Coding Style

Discussion in 'C++' started by Hal Vaughan, Mar 30, 2008.

  1. Hal Vaughan

    Hal Vaughan Guest

    This is more a style question, so I know it's subjective (I hope I don't
    start a religious war!), but I'm also interested to know if there is a
    trend.

    I've noticed that a lot of C++ code shuns lower case and basically tries to
    keep variables and functions with as short a name as possible (or at least
    one that's easy to type). Functions might be like this:

    getval()
    ldcfg()

    But I've also noticed some code that uses underscores between words:

    get_val()
    ld_cfg()

    And here's the part I'm curious about. It seems to me that more recent code
    seems to have the Java influence and is a bit more focused on readability,
    so it's more like this:

    getVal()
    loadConfig()

    Is it just me, or does it seem that more code is written like this lately?

    I read somewhere that a function name can be 30 characters long but only the
    1st 8 characters had to be unique, but my experience with gcc is that it
    does fine with the 1st 8 chars being the same (just toyed with it). Does
    that have any effect on shorter names or maybe people using different
    styles for names?

    Just wondering...

    Hal
     
    Hal Vaughan, Mar 30, 2008
    #1
    1. Advertising

  2. Hal Vaughan wrote:
    > This is more a style question, so I know it's subjective (I hope I don't
    > start a religious war!), but I'm also interested to know if there is a
    > trend.
    >
    > I've noticed that a lot of C++ code shuns lower case and basically tries to
    > keep variables and functions with as short a name as possible (or at least
    > one that's easy to type). Functions might be like this:
    >
    > getval()
    > ldcfg()
    >
    > But I've also noticed some code that uses underscores between words:
    >
    > get_val()
    > ld_cfg()
    >
    > And here's the part I'm curious about. It seems to me that more recent code
    > seems to have the Java influence and is a bit more focused on readability,
    > so it's more like this:
    >
    > getVal()
    > loadConfig()



    Actually the last is the "camel" style. It goes like GetVal() for
    functions and someVal for variables.
     
    Ioannis Vranos, Mar 30, 2008
    #2
    1. Advertising

  3. Hal Vaughan

    Ian Collins Guest

    Ioannis Vranos wrote:
    > Hal Vaughan wrote:
    >>
    >> And here's the part I'm curious about. It seems to me that more recent code
    >> seems to have the Java influence and is a bit more focused on readability,
    >> so it's more like this:
    >>
    >> getVal()
    >> loadConfig()

    >
    >
    > Actually the last is the "camel" style. It goes like GetVal() for
    > functions and someVal for variables.


    Or getVal() for functions, someVal for variables and SomeClass for classes.

    Style varies between shops, with some influence from the platform
    (GetVal() for functions appears to be common on windows).

    --
    Ian Collins.
     
    Ian Collins, Mar 30, 2008
    #3
  4. Hal Vaughan

    JoeC Guest

    On Mar 30, 4:50 pm, Hal Vaughan <> wrote:
    > This is more a style question, so I know it's subjective (I hope I don't
    > start a religious war!), but I'm also interested to know if there is a
    > trend.
    >
    > I've noticed that a lot of C++ code shuns lower case and basically tries to
    > keep variables and functions with as short a name as possible (or at least
    > one that's easy to type). Functions might be like this:
    >
    > getval()
    > ldcfg()
    >
    > But I've also noticed some code that uses underscores between words:
    >
    > get_val()
    > ld_cfg()
    >
    > And here's the part I'm curious about. It seems to me that more recent code
    > seems to have the Java influence and is a bit more focused on readability,
    > so it's more like this:
    >
    > getVal()
    > loadConfig()
    >
    > Is it just me, or does it seem that more code is written like this lately?
    >
    > I read somewhere that a function name can be 30 characters long but only the
    > 1st 8 characters had to be unique, but my experience with gcc is that it
    > does fine with the 1st 8 chars being the same (just toyed with it). Does
    > that have any effect on shorter names or maybe people using different
    > styles for names?
    >
    > Just wondering...
    >
    > Hal


    I can say that I write larger programs and I try to keep names as
    short as possible because it is blatantly less typing and less chance
    of error. I personally like one word or I like twoWords. I don't
    like to get too much longer than that. There is a question of
    readability and going back to some code after some time. It does get
    bad and some of the criptic var names can get confusing. Take time
    write code and large programs and find a system that works for you.
    Long ariable names get tedious to type especialy if you have to keep
    writing them:

    bitData[index++] = binTemp[0*(cur+number)] *
    128 + binTemp[1*(cur+number)] *
    64 + binTemp[2*(cur+number)] *
    32 + binTemp[3*(cur+number)] *
    16 + binTemp[4*(cur+number)] *
    8 + binTemp[5*(cur+number)] *
    4 + binTemp[6*(cur+number)] *
    2 + binTemp[7*(cur+number)];
     
    JoeC, Mar 31, 2008
    #4
  5. Hal Vaughan

    James Kanze Guest

    On Mar 30, 11:50 pm, Hal Vaughan <> wrote:
    > This is more a style question, so I know it's subjective (I
    > hope I don't start a religious war!), but I'm also interested
    > to know if there is a trend.


    > I've noticed that a lot of C++ code shuns lower case and
    > basically tries to keep variables and functions with as short
    > a name as possible (or at least one that's easy to type).


    You mean shuns upper case, of course. This corresponds more or
    less to the oldest traditions in C. (If you've ever listended
    to the output of a source listing on a teletype, you know why
    they wanted to keep the number of characters to a minimum:).)
    I've not seen it much in C++, except when interfacing with
    older, C libraries. Even in C, today, the tendency is to use
    more readable names---compare the names in the more recent parts
    of Posix (e.g. pthread_mutex_lock) with those from the orginal
    Unix (e.g. ioctl), for example.

    > Functions might be like this:


    > getval()
    > ldcfg()


    > But I've also noticed some code that uses underscores between words:


    > get_val()
    > ld_cfg()


    > And here's the part I'm curious about. It seems to me that
    > more recent code seems to have the Java influence and is a bit
    > more focused on readability,


    It's not Java influenced, and it's not particularly recent.
    There are a number of variations in the different conventions,
    but one main division is how you separate words in a symbol:
    with an underscore, or by starting each word within the symbol
    with a capital letter. The difference in readability is minor
    (and IMHO probably favors the underscore). The two traditions
    seem to come from different sources: most of the CCITT
    specifications used capital letters (the so-called CamelCase),
    so companies involved in any way with telephone systems tended
    to adopt that, going back to the mid 1980's, at least. There
    might have been other sources as well, since I don't think Java
    was connected with telephone systems at its beginnings, and it
    got it from somewhere as well.

    > so it's more like this:


    > getVal()
    > loadConfig()


    In modern C++, I'd expect to see getValue() and
    loadConfiguration() (or get_value() and load_configuration()).
    Use of arbitrary abbreviations more or less went out with the
    teletype. Other than that, all of the conventions require macro
    names to be all caps, with an underscore between words, and all
    modern conventions forbid anything else from being all caps
    (with the frequent exception of single letter type argument
    names to templates).

    > Is it just me, or does it seem that more code is written like
    > this lately?


    If by lately, you means since around 1990, maybe.

    > I read somewhere that a function name can be 30 characters
    > long but only the 1st 8 characters had to be unique, but my
    > experience with gcc is that it does fine with the 1st 8 chars
    > being the same (just toyed with it).


    C and C++ have always allowed unlimited length in symbol names.
    Early C did limit how many characters were significant, however,
    with 31 (I think) internally, but only the first six guaranteed
    accross modules (and no guarantee of case significance either).
    Implementations have always been allowed to support more (and
    I've never seen a C implementation which didn't support at least
    eight externally). The current C standard requires 63
    significant characters internally, and 31 externally (with case
    always significant). C++ makes no absolute limit, but
    recommends at least 1024 both internally and externally.

    > Does that have any effect on shorter names or maybe people
    > using different styles for names?


    Not today.

    --
    James Kanze (GABI Software) email:
    Conseils en informatique orientée objet/
    Beratung in objektorientierter Datenverarbeitung
    9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
     
    James Kanze, Mar 31, 2008
    #5
  6. Hal Vaughan

    James Kanze Guest

    On Mar 31, 12:14 am, Ian Collins <> wrote:
    > Ioannis Vranos wrote:
    > > Hal Vaughan wrote:


    > >> And here's the part I'm curious about. It seems to me that
    > >> more recent code seems to have the Java influence and is a
    > >> bit more focused on readability, so it's more like this:


    > >> getVal()
    > >> loadConfig()


    > > Actually the last is the "camel" style. It goes like GetVal() for
    > > functions and someVal for variables.


    > Or getVal() for functions, someVal for variables and SomeClass
    > for classes.


    > Style varies between shops, with some influence from the
    > platform (GetVal() for functions appears to be common on
    > windows).


    First, it's getValue() and loadConfiguration(). Modern
    conventions eschew obfuscating abbreviations. Beyond that, it
    probably depends on the ultimate source of the convention.
    (Microsoft didn't invent anything here.) CCITT (one important
    source for CamelCase), for example, used the convention that
    typenames start with a capital letter, everything else with a
    small. Convensions which have been taken over from earlier,
    non-OO languages, where you don't have user defined types, might
    very well adopt the convention of functions with a capital
    letter, since they don't have any other important distinction.
    (IMHO, the distinction between types and non-types is primordial
    in C++, since it affects how a statement is parsed.)

    --
    James Kanze (GABI Software) email:
    Conseils en informatique orientée objet/
    Beratung in objektorientierter Datenverarbeitung
    9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
     
    James Kanze, Mar 31, 2008
    #6
  7. In article <>,
    JoeC <> wrote:
    >On Mar 30, 4:50 pm, Hal Vaughan <> wrote:
    >> This is more a style question, so I know it's subjective (I hope I don't
    >> start a religious war!), but I'm also interested to know if there is a
    >> trend.
    >>
    >> I've noticed that a lot of C++ code shuns lower case and basically tries to
    >> keep variables and functions with as short a name as possible (or at least
    >> one that's easy to type). Functions might be like this:
    >>

    [...chop chop]
    >> And here's the part I'm curious about. It seems to me that more recent code
    >> seems to have the Java influence and is a bit more focused on readability,
    >> so it's more like this:


    I think the recent focus on readability is simply because programmers
    have understood the cost of unreadable code better.

    I am sorry but I have to disagree with the advice and justification below:

    >I can say that I write larger programs and I try to keep names as
    >short as possible because it is blatantly less typing


    Correct. This is less typing.

    However:

    How much of your programming time is spent typing? (hopefully only a
    small percentage)
    Do you type that slowly?
    Can't you paste a long variable name from just above?
    Have you considered IDEs/editors with auto-completion?

    > and less chance of error.


    Huh? Why? How? Less chances of inconsequential typos, maybe assuming
    that the probability of typo is directly proportional to the number of
    letters but less chance of a real error (i.e. a bug): no
    Two identifiers that differ only by one letter are much more likely to
    be confused or mistyped than clearly worded identifiers.

    e.g.:
    ldCg() vs loadConfig()
    ldPg() vs loadPage()

    In the first case, the likelyhood that one mistype the identifier and
    that this isn't picked by the compiler is quite high. This is also
    likely to be overlooked by glancing over the code. There is a high
    risk of it getting out of the door as a bug.

    In the second case, if you do a typo, the compiler will issue an error
    so be almost immediately noticed and fixed by the developer.

    >I personally like one word or I like twoWords. I don't
    >like to get too much longer than that. There is a question of
    >readability and going back to some code after some time. It does get
    >bad and some of the criptic var names can get confusing. Take time
    >write code and large programs and find a system that works for you.
    >Long ariable names get tedious to type especialy if you have to keep
    >writing them:


    You yourself have noticed that readability is poor when you are going
    going back to go you have written yourself a little while ago.
    This is code you have written yourself, using your personal
    style and you do have some recollection of it and you still find it
    hard to maintain. If you would have to go and maintain code that
    someone else who has a different style has written 2 years ago and has
    now left the company, then the maintainability problems would be
    ten time worse.

    Also if you are writing code only for yourself, never to publish,
    never to be seen by anyone else, "what works for you" might be
    acceptable, but if you ever are going to be part of a team and/or
    publish code, you should write code that is readable by others too.
    Even if you are not currently writing code that get seen by others, it
    is a good habit to take to write it as if it was going to be
    maintained by someone else.

    There's a quote about it:
    "Always program as if your code was to be maintained by a dangerous
    psychopath who knows where you live."

    The part where I will agree is that overly long name do reduce
    readability. So:

    loadConfigFileFromHardDisk() vs loadConfig()

    The former is less readable and probably obfuscate by mentionning
    unimportant information.

    >
    > bitData[index++] = binTemp[0*(cur+number)] *
    > 128 + binTemp[1*(cur+number)] *
    > 64 + binTemp[2*(cur+number)] *
    > 32 + binTemp[3*(cur+number)] *
    > 16 + binTemp[4*(cur+number)] *
    > 8 + binTemp[5*(cur+number)] *
    > 4 + binTemp[6*(cur+number)] *
    > 2 + binTemp[7*(cur+number)];


    This example is fine. But this is typically a small loop. My loop
    index tend to be called "i". I don't see any advantages to using
    "index" because it is:
    a) such an accepted usage
    b) very local scope, only inside the loop
    c) declare and initialised just a few lines above and going out of
    scope by the end of the scree

    Howver, global variables will have a much longer much more explicit
    name. Same for methods, the method name will give the user a good
    idea of what it does (the contract).

    Yannick
     
    Yannick Tremblay, Mar 31, 2008
    #7
  8. Hal Vaughan

    JoeC Guest

    On Mar 31, 7:28 am, (Yannick Tremblay) wrote:
    > In article <>,
    >
    > JoeC <> wrote:
    > >On Mar 30, 4:50 pm, Hal Vaughan <> wrote:
    > >> This is more a style question, so I know it's subjective (I hope I don't
    > >> start a religious war!), but I'm also interested to know if there is a
    > >> trend.

    >
    > >> I've noticed that a lot of C++ code shuns lower case and basically tries to
    > >> keep variables and functions with as short a name as possible (or at least
    > >> one that's easy to type). Functions might be like this:

    >
    > [...chop chop]
    > >> And here's the part I'm curious about. It seems to me that more recent code
    > >> seems to have the Java influence and is a bit more focused on readability,
    > >> so it's more like this:

    >
    > I think the recent focus on readability is simply because programmers
    > have understood the cost of unreadable code better.
    >
    > I am sorry but I have to disagree with the advice and justification below:
    >
    > >I can say that I write larger programs and I try to keep names as
    > >short as possible because it is blatantly less typing

    >
    > Correct. This is less typing.
    >
    > However:
    >
    > How much of your programming time is spent typing? (hopefully only a
    > small percentage)
    > Do you type that slowly?
    > Can't you paste a long variable name from just above?
    > Have you considered IDEs/editors with auto-completion?
    >
    > > and less chance of error.

    >
    > Huh? Why? How? Less chances of inconsequential typos, maybe assuming
    > that the probability of typo is directly proportional to the number of
    > letters but less chance of a real error (i.e. a bug): no
    > Two identifiers that differ only by one letter are much more likely to
    > be confused or mistyped than clearly worded identifiers.
    >
    > e.g.:
    > ldCg() vs loadConfig()
    > ldPg() vs loadPage()
    >
    > In the first case, the likelyhood that one mistype the identifier and
    > that this isn't picked by the compiler is quite high. This is also
    > likely to be overlooked by glancing over the code. There is a high
    > risk of it getting out of the door as a bug.
    >
    > In the second case, if you do a typo, the compiler will issue an error
    > so be almost immediately noticed and fixed by the developer.
    >
    > >I personally like one word or I like twoWords. I don't
    > >like to get too much longer than that. There is a question of
    > >readability and going back to some code after some time. It does get
    > >bad and some of the criptic var names can get confusing. Take time
    > >write code and large programs and find a system that works for you.
    > >Long ariable names get tedious to type especialy if you have to keep
    > >writing them:

    >
    > You yourself have noticed that readability is poor when you are going
    > going back to go you have written yourself a little while ago.
    > This is code you have written yourself, using your personal
    > style and you do have some recollection of it and you still find it
    > hard to maintain. If you would have to go and maintain code that
    > someone else who has a different style has written 2 years ago and has
    > now left the company, then the maintainability problems would be
    > ten time worse.
    >
    > Also if you are writing code only for yourself, never to publish,
    > never to be seen by anyone else, "what works for you" might be
    > acceptable, but if you ever are going to be part of a team and/or
    > publish code, you should write code that is readable by others too.
    > Even if you are not currently writing code that get seen by others, it
    > is a good habit to take to write it as if it was going to be
    > maintained by someone else.
    >
    > There's a quote about it:
    > "Always program as if your code was to be maintained by a dangerous
    > psychopath who knows where you live."
    >
    > The part where I will agree is that overly long name do reduce
    > readability. So:
    >
    > loadConfigFileFromHardDisk() vs loadConfig()
    >
    > The former is less readable and probably obfuscate by mentionning
    > unimportant information.
    >
    >
    >
    > > bitData[index++] = binTemp[0*(cur+number)] *
    > > 128 + binTemp[1*(cur+number)] *
    > > 64 + binTemp[2*(cur+number)] *
    > > 32 + binTemp[3*(cur+number)] *
    > > 16 + binTemp[4*(cur+number)] *
    > > 8 + binTemp[5*(cur+number)] *
    > > 4 + binTemp[6*(cur+number)] *
    > > 2 + binTemp[7*(cur+number)];

    >
    > This example is fine. But this is typically a small loop. My loop
    > index tend to be called "i". I don't see any advantages to using
    > "index" because it is:
    > a) such an accepted usage
    > b) very local scope, only inside the loop
    > c) declare and initialised just a few lines above and going out of
    > scope by the end of the scree
    >
    > Howver, global variables will have a much longer much more explicit
    > name. Same for methods, the method name will give the user a good
    > idea of what it does (the contract).
    >
    > Yannick


    Good advice. I have never worked as a team I only program for
    myself. I would really like to be part of a team but I don't know
    anyone who programs to work with. I don't like very long variable
    names but I do try to do a better job for readability. I do cut and
    paste at times. I try to stick to convention which I find more
    important than length. That is get functions getVar, num cur, I
    gneraly use l lp lp2 I am also trying to get use acc and dwn for x
    and y which often times I mess up.
     
    JoeC, Apr 2, 2008
    #8
    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. Paul Baxter

    style for coding latches

    Paul Baxter, Aug 10, 2003, in forum: VHDL
    Replies:
    7
    Views:
    1,166
    Mike Treseler
    Aug 15, 2003
  2. Willem Oosthuizen

    Coding style to prioritize certain inputs

    Willem Oosthuizen, Sep 2, 2003, in forum: VHDL
    Replies:
    5
    Views:
    512
    Mike Treseler
    Sep 4, 2003
  3. Analog Guy

    Coding style for CPLD vs FPGA

    Analog Guy, Mar 11, 2005, in forum: VHDL
    Replies:
    3
    Views:
    5,511
    Klaus Falser
    Mar 14, 2005
  4. calmar
    Replies:
    11
    Views:
    952
    calmar
    Feb 21, 2006
  5. Ken Varn
    Replies:
    0
    Views:
    531
    Ken Varn
    Apr 26, 2004
Loading...

Share This Page