Stylistic questions on UNIX C coding.
in [Unix Programming]
|
Prev: integer
Next: shared memory question
From: Seebs on 24 Feb 2010 14:32 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". > 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); Also, "Num" doesn't need to be there. > 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. > 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. > 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. > 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 use the Linux kernel style guide and/or the BSD style guide, which are basically compatible. Ignore the GNU coding standards, they're awful. > 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. It's a good effort. I do have to say, though... 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? -s -- Copyright 2010, all wrongs reversed. Peter Seebach / usenet-nospam(a)seebs.net http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
From: Julienne Walker on 24 Feb 2010 14:42 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.
From: Rich Webb on 24 Feb 2010 14:35 On Wed, 24 Feb 2010 11:10:21 -0800 (PST), Julienne Walker <happyfrosty(a)hotmail.com> wrote: >On Feb 24, 1: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. :) >> 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. > >I try to keep each line under 100 characters (80 if possible). It's >less about monitor size than it is about easily reading my code at a >glance. Typographers, who study this thing with the fervor that programmers bring to brace styles, would tend to agree. There are always reasonable exceptions but a line length that's 70-80 characters (monospaced) seems to be a sweet spot for comprehension. >> 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 there's the danger in having one's thoughts focused elsewhere when adding the next piece, and getting char* firstName, lastName; -- Rich Webb Norfolk, VA
From: Eric Sosman on 24 Feb 2010 14:50 On 2/24/2010 1:35 PM, Poster Matt 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'. All-caps is one of those conventions that's widely adopted, although there's no inherent linguisic necessity for it (indeed, some macros required by the C Standard itself are lower-case). People are accustomed to seeing macro names in upper-case only, and since macros can look like functions but behave differently (consider `x = MIN(y,z)' vs `x = MIN(y, f_with_side_effects())'), the coder must sometimes know which is being used. Recommendation: Stick with upper-case macro names to forestall confusion. > 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); Use whatever works for you, and for the others who read the same body of code. If you're working on existing code, stay with whatever conventions it already uses. If you're writing new code (that's not in association with existing code), use what you like. > 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. Really long lines -- especially in blocks that cover several consecutive lines -- can be hard to read because the eye may have trouble maintaining vertical "registration" while flipping back and forth between the end of one line and the start of the next -- oh, damn, I skipped down two again! Usual practice is to use narrower lines than yours, allowing the line to be seen as a whole rather than traced out in multiple horizontal jumps. Seventy to eighty characters are a typical length (although that range is in part due to hysterical raisins). > 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; If you're firm about declaring only one identifier per line, this is fine. But the minute you write char* firstPtr, finalPtr; .... you're going to be unpleasantly surprised. > 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." This could turn out to be helpful in translating the messages someday: "Das Verzeichnis wurde nicht gefunden." On the other hand, there are more flexible ways to deal with this than to compile separate versions for German, French, Klingon, ... > There are so many style guides out there, most of them say contradictory > things at one point or another. What do the pros do? Contradict each other, of course! Why did you ask? > 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. From the Eighth Commandment: "... thy creativity is better used in solving problems than in creating beautiful new impediments to understanding." The Commandment speaks of brace styles, but the point applies with equal force to other stylistic choices. -- Eric Sosman esosman(a)ieee-dot-org.invalid
From: Chris Friesen on 24 Feb 2010 15:02
On 02/24/2010 12:35 PM, Poster Matt wrote: > Hi, > > I've a few questions concerning style when programming C on UNIX systems. I > don't want to look like an amateur. :) > There are so many style guides out there, most of them say contradictory things > at one point or another. What do the pros do? Your questions are valid, but the real answer is that it totally depends on the project. If you're contributing to an existing project then you should follow the coding standards already in place. If you're starting something totally new, you can do whatever you want. That said, most people will be familiar with a few of of the main standard styles: linux kernel, K&R, GNU, etc. It may make sense to pick one of those that closest matches your preferred style. I spend most of my time in the kernel, so my answers would be: 1) #defines should be uppercase and words separated with underscores. Uppercase is also used for enums and name-prefixes that follow a uniform convention. 1a) Using CamelCase (aka StudlyCaps) is frowned upon partly because it means that the word-based commands in various editors (emacs, for instance) don't work properly. 2) lowercase everything separated by underscores 3) max line length is 80 char 4) pointer * is next to variable 5) error messages are in the code explicitly Chris |