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

Re: Debian coding style?



uwd38znr@umail.furryterror.org (Amy Fong) writes:

> Query, is there actually a coding style guideline for debian stuph?

There's not any formal spec since there are so many different
languages involved.  For example, lisp/elisp/scheme programmers would
lynch you if you tried to make them use function names like
CPhoneBookEntry.  This would, in accordance with the ONE TRUE WAY be
phone-book-entry or similar.  Many of the rules you've quoted are only
applicable in a very narrow domain (i.e. C++ (and sometimes C) code).

In general, for C code, I prefer something more similar to the GNU
programming guidelines ("info standards"), and if you were to go by
sheer code volume, I would guess that the three top contenders for a
majority style would be GNU, the kernel conventions, or XFree86
conventions with GNU being the most likely winner (though I haven't
gathered any statistics).

> Will the Debian community be excrusiatingly unhappy with this?

Of course one of the highest order rules is "Those who code well,
win.", so if your stellar developers contribute unbelievably clever
WINE code that lets us never think about that other company again, or
painfully elegant auto-configuration code that makes the installation
process require a single keypress and a wink, then you can probably
write it in Sumerian and we'll still be as happy as clams.

> Hungarian Notation:

Yuck.

> 11. Curly braces
  [...]
> m_nDummy = nDummy;
> 
> if (nDummy > knFunkyLimit)
> 
> {
> 
> DoSomethingFunky();
> 
> }
> 
> }

Double yuck.  Each brace level should indent.  Consistency is good...

> 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. Old or unwanted code should be deleted from the source files prior
> to check-in. Source safes history feature can be used to retrieve an old
> version of the file if the old code is ever required again.

Think multi-platform...

> 16. Goto statements should not be used.

Good general suggestion, but not always valid.  Many language
implementations need goto and longjmp and we have quite a few such
beasts.

> 19. Comparisons for equality against a constant value should list the
> constant value first. Its easy to miss one of the equals signs - this way
> the compiler will catch it if you do.

I never actually realized what the advantage to this was until now.
Hmm.  Learn something new...  (Of course C shouldn't have created this
mess in the first place, but that's water over the dam...)

> 20. Header files must not include other header files (to prevent header file
> bloat). Use forward class references to inform compiler of required data
> types.

What?  This sounds *extremely* broken if I understand it correctly.

> 21. Filenames: source files should have .cpp extension.

.cc is much more common (I think) in Linux, but I haven't checked.

Overall, a pretty reasonable set of rules.  Hmm.  Surprised, but
mostly pleased.

-- 
Rob Browning <rlb@cs.utexas.edu> PGP=E80E0D04F521A094 532B97F5D64E3930


Reply to: