Stylistic questions on UNIX C coding.

Discussion in 'C Programming' started by Poster Matt, Feb 24, 2010.

  1. Poster Matt

    Poster Matt Guest

    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.
     
    Poster Matt, Feb 24, 2010
    #1
    1. Advertising

  2. On Feb 24, 1:35 pm, Poster Matt <postermatt@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.
     
    Julienne Walker, Feb 24, 2010
    #2
    1. Advertising

  3. Poster Matt

    Fred Guest

    On Feb 24, 11:10 am, Julienne Walker <> wrote:
    > On Feb 24, 1:35 pm, Poster Matt <postermatt@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
     
    Fred, Feb 24, 2010
    #3
  4. Poster Matt

    James Harris Guest

    On 24 Feb, 18:35, Poster Matt <postermatt@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
     
    James Harris, Feb 24, 2010
    #4
  5. Poster Matt

    Lew Pitcher Guest

    On February 24, 2010 13:35, in comp.lang.c, postermatt@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. ------
     
    Lew Pitcher, Feb 24, 2010
    #5
  6. Poster Matt

    Seebs Guest

    On 2010-02-24, Poster Matt <postermatt@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 /
    http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
    http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
     
    Seebs, Feb 24, 2010
    #6
  7. Poster Matt

    Rich Webb Guest

    On Wed, 24 Feb 2010 11:10:21 -0800 (PST), Julienne Walker
    <> wrote:

    >On Feb 24, 1:35 pm, Poster Matt <postermatt@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
     
    Rich Webb, Feb 24, 2010
    #7
  8. On Feb 24, 2:21 pm, Fred <> wrote:
    > On Feb 24, 11:10 am, Julienne Walker <> wrote:
    > > On Feb 24, 1:35 pm, Poster Matt <postermatt@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.
     
    Julienne Walker, Feb 24, 2010
    #8
  9. Poster Matt

    Eric Sosman Guest

    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
    lid
     
    Eric Sosman, Feb 24, 2010
    #9
  10. Poster Matt <postermatt@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.
     
    Rainer Weikusat, Feb 24, 2010
    #10
  11. Poster Matt <postermatt@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) <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"
     
    Keith Thompson, Feb 24, 2010
    #11
  12. Poster Matt

    BruceS Guest

    On Feb 24, 12:32 pm, Seebs <> wrote:
    > On 2010-02-24, Poster Matt <postermatt@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.
     
    BruceS, Feb 24, 2010
    #12
  13. Rainer Weikusat <> writes:
    > Poster Matt <postermatt@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) <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"
     
    Keith Thompson, Feb 24, 2010
    #13
  14. Poster Matt

    James Harris Guest

    On 24 Feb, 20:53, BruceS <> 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!
     
    James Harris, Feb 24, 2010
    #14
  15. On Feb 24, 2:35 pm, Poster Matt <postermatt@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.
     
    William Hughes, Feb 24, 2010
    #15
  16. In article <>, Seebs <> writes:
    > On 2010-02-24, Poster Matt <postermatt@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
    <>, CamelCase and co. originate from
    much earlier. (Thanks for the interesting historical tidbit, Rainer!)

    Cheers,
    lacos
     
    Ersek, Laszlo, Feb 24, 2010
    #16
  17. In article <>, James Harris <> writes:
    > On 24 Feb, 20:53, BruceS <> 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
     
    Ersek, Laszlo, Feb 24, 2010
    #17
  18. 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
     
    Stephen Sprunk, Feb 24, 2010
    #18
  19. Stephen Sprunk <> writes:
    > On 24 Feb 2010 12:35, Poster Matt wrote:

    [...]
    >> 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.


    His convention apparently is to use camelCase for variables and
    PascalCase for functions. It's not necessarily a style I'd use, but
    it's not obviously horrible (and it's more or less the style I use
    at work). As with most of these rules, conforming to existing code
    is far more important than any benefits of one style over another.
    I really dislike the brace placement of the code I work on, but
    mixing my own style into it would be far worse (and wouldn't survive
    a code review anyway).

    > (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...)


    Again, This_Type_Of_Identifier isn't obviously horrible. (I use it
    myself, though not in C.)

    [...]

    --
    Keith Thompson (The_Other_Keith) <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"
     
    Keith Thompson, Feb 24, 2010
    #19
  20. On Feb 24, 4:53 pm, BruceS <> 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
     
    William Hughes, Feb 24, 2010
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. P.Hill
    Replies:
    13
    Views:
    565
    Adam Maass
    Apr 23, 2004
  2. Denis Remezov
    Replies:
    4
    Views:
    483
    Siemel Naran
    Apr 30, 2004
  3. Mantorok Redgormor

    stylistic prototype question

    Mantorok Redgormor, Oct 29, 2003, in forum: C Programming
    Replies:
    5
    Views:
    365
    Mark A. Odell
    Oct 30, 2003
  4. Andrew Koenig

    Stylistic question about inheritance

    Andrew Koenig, Mar 31, 2005, in forum: Python
    Replies:
    17
    Views:
    496
    Guy Bolton King
    Apr 1, 2005
  5. Mark Healey

    A stylistic question.

    Mark Healey, May 14, 2006, in forum: C Programming
    Replies:
    60
    Views:
    1,248
    Jordan Abel
    May 28, 2006
Loading...

Share This Page