Stylistic questions on UNIX C coding.
in [Unix Programming]
|
Prev: integer
Next: shared memory question
From: William Hughes on 24 Feb 2010 16:30 On Feb 24, 2:35 pm, Poster Matt <postermatt(a)no_spam_for_me.org> wrote: > There are so many style guides out there, most of them say contradictory things > at one point or another. What do the pros do? Among other things write style guides. (i.e. what makes you think the pros are not contradictory) The only near universal conventions that I can identify are - macros should be upper case - lines should not exceed 80 characters For the rest, choose what you are most comfortable with, always remembering that good code comes first. (There have been lots of pros and cons pointed out for your chosen style. I have little to add; putting all error strings in one place seems like a good idea, but something a little more flexible than simple macros would seem in order.) - William Hughes > > 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: Ersek, Laszlo on 24 Feb 2010 16:49 In article <slrnhob00o.fh7.usenet-nospam(a)guild.seebs.net>, Seebs <usenet-nospam(a)seebs.net> writes: > On 2010-02-24, Poster Matt <postermatt(a)no_spam_for_me.org> wrote: >> 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? > > It'll work, but people will find it surprising. All-caps as a warning that > something is a macro or other manifest constant is pretty canonical. > > But you'd normally spell that one "MAX_FILES". ( And not FILES_MAX, as _MAX is a reserved suffix (in the X/Open (or POSIX) Name Space). http://www.opengroup.org/onlinepubs/007908775/xsh/compilation.html#tag_000_002_001 http://www.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html#tag_15_02_02 ) >> 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(). I agree. However, I'd like to mention, as a counter-example, some C language X client libs using CamelCase. http://en.wikipedia.org/wiki/Xlib http://en.wikipedia.org/wiki/Intrinsics http://en.wikipedia.org/wiki/Motif_(widget_toolkit) >> 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. > > 80ish is preferred. Lines exceeding 80 will generally not be accepted by a > lot of projects unless there's a VERY good reason. Yes, a source formatted 80 columns wide works nicely on a character console. And on a 24" TFT in 1920x1200, you can put two such windows side by side, or have a web browser or a PDF viewer open beside the source window, or diff two versions side by side without having to scroll horizontally. >> 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." > > No. Look into gettext() if you need to do this, or just put them in > literally. Or, for a bit more portable (and harder to use) approach: http://www.opengroup.org/onlinepubs/007908775/xsh/catopen.html http://www.opengroup.org/onlinepubs/007908775/xcu/gencat.html The idea is that you translate printf() style format strings into different natural languages, making heavy use of %n$ "position specifiers", so that you can change the order the arguments are printed in, without changing the order they are passed to *printf() (ie. without changing the code). http://www.opengroup.org/onlinepubs/007908775/xsh/fprintf.html#tag_000_008_809 catgets() allows/forces the programmer to supply a default string, which is very useful. (Not that I'd believe in software internationalization at all, having seen *no* software correctly *and* understandably translated from English to Hungarian, for example.) > It's odd that you've managed > a complete sweep of, for every stylistic decision described above, picking > the opposite of the general convention in the UNIX world. 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!) Cheers, lacos
From: Ersek, Laszlo on 24 Feb 2010 16:54 In article <7f8b94fc-a78e-4c64-becf-f70a3843de08(a)o3g2000yqb.googlegroups.com>, James Harris <james.harris.1(a)googlemail.com> writes: > 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! I've actually laughed out loud when I've read Bruce's part above; it's so blatant that I'm almost completely sure it was meant as irony. (Perhaps so is your response, too.) Cheers, lacos
From: Stephen Sprunk on 24 Feb 2010 16:58 On 24 Feb 2010 12:35, Poster Matt wrote: > I've a few questions concerning style when programming C on UNIX > systems. I don't want to look like an amateur. :) The biggest mistakes that newbies make are lack of consistency and trying to change others' style. If you're contributing to an existing project, follow whatever established style it has, period. If you're starting a new project, pick one of the common styles in other projects you've seen and like. Do not modify (or "customize") the style unless you can competently explain _why_ it does things the way it does and you can demonstrate (to people more skilled than you) that your change is an improvement for your particular project. Do not invent your own style. > 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'. This is canonical and is done in all of the various styles I've seen. There are very good reasons for that. (It's more important for function-like macros, where you may need to warn the user that arguments may be evaluated multiple times. OTOH, function-like macros that mask a true function must use the case of the function they mask, but must take care not to do multiple evaluation.) > 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; 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. (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...) Some mixing is unavoidable if you call libraries that use different styles, but don't deliberately make it worse. > 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. Do not go over 80 columns without a very, very good reason. If that presents a serious problem (i.e. more than the occasional complicated function call or if expression), there's probably something wrong with your code anyway. > 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 latter is canonical in all styles. If you use the former, one day you'll write "char* firstName, lastName;" and cause all sorts of problems. > 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." Either put the string inline or use some facility such as gettext(), which is better for later i18n issues anyway. > There are so many style guides out there, most of them say contradictory > things at one point or another. What do the pros do? See comments at top. > 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. If your code will be read by someone else, you want the style to seem familiar enough to them that it won't distract them from being able to read what the code _means_; that generally means picking one of the common styles even if it's not ideal according to your tastes. If you're absolutely sure _nobody_ will _ever_ read your code, do whatever you want--but I'd recommend picking a common style anyway just in case you're wrong. People usually are about such things, eventually. 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: William Hughes on 24 Feb 2010 17:04
On Feb 24, 4:53 pm, 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. You need to fix your misprint. Clearly you meant If you *dont* 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. - William Hughes |