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

Re: Debian coding style?



On 7 May 1999, Amy Fong wrote:

> Query, is there actually a coding style guideline for debian stuph?
> 
> Basically I'm with the Corel Linux group and this is what the Corel
> Linux Coding guidelines say... (follows). A few note-worthy ones are:
> 	- tabs: 2 spaces

As I've read the rest of the stuff (not quoted here), the guidelines call
for the size of tab stops to be changed and for tab characters to be used.
This is generally EXTREMELY BAD practice in unix/linux code, as most
editors default to 8 character tab stops, not all of them let you change
it.

> 	- curly braces alway on next line
> 		ie if (...)
> 			 {
> 			 }
> 			 else
> 			 {
> 			 }

Well I think it looks ugly, but my idea of the OTBS (one true brace style)
is the K&R one

if (condition) {
    statements
} else {
    other stuff
}

> 	- hungarian notation

Lots of people dislike hungarian notation.  I learned it once, found it
didn't really make variable names any easier to understand, it just looked
ugly.

> Will the Debian community be excrusiatingly unhappy with this?

It's your code.  But in general, Debian tries to make code modifications
in the style of the original author.

> 21. Filenames: source files should have .cpp extension. Header files should
> have a .h extension. All filenames should be created using only lower case
> characters. All filenames in #include statements should also be written in
> lower case. Source and header files should normally reside in the same
> directory. Large projects should be split up into smaller sub-projects to
> keep the number of source files in each directory manageable.

In general, C++ code in unix environments uses the .cc extension.

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

GNU gettext is useful for this under linux/unix



Reply to: