Stylistic questions on UNIX C coding.
in [Unix Programming]
|
Prev: integer
Next: shared memory question
From: Poster Matt on 25 Feb 2010 11:18 Julienne Walker wrote: > On Feb 24, 2:21 pm, Fred <fred.l.kleinschm...(a)boeing.com> wrote: >> On Feb 24, 11:10 am, Julienne Walker <happyfro...(a)hotmail.com> wrote: >>> On Feb 24, 1:35 pm, Poster Matt <postermatt(a)no_spam_for_me.org> wrote: >>>> 4. Does anyone care where the pointer * is? I prefer keeping to next to the >>>> type, rather than next to the variable name. >>>> EG. I like: char* firstName; and not so much: char *firstName; >>> Just make sure you're consistent and nobody will care. :-) >> Except that it is very error-prone to do so. > > It's only error prone if you have multiple variables in a declaration > statement (which the OP's example did not). That itself is often > viewed as an unsafe practice. OP here... Yes and agreed. My view is that each variable should have it's own line. The only exception I make is when a for loop needs 2 index variables and both are initiated in the for loop statement. EG: int i, j; for (i = pos, j = 0; ...)
From: John Bode on 25 Feb 2010 11:21 On Feb 24, 12:35 pm, Poster Matt <postermatt(a)no_spam_for_me.org> wrote: > Hi, > > I've a few questions concerning style when programming C on UNIX systems. I > don't want to look like an amateur. :) > > 1. Having been programming in higher level languages for the last 15 years, I'm > finding it hard to get used to DEFINES in all capitals. Is it really frowned on > not to do so? Is CamelCase acceptable? > > EG. '#define MaxNumFiles 1024' not '#define MAXNUMFILES 1024'. > The all-caps convention makes it easier to distinguish preprocessor macros from other symbols. This can matter, especially when using function-like macros (macros that take arguments). Remember that macro expansions are simple text substitutions; a macro like #define square(x) (x*x) does not compute "x*x" and return a value; it *replaces* the text "square(x)" with "(x*x)". If x is "z++", then the replacement text is "(z++*z++)", which invokes undefined behavior. If x is "a+b", then the replacement text is "(a+b*a+b)". By using all-uppercase for macros, it makes it easier to see potential red flags like "SQUARE(x+ +)" or "SQUARE(x+y)". > 2. My personal variable and function naming style is camel case, with variable > names beginning with a lower case char and function names not. Is that > acceptable, if not what is? > > EG: > Variables: int numFiles = 0; > Functions: int CountNumFilesInDir(char* path); > That's fine. Just be consistent. > 3. Is there an accepted maximum line length? I've got a 24" monitor, if I reach > 120 chars I start thinking this might not look great in someone else's editor. > Side scrolling is irritating. Just make sure you break lines up sensibly. > 4. Does anyone care where the pointer * is? I prefer keeping to next to the > type, rather than next to the variable name. > > EG. I like: char* firstName; and not so much: char *firstName; > It's an accident of C lexical rules that you can write it either way. The second form correctly reflects the language syntax (the '*' operator is bound to the declarator, not the type specifier), and tends to be preferred among C programmers. It also guards against potential mistakes like char* a, b; // b is a regular char Declarations in C (and C++) reflect the type of an *expression*, not an object. The type of the *expression* "*firstName" is char. The idea is that the form of the declaration should closely match the form of an expression that yields a value of that type. If you have an array of pointers to int, and you wanted to access a specific int value, the expression would be "x = *a[i];" The type of the *expression* "*a[i]" is int, so the declaration of a is "int *a[N]". C++ programmers prefer "char* firstName", because the type of the *object* "firstName" is char*. Fine, but what about "char lastName[20]"? The type of "lastName" is "20-element array of char", but we can't write "char[20] lastName". Same thing for function types. Same thing for pointers to arrays, pointers to functions, etc. > 5. On a slightly different note, I've been handling my error messages by using > #define string constants in a header file. I saw some code which did this and it > looked good to me. Is that standard practise, if not what is? > > EG. #define ErrorDirNotFound "The directory was not found." > > There are so many style guides out there, most of them say contradictory things > at one point or another. What do the pros do? > I can't speak for anyone else, but I typically create a string table and an enum to index it: enum ErrorCodes {ErrDirNotFound, ErrInvalidPath, ...}; char ErrorStrings[] = {"Directory not found", "Path is invalid", ...}; It scales a little better than using #defines all over the place. > Finally, before someone points this out... I know if I'm coding for myself, and > not following somebody else's stylistic requirements, I can do whatever I want. > However I'd like my code to be 'acceptable looking' to the wider UNIX C community. > > Thanks and regards, etc.
From: Stephen Sprunk on 25 Feb 2010 11:42 On 24 Feb 2010 16:04, Keith Thompson wrote: > Stephen Sprunk <stephen(a)sprunk.org> writes: >> On 24 Feb 2010 12:35, Poster Matt wrote: > [...] >>> EG: >>> Variables: int numFiles = 0; >> >> This is camelCase. >> >>> Functions: int CountNumFilesInDir(char* path); >> >> This is PascalCase. >> >> Mixing the two in the same project will drive adherents of _both_ styles >> nuts. Pick one and stick to it; that way you'll only drive half of your >> readers nuts. > > His convention apparently is to use camelCase for variables and > PascalCase for functions. It's not necessarily a style I'd use, but > it's not obviously horrible (and it's more or less the style I use > at work). Granted, it's not as bad as mixing the two within the same type of thing, but it's still bad, IMHO. I hate PascalCase; I can deal with it if _everything_ is cased that way, but a lot of my functions and function calls would end up in camelCase if I had to switch back and forth. > As with most of these rules, conforming to existing code > is far more important than any benefits of one style over another. Of course; I said roughly the same thing at the top of my post. I've just never seen a project that does it that way--or perhaps it was so painful for me to read that I gave up, moved on, and repressed the memory. >> (There's also this_type_of_identifier; the same logic applies, i.e. >> don't mix that with either of the above. Never, never create some >> God-awful hybrid with both underscores and uppercase letters...) > > Again, This_Type_Of_Identifier isn't obviously horrible. (I use it > myself, though not in C.) IMHO, that's also horrible. What I was thinking of was worse, though: this_typeOfIdentifier. "Horrible" isn't strong enough for that. S -- Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking
From: Poster Matt on 25 Feb 2010 11:58 >> Where did you pick up these preferences? > > I'd have guessed Java, but as Rainer Weikusat points out in > <87d3zuflhs.fsf(a)fever.mssgmbh.com>, CamelCase and co. originate from > much earlier. (Thanks for the interesting historical tidbit, Rainer!) OP here... I picked them up from a university lecturer of mine during a software engineering course in the mid 1990's. The course required groups of 5 students collaborating on a coding project, don't remember what language we used but definitely not C or C++, possibly Java, but not sure. The lecturer explained that in real world projects with a programming team, a style guide would be the norm. So he imposed his own one on us. When free to choose, I've been using my own variation of it ever since. It may have been influenced by a book called Code Complete, but it's so long since I read it that I can't recall exactly what I picked up from that and what from personal experience and preference.
From: Poster Matt on 25 Feb 2010 12:03
Eric Sosman wrote: >> > Contradict each other, of course! Why did you ask? Given the amount of contradictory advise I'm getting in this thread I am beginning to wonder why myself. :) |