Stylistic questions on UNIX C coding.
in [Unix Programming]
|
Prev: integer
Next: shared memory question
From: Poster Matt on 24 Feb 2010 13:35 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'. 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); 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. 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; 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? 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: Julienne Walker on 24 Feb 2010 14:10 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. :) > > 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 merely a convention so that macros are easier to see. If you don't want to follow that convention, feel free. Though keep in mind that conventions are there for a reason. The preprocessor has proven troublesome enough over the years to warrant having macros stand out a bit. ;-) > 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. I see that style often. > 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. > 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. :-) > 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 acceptable. Though keep in mind that in the age of internationalization and localization, hard coding string literals makes your code harder to port to other spoken languages. > There are so many style guides out there, most of them say contradictory things > at one point or another. What do the pros do? The pros are just as contradictory as the style guides. Pick a style you like and run with it, with the caveat that over time your tastes (and as a result, your style) will evolve. > 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. You can make bad code look pretty and it's still bad code. But in my experience, good code has never looked ugly. Good aesthetics seems to come naturally if you focus on writing the best code possible.
From: Fred on 24 Feb 2010 14:21 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: > > > 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 merely a convention so that macros are easier to see. If > you don't want to follow that convention, feel free. Though keep in > mind that conventions are there for a reason. The preprocessor has > proven troublesome enough over the years to warrant having macros > stand out a bit. ;-) > > > 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. I see that style often. > > > 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. > > > 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. In C, the asterisk is associated with the variable name, not the type specifier. I've seen this so many times: char* x, y; Here, x a pointer to char, but y is a char. Much clearer to show what you really intended: char *x, *y; /* Both pointers */ or char *x, y; /* One a pointer, one not */ >(snip) -- Fred K
From: James Harris on 24 Feb 2010 14:29 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.... > 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. Indeed if we change them to parameters in a function call they lose upper case status. 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. Many libraries use all caps for their constants. You could also define constants in enums rather than in #defines. > > 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? You'll probably get advised to stick to whatever coding standards your project team members use. Also, when changing someone else's code, stick to the standards used therein. For your own projects you could use first_name firstname FirstName firstName > 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. Again, use existing coding standards if there are any. My monitor is also wide but I prefer to keep to 80-columns because you never know what size monitor the code will subsequently be edited on. > > 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 normally as the latter due to char* FirstName, ch, *p; char *FirstName, ch, *p; Regardless of which form is used I think only ch will be a char variable - i.e. "char*" can be misleading. The other variables will be pointers. Someone will correct me if I'm wrong. Though you are right in principle, C does not cleanly segregate type and name. For example int func(int); This declares the name func but the type information is scattered all over such declarations. > 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. You may need a way to include variable values in your messages. > > There are so many style guides out there, most of them say contradictory things > at one point or another. What do the pros do? > > 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 James
From: Lew Pitcher on 24 Feb 2010 14:29
On February 24, 2010 13:35, in comp.lang.c, 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'. CamelCase is acceptable, with the caveat that the programmer (you, or whomever reads your code) should be able to distinguish the difference between a macro and a variable. > 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); Again, CamelCase is acceptable. > 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. Somewhere around 80 characters per line is the norm. That facilitates both on-screen review and editing as well as printing and emailing of code. > 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; That's acceptable, but prone to error. Given char* firstName lastName; what is the type of <lastName>? If you read the declaration and answered that <lastName> is of char* type, then you would be wrong. The language groups type modifiers to the defined object, and not to the base type. Visually grouping the modifiers contrary to how the language groups them can lead to programmer mis-interpretation and error. > 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." Most development groups I've worked with would find that practice acceptable. > There are so many style guides out there, most of them say contradictory > things at one point or another. What do the pros do? Usually, the pros do what the other pros that they are working with do. Computer languages are a convenience to the /programmer/, not to the computer. The rules (both at a language level, and at a developer level) are set to make it easy for a programmer to write code, and for other programmers to read (and often rewrite) it. So long as you apply your style rules consistently (so that there are no unexpected deviations), things should work out. > 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. /Which/ "UNIX C community"? Some communities have their own coding styles ("the one true style", or the K&R style, or the "Linux Kernel stye", for instance), and no one set of rules will make your code acceptable to all of the communities out there. The best I can give you is to a) be consistant, and b) be simple in your coding. Don't do the unexpected; once you've established a pattern, stick with it until there is good reason to change. Document the change ahead of time. Don't over-complicate things. The point is to make your code easy to read and understand at the /human/ level. > Thanks and regards, etc. -- Lew Pitcher Master Codewright & JOAT-in-training | Registered Linux User #112576 Me: http://pitcher.digitalfreehold.ca/ | Just Linux: http://justlinux.ca/ ---------- Slackware - Because I know what I'm doing. ------ |