From: Tom H. <tom...@us...> - 2002-08-14 12:11:24
|
Hi, > This is the coding style I'm trying to use for the 3D server. Would be > nice if everybody else also tries to use it; however, I'm not going to > start holy wars it :) > If you think something should be changed for a good reason, please do > so. (Oliver) I agree with most of your points, with a few exceptions. See below for details, though I would be interested to here other opinions. [...snip...] > * Naming Conventions > > Structures: > class ClassName; > struct SStructName; > typedef int TInt; I disagree with SStructName and TInt. The reason being that if the struct or typedef changes to something else, then the naming is misleading and doing a global replace can result in errors. So I prefer Structures: class ClassName; struct StructName; typedef int Int; union UnionName; > ** Enums > > Enumeration types 'enum' start with a capital 'E', followed by the > type name starting with a capital letter. Again I disagree, for the same reasons as above. > Enumeration elements start with 'e', followed by the > name of the constant starting with a capital letter. To me enumerated elements are akin to static const members and as such should have the same syntax. > Example: > enum EEnumName > { > eEnumElement1, > eEnumElement2 > }; Example: enum ENumName { S_ENUM_ELEMENT, S_ENUM_ELEMENT } I'll get to the S_ later. [...snip...] > ** Variables: > > *** Variables with local scope > > Variables with local scope start with a small letter. New words > within the variable name start with a captial letter. > > Example: myVariable I prefer my_variable as it's easier to recognise as a local variable and not a function. > *** Member variables > > Member variables start with a 'm', followed by the variable name, > beginning with a capital letter. New words within the variable name > start with a captial letter. > > Example: mMemberVariable I prefer M_member_variable, to maintain similarities between the syntax or local variables and member variables and to help discern it from a function (though it could be argues that the 'm' does that). I also prefer static member variable start with a 'S_' followed by the variable name with new words separated by a '_'. Example: S_static_member_variable Constant static member variables (and enums) are the same but capitalised. Example: S_STATIC_CONST_MEMBER_VARIABLE [...snip...] > * Files > > - file names consist of only small letters > - .h is the suffix for c++ header files, .cc is the suffix for c++ source > files - max line length is 80 characters and should start with // -*-c++-*- /*************************************************************************** filename Description ------------------- begin : begin date copyright : (C) year (or years) by The RoboCup Soccer Simulator Maintenance Group. email : sse...@li... ***************************************************************************/ /*************************************************************************** * * * This program is free software; you can redistribute it and/or modify * * it under the terms of the GNU GPL as published by the Free Software * * Foundation; either version 2 of the License, or (at your option) any * * later version. * * * ***************************************************************************/ Just my 2 pence. Any opinions? Cheers, Tom |
From: Artur M. <am...@ir...> - 2002-08-14 13:25:57
|
Hi, most points are also OK for me. What I'm missing are rules for names of header files and the corresponding defines. If the file contains basically the declaration of a new class MyNewClass the the corresponding file should be called my_new_class.h (inserting an underscore instead of capitalisation). Furthermore each header file (eg. "my_header_file.h" should start with #ifndef _MY_HEADER_FILE_H_ #define _MY_HEADER_FILE_H_ ... #endif capitalising the file name and with an underscore prepended and a "_H_" attached (or some other consistent convention). Here some other comments: On Wed, 14 Aug 2002, Tom Howard wrote: > I disagree with SStructName and TInt. The reason being that if the struct or > typedef changes to something else, then the naming is misleading and doing a > global replace can result in errors. > > So I prefer > > Structures: > class ClassName; > struct StructName; > typedef int Int; > union UnionName; me too (for the same reason) * Indentation Only four-space line indentation should be used. I prefer 2 space indentation, but it's certainly a matter of taste. > *** Member variables > > Member variables start with a 'm', followed by the variable name, > beginning with a capital letter. New words within the variable name > start with a captial letter. > > Example: mMemberVariable >I prefer M_member_variable, to maintain similarities between the syntax or >local variables and member variables and to help discern it from a >function (though it could be argues that the 'm' does that). I also prefer m_member_variable or M_member_variable. We should also encourage the usage of const (as often as possible) 1) example: prefer SomeClass::method(MyNewClass const* mnc) { //mnc is not changed (and just const methods of mnc are called) } instead of SomeClass::method(MyNewClass * mnc) { //mnc is not changed (and just const methods of mnc are called) } if mnc is not supposed to get changed. 2) example: methods not supposed to change member variables should always be const: SomeClass::method( ... ) const { //do not change any member variable } instead of just SomeClass::method( ... ) { //do not change any member variable } ... any comments? Artur __________________________________________________________________________ Artur Merke ||| am...@ir... (O-O) art...@st... _______________.oo0--(_)--0oo.____________________________________________ |
From: Tom H. <tom...@us...> - 2002-08-15 08:52:59
|
On Wednesday 14 August 2002 1:25 pm, Artur Merke wrote: > my_new_class.h (inserting an underscore instead of capitalisation). I agree with Oliver that mynewclass.h is better. > Furthermore each header file (eg. "my_header_file.h" should start with > > #ifndef _MY_HEADER_FILE_H_ > #define _MY_HEADER_FILE_H_ > ... > #endif > > capitalising the file name and with an underscore prepended and a "_H_" > attached (or some other consistent convention). I've constantly read that underscores at the start and end should only be used in the STL (I don't know why). So I suggest #ifndef MY_HEADER_FILE_H #define MY_HEADER_FILE_H But this usually doesn't take namespaces into account, which means that sometimes header files from different libs can clash, so I've started using #ifndef NAMESPACE_MY_HEADER_FILE_H #define NAMESPACE_MY_HEADER_FILE_H where namespaces are used (which should be most of the time) What do you reckon? Cheers, Tom |
From: <fr...@ro...> - 2002-08-14 16:21:16
|
At Wed, 14 Aug 2002 15:25:47 +0200 (MEST), Artur Merke wrote: > What I'm missing are rules for names of header files and the > corresponding defines. > > If the file contains basically the declaration of a new class > > MyNewClass > > the the corresponding file should be called > > my_new_class.h (inserting an underscore instead of capitalisation). I prefer using 'mynewclass.h' for brevity, at least this is what I used for the files I committed. If we use 'my_new_class.h', this is OK for me; for the committed directories I'm going to stick to the 'mynewclass.h' syntax to be at least consistent (the other option would be to rename all the files, remove them from CVS and check them in with the new name). > Furthermore each header file (eg. "my_header_file.h" should start with > > #ifndef _MY_HEADER_FILE_H_ > #define _MY_HEADER_FILE_H_ > ... > #endif > > capitalising the file name and with an underscore prepended and a "_H_" > attached (or some other consistent convention). Right, for the header files, it should be: #ifndef _MY_HEADER_FILE_H_ // (or _MYHEADERFILE_H_, depending on the #define _MY_HEADER_FILE_H_ // file naming convention) #ifdef HAVE_CONFIG_H #include <config.h> #endif ... #endif to support the configure stuff. > Only four-space line indentation should be used. > > I prefer 2 space indentation, but it's certainly a matter of taste. yep; usually I do 8, but with long function names I think 4 is a good compromise. > I also prefer m_member_variable or M_member_variable. Also OK for me (lines get so much longer then... :). We can use M_..., as this appears in the 2d server already. > We should also encourage the usage of const (as often as possible) I thought this goes without saying, but after looking into my code: should be in. I'm working over the console stuff anyway, so I'll convert it while I'm trying to get the console running. However, getting it running comes first... cheers Oliver -- Oliver Obst 0261 287-2774 form follows function - Louis Sullivan AI Research Group U Koblenz MB219 https://www.uni-koblenz.de/~fruit/about/pgp.html |
From: Patrick R. <pf...@cs...> - 2002-08-14 17:14:10
|
On a somewhat separate issue: The small size robot team here has been working on a simulator using ODE. It's in pretty good shape, and code should be available at the end of the month (and they'll give the whole group here access sooner if we want). Notably, there is code for hierarchical scene graphs as we discussed. This raises 2 issues: 1. Do we want our new simulator to be useful to people developing real robots? This will require some extra work and coordination for us, as well as the headaches of a shared code base. OTOH, this could do a great deal for making it easier to move simulation code to real robots and getting the simulation league more respect in the general community. 2. Do we want to maintain a shared simulatenous code base and development? Once again, more work for us, but better result in the end I believe. -- Patrick Riley Fourth Year Ph.D. Student Computer Science Department, Carnegie Mellon University http://www.cs.cmu.edu/~pfr |
From: <fr...@ro...> - 2002-08-15 06:41:59
|
At Wed, 14 Aug 2002 13:13:49 -0400, Patrick Riley wrote: > > On a somewhat separate issue: > > The small size robot team here has been working on a simulator using > ODE. It's in pretty good shape, and code should be available at the > end of the month (and they'll give the whole group here access sooner > if we want). > > Notably, there is code for hierarchical scene graphs as we discussed. Sound great. At least we should have a look at it; there's possibly a lot of stuff in to learn from. Maybe we don't want to have a shared code base, but if the 3d server gets modular enough, we can have kinds of "real robots" modules that we can plug in. At least the interface and the actuator stuff is worth having a look. If the small size people also want to put some effort in maintaining a shared code base, we can possibly sort out the stuff we do want to share and maintain it in a separate library. cheers Oliver -- Oliver Obst 0261 287-2774 form follows function - Louis Sullivan AI Research Group U Koblenz MB219 https://www.uni-koblenz.de/~fruit/about/pgp.html |
From: Tom H. <tom...@us...> - 2002-08-15 08:55:05
|
On Wednesday 14 August 2002 5:13 pm, Patrick Riley wrote: > 1. Do we want our new simulator to be useful to people developing real > =A0 =A0robots? Eventually yes. > 2. Do we want to maintain a shared simulatenous code base and > =A0 =A0development? I thing this would be a very good idea. Cheers, Tom |
From: Artur M. <am...@ir...> - 2002-08-15 08:00:28
|
Hi, On Wed, 14 Aug 2002, Oliver Obst wrote: > I prefer using 'mynewclass.h' for brevity, at least this is what I > used for the files I committed. > If we use 'my_new_class.h', this is OK for me; for the committed > directories I'm going to stick to the 'mynewclass.h' syntax to be at > least consistent (the other option would be to rename all the files, > remove them from CVS and check them in with the new name). mynewclass.h and _MYNEWCLASS_H_ is OK for me. BTW I was wondering why you are speaking about committed code, and I couldn't find any after issuing cvs update, but at the end cvs update -d did the job. > yep; usually I do 8, but with long function names I think 4 is a good > compromise. OK, OK nor further arguments, because 4 is really the maximum I could live with ;-) > > I also prefer m_member_variable or M_member_variable. > > Also OK for me (lines get so much longer then... :). > We can use M_..., as this appears in the 2d server already. so let stick to M_ > > We should also encourage the usage of const (as often as possible) > > I thought this goes without saying, but after looking into my code: > should be in. > > I'm working over the console stuff anyway, so I'll convert it > while I'm trying to get the console running. However, getting it > running comes first... sounds reasonable. Cheers Artur __________________________________________________________________________ Artur Merke ||| am...@ir... (O-O) art...@st... _______________.oo0--(_)--0oo.____________________________________________ |
From: Patrick R. <pf...@cs...> - 2002-08-14 17:17:58
|
From codingstyle.txt * Placing Braces Opening and closing braces should be on the same level of indentation below the token opening the scope. Opening and closing braces appear on a separate line by themselves. Example: void ClassName::function() { if (x) { while (y) { // ... } } else { switch (z) { case 1: { // ... break; } default: { // ... break; } } } } ------------------ I would prefer the 2 space to the brace and two space after like the current server uses, but that's really not a big deal. I'll just configure my emacs to DTRT :-) If everyone/most people are emacs folks, I'll write a thing to configure the indentation to whatever we agree on. example: void ClassName::function() { if (x) { while (y) { // ... } } else { switch (z) { case 1: { // ... break; } default: { // ... break; } } } } -- Patrick Riley Fourth Year Ph.D. Student Computer Science Department, Carnegie Mellon University http://www.cs.cmu.edu/~pfr |
From: <fr...@ro...> - 2002-08-15 07:52:47
|
At Wed, 14 Aug 2002 13:17:47 -0400, Patrick Riley wrote: > I would prefer the 2 space to the brace and two space after like the > current server uses, but that's really not a big deal. I'll just > configure my emacs to DTRT :-) If everyone/most people are emacs > folks, I'll write a thing to configure the indentation to whatever we > agree on. OK, great. Below is some configuration to use with GNU indent. With this text in a file ~/.indent.pro, indent can reformat the source files the way we want.=20 (Currently, the braces style is like I was proposing; with '-bli2' indent does the 2 spaces before the brace, but the regular indentation (4 spaces) after the brace. I don't know yet how to fix that.) =20 cheers Oliver // -*- text -*- // to use this file with indent, put it into your $HOME as .indent.pro // // it does ALMOST that what I want (the public:, protected: and // the private: keyword are a bit misaligned, but the rest seems OK). // don't causes indent to force a blank line after every block of // declarations. -nbad // The `-bap=B4 option forces a blank line after every procedure body. -bap // swallow optional blank lines -sob // comments --dont-star-comments --no-comment-delimiters-on-blank-lines -cp33=20 -d0 -nfc1 -nfca // braces -bl -bli0 // case labels and braces in case labels -cli4 -cbi0 // space label before semicolon on the same line as for or while -ss // no space between procedure call and opening bracket -npcs // no spaces after paranthesis -nprs // spaces after for, while and if, space after cast operator -saf -saw -sai -cs // old style functions -ip0 // declarations -di1 -nbc=20 // function types in a line before function name (useful for etags) -psl // structs -bls // indentation and no tabs, no additional continuation indentation -i4 -nut -ci0 // no special declaration indentation -di1 // lineup after a line with an opening bracket -lp // breaking long lines: max 80 chars, don't break before operators,=20 // honour the newlines already in -l80 -nbbo -hnl --=20 Oliver Obst 0261 287-2774 form follows function - Louis Sullivan AI Research Group =20 U Koblenz MB219 https://www.uni-koblenz.de/~fruit/about/pgp.html=20 |
From: Artur M. <am...@ir...> - 2002-08-15 08:19:25
|
Hi, On Wed, 14 Aug 2002, Patrick Riley wrote: > I would prefer the 2 space to the brace and two space after like the > current server uses, but that's really not a big deal. I'll just > configure my emacs to DTRT :-) If everyone/most people are emacs > folks, I'll write a thing to configure the indentation to whatever we > agree on. sounds good to me (if emacs also includes xemacs ;-) > example: > > void > ClassName::function() > { > if (x) > { > while (y) > { > // ... > } > } > else > { > switch (z) > { > case 1: > { > // ... > break; > } > default: > { > // ... > break; > } > } > } > } Personally I prefer ClassName::function() { if (x) { while (y) { // ... } } else ... (or the version with 2 spaces instead of 4 ;-) but It's also reasonable to place the braces on the same column. But if doing so I would prefer Olivers version. IMO it's also more consistent with pure local blocks prefer cout << "hello world" { //some local block ... } //some other code ... instead of cout << "hello world" { //some local block ... } //some other code ... because the local block is just a (macro) instruction, and there is no reason to have an extra indentation rule for such instructions (IMO). Cheers Artur __________________________________________________________________________ Artur Merke ||| am...@ir... (O-O) art...@st... _______________.oo0--(_)--0oo.____________________________________________ |