[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Debian coding style?

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

> * 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

> 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

> 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

> 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.


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: pgpkw5FlxePcb.pgp
Description: PGP signature

Reply to: