I'm probably too late and lots of people have probably already said the same, but some comments: > Modifications made to existing code may follow the coding style used > by the original author in order to maintain readability. Replace may with must here please: it's really horrible if you get a patch for a program you wrote with a different coding style then you use. You'll have to reindend, and as a result the person who made the patch can't patch cleanly to your source anymore, etc. etc. (and yes, I've seen people almost walking away angrily from a project because of that). > * Compiling: all code must compile clean at warning level 3 with warnings > as errors. That sounds mscl (now called msvc) specific, for gcc you would want to use -Wall. > > 2. Testing: all code must be compilable, tested, and DIFF'ed before being > checked into source safe. source safe -> the repisotory (no need to be product specific here). > Remember that the person who is most qualified to test any piece of > code is the person who wrote it. I can argue about that. But I won't :) > 3. Tabs should be set to 2, and they should be kept as tabs, no spaces > please. This is a definite no-no. Tabstops are traditionally 8. All editors default to 8, and some can't change the tabstop. A lot of people get away with a tabstop of 4 (me for example), but I'ld stick with 8 if possibly. > 4. Code width: The complete line of code should be visible without having to > scroll horizontally - i.e. it should normally not pass the 78th column. With C++ and STL code you'll never be able to use that, the names just get too long. (example: I have a type called IntelligenceFactor::AnswerIterator::const_iterator in a project). > 5. Naming conventions: > > a) Class names always start with upper-case 'C', followed by an upper-case > letter, followed by mixed upper/lower case and must always take the form of > a descriptive noun. Highly personal comment: Evil :). I used prefixes like that to categorize classes occasionally (ie every classname starting with a U is for userinterface-stuff), but with namespaces that isn't even usefull anymore. > b) Method/function names always start with upper-case followed by mixed > upper/lower case and must always take the form of a descriptive verb or > action. Same as I always use. Not that that should mean anything to anyone else :) > c) Variable names must use hungarian notation (see below) followed by > upper-case followed with mixed upper/lower case and must always take the > form of a descriptive noun. Variables which are members of a class must have > m_ prepended to the name. This was considered usefull for a while, I don't think anyone really uses this anymore. I found it to be more trouble then it's worth. > * Magic numbers must not be embedded directly in the source code. Use a > const int variable to hold the magic number rather than a #define. Sounds like good coding style, makes things much easier later. > 10. Function/method size: bigger is not better. Functions and methods should > be kept to a maximum of 40-50 lines. Larger methods should be broken down > into several smaller methods. I tend to use functional blocks in a function as guideline instead of linecount. > 14. Compilation conditionals, with the exception of debug code noted above, > should be avoided since they make the source code difficult to read and > maintain. You might want to list architecture or OS-dependant differences as well here. > 21. Filenames: source files should have .cpp extension. .cpp seems to be the standard extensions used for windows. For UNIX systems everyone is using .cc instead. (Stroustrup seems to use .c for C++ as well btw). > 22. Localization: text which will be visible to the user should never be > embedded within the source code. All string literals should be placed in a > separate header file to ease the pain of possible future translation. Why not use gettext? I think that doesn't need/want this approach, and it is *the* standard for i8n under UN*X systems. > 24. delete operations should be followed by an immediate reassignment of the > associated pointer with a NULL value as in the following example, even if > the pointer is about to go out of scope. Stroustrup quite strongly says one should never use NULL, but plain and simple 0. > Any accidental attempt to use the pointer following its deletion will > generate an immediate protection fault when the code is executed, > which is much easier to find than unpredictable behaviour caused by > using and invalid pointer. Or an throw an exception, I think that depends on the compiler? > 27. C++ style casts (dynamic_cast, static_cast) should be used rather than > older C style casts. This makes it easy to later find occurrences of > casting. Given a choice, use of dynamic_cast is preferred since it uses > runtime type info to ensure that the cast is valid. I'ld put this stronger and say they must be used. Wichert. -- ============================================================================== This combination of bytes forms a message written to you by Wichert Akkerman. E-Mail: wichert@cs.leidenuniv.nl WWW: http://www.wi.leidenuniv.nl/~wichert/
Attachment:
pgpvzCcoLPBNo.pgp
Description: PGP signature