Stylistic questions on UNIX C coding.
in [Unix Programming]
|
Prev: integer
Next: shared memory question
From: Rainer Weikusat on 24 Feb 2010 15:05 Poster Matt <postermatt(a)no_spam_for_me.org> writes: > 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 problem with the preprocessor is that it work at the level of preprocessing tokens and this means that, if preprocessor macros don't live in a unique namespace, unintended substitutions can happen easily, for instance, of subroutine names, and errors caused by this are difficult to track down. [...] > 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); CamelCase was invented for the Xerox Alto whose keyboard didn't have an underscore character. Since 'object oriented programming' was also (mostly) invented in the same context, 'OO-programmers' of today still work around this hardware deficiency of the 1970s. TheReasonThatTextsAreNotWrittenLikeThisIsBecauseReadibiltyIsCrappyThen. So_use_a_visually_distinct_separator_character. People using scripts based on the Roman alphabet have abandoned the Roman writing convention to not use separators more than thousand years ago. Don't reinvent it. [...] > 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; C knows about three kinds of derived types, arrays char a[]; Pointers to functions char (*a)(); and pointers char *a; Don't special-case on of these three cases because of a lack of understanding of the C type system. Lastly, please don't ask questions like this in public.
From: Keith Thompson on 24 Feb 2010 15:41 Poster Matt <postermatt(a)no_spam_for_me.org> writes: > 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 convention is to use all-caps for macro names, unless you're deliberately hiding the fact that something is a macro. > 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); A lot of people dislike camel case (my own preference is lower case with underscores for most things), but it's a common and widely accepted style. If you're working on an existing project, you should follow the existing style (this applies to all these rules). > 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. 80 columns. > 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; The usual C style is char *firstName; The usual C++ style is char* firstName; There's no language-level reason for the difference; C and C++ syntax are the same at this level. I think it's just that Kernighan and Ritchie preferred the first form, and Stroustrup preferred the second. If you're going to be programming in C, I recommend the first form, both because it's the usual convention and because it follows the syntax of the langauge. When the compiler parses: char * firstName ; "*" and "firstName" are grouped together. What the declaration really means is that the expression "*firstName" is of type char; it follows from this that firstName is of type char*. C declarations usually follow a "declaration follows use" format (though not 100% consistently). If you choose to use the second style, you should avoid declaring multiple objects in a single declaration. Others have pointed out that this: char* foo, bar; is either misleading or wrong. The solution, whichever style you use, is to declare foo and bar separately: char *foo; /* or char* foo; if you insist */ char bar; [...] -- Keith Thompson (The_Other_Keith) kst-u(a)mib.org <http://www.ghoti.net/~kst> Nokia "We must do something. This is something. Therefore, we must do this." -- Antony Jay and Jonathan Lynn, "Yes Minister"
From: BruceS on 24 Feb 2010 15:53 On Feb 24, 12:32 pm, Seebs <usenet-nos...(a)seebs.net> wrote: > On 2010-02-24, Poster Matt <postermatt(a)no_spam_for_me.org> wrote: <snip> > > 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? > > I dislike it, anyway. Convention is words_with_underscores(). > > > EG: > > Variables: int numFiles = 0; > > Functions: int CountNumFilesInDir(char* path); FWIW, I prefer the camel case style, though I don't capitalize function names. If I'm maintaining someone else's code (and don't expect to take it over), I follow their style. If I'm working with a team, the team usually agrees on a style. <snip> > > 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; > > You are wrong. > > I mean, sure, it compiles, but consider: > > char* x, y; > > By contrast: > char *x, y; > makes it clear that you are aware that the * modifies the variable, not the > type. Absolutely with Seebs on this. The first style clearly implies that x and y are both pointers to characters. <snip> I would like to add that, as long as you're trying to use good style, for God's sake don't use the wrong indentation style. If you put your opening braces on the same line as your conditional, you'll just look like a fool in front of your friends and colleagues.
From: Keith Thompson on 24 Feb 2010 16:06 Rainer Weikusat <rweikusat(a)mssgmbh.com> writes: > Poster Matt <postermatt(a)no_spam_for_me.org> writes: [...] >> 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; > > C knows about three kinds of derived types, arrays > > char a[]; > > Pointers to functions > > char (*a)(); > > and pointers > > char *a; Array types, structure types, union types, function types, and pointer types are all derived types (C99 6.2.5). > Don't special-case on of these three cases because of a lack of > understanding of the C type system. But it might be acceptable to special-case on some cases *with* an understanding of the C type system. I prefer "char *a;" myself, but there's a valid argument that "char* a;" makes it more obvious that's meant (that a is of type char*). As long as you also avoid declaring multiple objects in a single declaration, it doesn't necessarily cause any problems. > Lastly, please don't ask questions like this in public. Why not? Or are you just being rude? -- Keith Thompson (The_Other_Keith) kst-u(a)mib.org <http://www.ghoti.net/~kst> Nokia "We must do something. This is something. Therefore, we must do this." -- Antony Jay and Jonathan Lynn, "Yes Minister"
From: James Harris on 24 Feb 2010 16:28
On 24 Feb, 20:53, BruceS <bruce...(a)hotmail.com> wrote: .... > I would like to add that, as long as you're trying to use good style, > for God's sake don't use the wrong indentation style. If you put your > opening braces on the same line as your conditional, you'll just look > like a fool in front of your friends and colleagues. Snobbish nonsense! |