Stylistic questions on UNIX C coding.
in [Unix Programming]
|
Prev: integer
Next: shared memory question
From: Branimir Maksimovic on 2 Mar 2010 04:11 Nick Keighley wrote: > On 27 Feb, 16:39, Rich Webb <bbew...(a)mapson.nozirev.ten> wrote: >> On Sat, 27 Feb 2010 08:30:16 -0800 (PST), Nick Keighley >> <nick_keighley_nos...(a)hotmail.com> wrote: >>> On 27 Feb, 08:39, James Harris <james.harri...(a)googlemail.com> wrote: > > > >>>> Windows Notepad users are stuck with 8. Windows Wordpad users seem to >>>> be stuck with 6. These are not earlier than the 1980s. >>>> Come to think of it, apart from those two programs what do Windows >>>> users use to enter and edit source code? >>> the IDE, ConText, emacs, Word >> vi! Nowadays likely in its gvim incarnation, of course. > > VI VI VI! > the editor of the beast > Well, when I used VI it was because there wasn;t anything better on machine. Who said: VI editor that beeps and corrupts you files? Once I encrypted my source code by accident with that thing. Greets
From: Curtis Dyer on 2 Mar 2010 04:53 On 26 Feb 2010, Phil Carmody <thefatphil_demunged(a)yahoo.co.uk> wrote: > Julienne Walker <happyfrosty(a)hotmail.com> 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; >> >> Just make sure you're consistent and nobody will care. :-) > > Horrifically wrong. I think it's a good bet that Julienne meant that the OP should be consistent *with a reasonable style*. > Just make sure you're consistent with > everyone else, and nobody will care. I don't know of any one style that's completely consistent with everyone else. But overall, you make a good point, since abominations such as char * foo( char* *x ) { /* ... */ } and void bar( int* y ) { /* ... */ } are consistent, but consistently awful. -- "Don't worry about efficiency until you've attained correctness." ~ Eric Sosman, comp.lang.c
From: Curtis Dyer on 2 Mar 2010 07:04 On 24 Feb 2010, James Harris <james.harris.1(a)googlemail.com> wrote: > On 24 Feb, 18:35, 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. :) > > As a fellow amateur in C.... Another fellow amateur, here. :-) >> 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'. > > While I use them I don't like all caps for #defined values for > two reasons > > 1) #defined values don't seem to me too far removed from global > parameters. I'm not sure what you mean here by "global parameters". Perhaps you mean object identifiers that have file scope? If so, one crucial difference that stands out to me is that macros may not expand to lvalues. #define MaxFoo 512 /* ... */ int main(void) { /* ... */ MaxFoo++; /* Whoops */ /* ... */ } > Indeed if we change them to parameters in a function > call they lose upper case status. Again, I'm not sure what you mean. > The two uses are similar. To > my mind the format of the names should also be similar. > > 2) I'd prefer to reserve all caps for macros. Then they serve as > a warning that parameters are not guaranteed to be evaluated > exactly once. Another distinction is that you can't use macro identifiers exactly like function identifiers: qsort(data, nitems, sizeof *data, compar); > Many libraries use all caps for their constants. I rather like Rob Pike's style and reasoning behind identifiers in his _Notes on Programming in C_. <http://www.lysator.liu.se/c/pikestyle.html> <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; I've occasionally seen: char * firstname; > It's normally as the latter due to > > char* FirstName, ch, *p; > char *FirstName, ch, *p; As Eric Sosman noted elsethread, I find that it depends on the context, whether or not I include multiple declarations on the same line. I generally like to place the asterisk next to the declarator for object declarations. For function prototypes and definitions, I like to place the asterisk next to the return type. > Regardless of which form is used I think only ch will be a char > variable Right. > - i.e. "char*" can be misleading. I think mainly to newcomers, but I can't imagine it being too misleading for most C programmers. <snip> >> 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." > > That's much better than sprinkling messages throughout the code. > If followed consistently it makes clear what messages the code > can issue. Apart from clarity that would help if you ever want > to release your code in another human language. There are better > ways with more mechanism. I believe some use enum constants, for example, as indexes for a lookup table with error message strings. > You may need a way to include variable values in your messages. Format strings for the *printf() functions is one obvious way. >> There are so many style guides out there, most of them say >> contradictory things at one point or another. What do the pros >> do? As Julienne noted elsethread, the professionals are no more in agreement, with regard to style, than the differing style guides. >> 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. > > Check some examples: K&R2, C Unleashed, books by Douglas Comer, > the Linux source etc. Also there is a FAQ entry for style > issues: > > http://c-faq.com/style/index.html Also, I would imagine lurking in comp.unix.programmer would be another good way to pick up on common Unix coding styles, as well as good practices in general. -- "Don't worry about efficiency until you've attained correctness." ~ Eric Sosman, comp.lang.c
From: Nick Keighley on 2 Mar 2010 09:03 On 2 Mar, 12:04, Curtis Dyer <dye...(a)gmail.com> wrote: > On 24 Feb 2010, James Harris <james.harri...(a)googlemail.com> > > On 24 Feb, 18:35, Poster Matt <postermatt(a)no_spam_for_me.org> > >> I've a few questions concerning style when programming C on > >> UNIX systems. I don't want to look like an amateur. :) > > > As a fellow amateur in C.... > > Another fellow amateur, here. :-) > > >> 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'. pre-processor macros have nasty semantics so its worth making them standout. > > While I use them I don't like all caps for #defined values for > > two reasons > > > 1) #defined values don't seem to me too far removed from global > > parameters. > > I'm not sure what you mean here by "global parameters". nor me. If he meant "global variable" the that means either file scope with internal linkage or file scope with external linkage. I suppose "global parameter" might be one of these. int adjust = 10; int make_adjustment (int fiddle) { mass_adjust (adjust + fiddle); } void do_stuff (int bing) { adjust = 0; make_adjustment (); } an abomination, but it happens (call backs without a needed parameter are one excuse). I don't really see #defines as being like global variables even though they have file scope. > Perhaps you > mean object identifiers that have file scope? If so, one crucial > difference that stands out to me is that macros may not expand to > lvalues. > > #define MaxFoo 512 > > /* ... */ > > int main(void) > { > /* ... */ > > MaxFoo++; /* Whoops */ > > /* ... */ > } well they can if you use them to alias an l-value int max_foo; #define MAXFOO max_foo MAXFOO++ not a good idea but... > > Indeed if we change them to parameters in a function > > call they lose upper case status. > > Again, I'm not sure what you mean. me neither! > > The two uses are similar. which two uses! > > To > > my mind the format of the names should also be similar. > > > 2) I'd prefer to reserve all caps for macros. Then they serve as > > a warning that parameters are not guaranteed to be evaluated > > exactly once. what? I thought you were explaining why you weren't using all caps for macros?! Did you mean value macros and function-like macros? #define MaxFoo 127 #define INC(X) (X++) > Another distinction is that you can't use macro identifiers exactly > like function identifiers: > > qsort(data, nitems, sizeof *data, compar); why not? I just don't follow you. <snip> > >> 4. Does anyone care where the pointer * is? oh yes! C programmers are nothing if not opinionated! <snip> > > - i.e. "char*" can be misleading. > > I think mainly to newcomers, but I can't imagine it being too > misleading for most C programmers. the C++ people seem to mange ok <snip>
From: Nick Keighley on 2 Mar 2010 09:06
On 2 Mar, 09:11, Branimir Maksimovic <bm...(a)hotmail.com> wrote: > Nick Keighley wrote: > > On 27 Feb, 16:39, Rich Webb <bbew...(a)mapson.nozirev.ten> wrote: > >> On Sat, 27 Feb 2010 08:30:16 -0800 (PST), Nick Keighley > >> <nick_keighley_nos...(a)hotmail.com> wrote: > >>> On 27 Feb, 08:39, James Harris <james.harri...(a)googlemail.com> wrote: > >>>> [...] what do Windows > >>>> users use to enter and edit source code? > > >>> the IDE, ConText, emacs, Word > >> vi! Nowadays likely in its gvim incarnation, of course. > > > VI VI VI! > > the editor of the beast > > Well, when I used VI it was because there wasn;t anything > better on machine. Who said: VI editor that beeps and corrupts you > files? > Once I encrypted my source code by accident with that thing. "The Real Programmer wants a "you asked for it, you got it" text editor--complicated, cryptic, powerful, unforgiving, dangerous. TECO, to be precise." |