Caps convention.

Discussion in 'C Programming' started by Malcolm, Dec 20, 2003.

  1. Malcolm

    Malcolm Guest

    Use all lower case for ansi c functions, and Capitalise For
    Platform-Specific.

    If you call something with caps, then your function name requires caps
    itself.
     
    Malcolm, Dec 20, 2003
    #1
    1. Advertising

  2. Malcolm

    Jack Klein Guest

    Jack Klein, Dec 20, 2003
    #2
    1. Advertising

  3. Malcolm wrote:
    > Use all lower case for ansi c functions, and Capitalise For
    > Platform-Specific.
    >
    > If you call something with caps, then your function name requires caps
    > itself.


    The common style is to use all-caps for constants and macros.
    Function name styles differ:
    leading word starts lowercase followed by Capitalized words:
    thisIsMyFunction
    same thing, using underscores:
    this_Was_My_Function
    starting with Captials:
    ThisIsAnotherFunction
    This_May_Be_More_Readable
    as you suggested:
    anansicfunction
    another_ansi_function

    However, most all good coding styles don't permit function names
    to start with '_' (underscores) as these are reserved for
    implementations.

    This is a religous issue: all a matter of faith. As long as you
    are consistent and the names are readble, any style will do. Just
    as there is no best religion, there is no best coding style.

    --
    Thomas Matthews

    C++ newsgroup welcome message:
    http://www.slack.net/~shiva/welcome.txt
    C++ Faq: http://www.parashift.com/c -faq-lite
    C Faq: http://www.eskimo.com/~scs/c-faq/top.html
    alt.comp.lang.learn.c-c++ faq:
    http://www.raos.demon.uk/acllc-c /faq.html
    Other sites:
    http://www.josuttis.com -- C++ STL Library book
    http://www.sgi.com/tech/stl -- Standard Template Library
     
    Thomas Matthews, Dec 20, 2003
    #3
  4. Thomas Matthews wrote:
    > Malcolm wrote:
    >
    >> Use all lower case for ansi c functions
    >> and Capitalize For Platform-Specific.
    >>
    >> If you call something with caps,
    >> then your function name requires caps itself.


    No!
    That would imply that your API *depends* upon
    details of its implementation.

    > The common style is to use all-caps for constants and macros.


    This is an anachronism.

    > Function name styles differ:
    > leading word starts lowercase followed by Capitalized words:
    > thisIsMyFunction
    > same thing, using underscores:
    > this_Was_My_Function
    > starting with Captials:
    > ThisIsAnotherFunction
    > This_May_Be_More_Readable
    > as you suggested:
    > anansicfunction
    > another_ansi_function


    These aren't really styles. The are typing shortcuts
    for programmers with a missing shift key.
    The idea was that because capital letters and underscore
    required the programmer to hold down the shift key,
    they slowed down typing (meaning productivity).
    The first style above is a compromise
    between readability and typing efficiency.

    > However, most all good coding styles
    > don't permit function names to start with '_' (underscores)
    > as these are reserved for implementations.


    Again, this rule has nothing to do with style.
    It's just a way to avoid conflicts with the implementation.

    > This is a religious issue: all a matter of faith.
    > As long as you are consistent and the names are readable,
    > any style will do.
    > Just as there is no best religion, there is no best coding style.


    Yes, but no "true believer" will agree with you.
     
    E. Robert Tisdale, Dec 20, 2003
    #4
  5. Malcolm wrote:

    > Use all lower case for ansi c functions, and Capitalise For
    > Platform-Specific.
    >
    > If you call something with caps, then your function name requires caps
    > itself.


    Taken to its logical conclusion, this requires you to define your entry
    point as Main() - and then it won't link.

    Duh.

    --
    Richard Heathfield :
    "Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
    C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
    K&R answers, C books, etc: http://users.powernet.co.uk/eton
     
    Richard Heathfield, Dec 20, 2003
    #5
  6. On Sat, 20 Dec 2003, Richard Heathfield wrote:
    >
    > Malcolm wrote:
    > >
    > > Use all lower case for [ANSI C] functions, and Capitalise For
    > > Platform-Specific.
    > >
    > > If you call something with caps, then your function name requires caps
    > > itself.

    >
    > Taken to its logical conclusion, this requires you to define your entry
    > point as Main() - and then it won't link.


    Only if your main function is Platform-Specific. And in that case
    it's off-topic for comp.lang.c anyway, and if you do post it,
    *no matter* the capitalization, all you'll get are smiley posts
    claiming that it won't link on [your OS here]. No harm, no foul.
    (-:

    FWIW, except for Malcolm's miscapitalization of the terms "ANSI C",
    I basically agree with his statement. I just don't think it really
    needed to be broadcast to the world, any more than it would be
    appropriate to start a new thread in alt.usage.english to say,
    "Start a new paragraph when there's a new speaker," or in comp.programming
    to point out that the worst-case running time of Quicksort is O(n^2).
    Those who care, already know.

    -Arthur
     
    Arthur J. O'Dwyer, Dec 20, 2003
    #6
  7. begin E. Robert Tisdale:
    > These aren't really styles. The are typing shortcuts
    > for programmers with a missing shift key.
    > The idea was that because capital letters and underscore
    > required the programmer to hold down the shift key,
    > they slowed down typing (meaning productivity).


    And how do you get an underscore without pressing shift?

    --
    Für Google, Tux und GPL!
     
    Alexander Bartolich, Dec 20, 2003
    #7
  8. Malcolm

    Malcolm Guest

    "Richard Heathfield" <> wrote in message
    > Taken to its logical conclusion, this requires you to define your entry
    > point as Main() - and then it won't link.
    >
    > Duh.
    >

    So this is an issue for comp.std.c. If programs beginning main() were
    constrained to be portable ANSI C, whilst platform-specific can start
    Main(), then this is a powerful incentive for people to write portable
    programs.

    Actually main() is often not the entry point for non-ANSI programs.
     
    Malcolm, Dec 20, 2003
    #8
  9. Arthur J. O'Dwyer wrote:
    > On Sat, 20 Dec 2003, Richard Heathfield wrote:
    >> Malcolm wrote:
    >> >
    >> > Use all lower case for [ANSI C] functions, and Capitalise For
    >> > Platform-Specific.
    >> >
    >> > If you call something with caps, then your function name requires caps
    >> > itself.

    >>
    >> Taken to its logical conclusion, this requires you to define your entry
    >> point as Main() - and then it won't link.

    >
    > Only if your main function is Platform-Specific.


    Or if it /calls/ something Platform-Specific, according to Malcolm.

    <snip>

    > FWIW, except for Malcolm's miscapitalization of the terms "ANSI C",
    > I basically agree with his statement. I just don't think it really
    > needed to be broadcast to the world, any more than it would be
    > appropriate to start a new thread in alt.usage.english to say,
    > "Start a new paragraph when there's a new speaker," or in comp.programming
    > to point out that the worst-case running time of Quicksort is O(n^2).
    > Those who care, already know.


    Quite so. But since we're being so public about it at present, my own
    preference is xyz_CamelCase for function names and parameter names in the
    xyz library (or, perhaps, the library for which xyz is a suitable
    contraction or abbreviation), SEPARATED_UPPER_CASE for type names and
    macros, and whatever I feel like for local identifiers.

    --
    Richard Heathfield :
    "Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
    C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
    K&R answers, C books, etc: http://users.powernet.co.uk/eton
     
    Richard Heathfield, Dec 20, 2003
    #9
  10. "E. Robert Tisdale" <> writes:
    [...]
    > > The common style is to use all-caps for constants and macros.

    >
    > This is an anachronism.


    Since when?

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    San Diego Supercomputer Center <*> <http://www.sdsc.edu/~kst>
    Schroedinger does Shakespeare: "To be *and* not to be"
    (Note new e-mail address)
     
    Keith Thompson, Dec 20, 2003
    #10
  11. On 20 Dec 2003 20:15:59 GMT, in comp.lang.c , Alexander Bartolich
    <> wrote:

    >begin E. Robert Tisdale:
    >> These aren't really styles. The are typing shortcuts
    >> for programmers with a missing shift key.
    >> The idea was that because capital letters and underscore
    >> required the programmer to hold down the shift key,
    >> they slowed down typing (meaning productivity).

    >
    >And how do you get an underscore without pressing shift?


    By using the right keyboard. Not all keyboards have the same layout as
    your current (possibly Austrian) one. Some keyboards used to lack the
    angles <>, others lacked square brackets, at signs etc. Some Mac ones
    still do lack a hash #.
    All the world's not a VT102 you know...


    --
    Mark McIntyre
    CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
    CLC readme: <http://www.angelfire.com/ms3/bchambless0/welcome_to_clc.html>


    ----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
    http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
    ---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---
     
    Mark McIntyre, Dec 21, 2003
    #11
  12. begin Mark McIntyre:
    >>And how do you get an underscore without pressing shift?

    >
    > By using the right keyboard. Not all keyboards have the same layout as
    > your current (possibly Austrian) one.


    Nope. I do enjoy fast access to square, curly and angle brackets.

    http://sunsolve.sun.com/handbook_pub/Devices/Input_Device/INPUT_UNIX_Kbd.html

    > [...] All the world's not a VT102 you know...


    In the good old times, when real men wrote their own termcap entries...

    --
    Für Google, Tux und GPL!
     
    Alexander Bartolich, Dec 21, 2003
    #12
  13. On 21 Dec 2003 01:05:35 GMT, in comp.lang.c , Alexander Bartolich
    <> wrote:

    >begin Mark McIntyre:
    >>>And how do you get an underscore without pressing shift?

    >>
    >> By using the right keyboard. Not all keyboards have the same layout as
    >> your current (possibly Austrian) one.

    >
    >Nope. I do enjoy fast access to square, curly and angle brackets.


    If you reread my post, you'll notice that I didn't say whether you
    did, or did not have that. Nor, frankly do I care.

    --
    Mark McIntyre
    CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
    CLC readme: <http://www.angelfire.com/ms3/bchambless0/welcome_to_clc.html>


    ----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
    http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
    ---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---
     
    Mark McIntyre, Dec 21, 2003
    #13
  14. Richard Heathfield wrote:

    >
    > Quite so. But since we're being so public about it at present, my own
    > preference is xyz_CamelCase for function names and parameter names in the
    > xyz library (or, perhaps, the library for which xyz is a suitable
    > contraction or abbreviation), SEPARATED_UPPER_CASE for type names and
    > macros, and whatever I feel like for local identifiers.
    >


    Which reminds me. I wouls like to see namespaces in C. Just a very
    simple thing, nothing very fancy.

    Putting something in a namespace.
    Accessing the namespace explicitly.
    Maybe a way of setting the namespace currently being used.

    As simple as that.

    What do people think?

    --
    Thomas.
     
    Thomas Stegen, Dec 21, 2003
    #14
  15. begin Thomas Stegen:
    > Which reminds me. I wouls like to see namespaces in C.
    > Just a very simple thing, nothing very fancy.


    No, it ain't not simple.

    Eventually all symbols end up in one global scope, the symbol table
    of the linker. C++ uses a technique called mangled names to work
    around this. Think of it as an automatic translation of std::string
    to _std_string or something similar, only that C++ also adds argument
    types to that.

    The net effect are almost unreadable map files, linking problems
    between object code from different compilers, additional syntax to
    switch back to old behaviour (extern "C"), and increased resource
    demands for the linker.

    You can use C++ as A Better C (TM), if you like.
    The ecological niche of C is bare bones programming, though.

    --
    Für Google, Tux und GPL!
     
    Alexander Bartolich, Dec 21, 2003
    #15
  16. begin Mark McIntyre:
    > If you reread my post, you'll notice that I didn't say whether you
    > did, or did not have that. Nor, frankly do I care.


    Thomas Matthews wrote:
    # These aren't really styles. The are typing shortcuts
    # for programmers with a missing shift key.
    # The idea was that because capital letters and underscore
    # required the programmer to hold down the shift key,
    # they slowed down typing (meaning productivity).

    I think that's an urban legend.

    --
    Für Google, Tux und GPL!
     
    Alexander Bartolich, Dec 21, 2003
    #16
  17. Malcolm

    CBFalconer Guest

    Mark McIntyre wrote:
    > <> wrote:
    >

    .... snip ...
    > >
    > > Nope. I do enjoy fast access to square, curly and angle brackets.

    >
    > If you reread my post, you'll notice that I didn't say whether you
    > did, or did not have that. Nor, frankly do I care.


    You cruel unfeeling beast.

    --
    Chuck F () ()
    Available for consulting/temporary embedded and systems.
    <http://cbfalconer.home.att.net> USE worldnet address!
     
    CBFalconer, Dec 21, 2003
    #17
  18. Malcolm

    Joe Wright Guest

    Richard Heathfield wrote:
    >
    > Arthur J. O'Dwyer wrote:
    > > On Sat, 20 Dec 2003, Richard Heathfield wrote:
    > >> Malcolm wrote:
    > >> >
    > >> > Use all lower case for [ANSI C] functions, and Capitalise For
    > >> > Platform-Specific.
    > >> >
    > >> > If you call something with caps, then your function name requires caps
    > >> > itself.
    > >>
    > >> Taken to its logical conclusion, this requires you to define your entry
    > >> point as Main() - and then it won't link.

    > >
    > > Only if your main function is Platform-Specific.

    >
    > Or if it /calls/ something Platform-Specific, according to Malcolm.
    >
    > <snip>
    >
    > > FWIW, except for Malcolm's miscapitalization of the terms "ANSI C",
    > > I basically agree with his statement. I just don't think it really
    > > needed to be broadcast to the world, any more than it would be
    > > appropriate to start a new thread in alt.usage.english to say,
    > > "Start a new paragraph when there's a new speaker," or in comp.programming
    > > to point out that the worst-case running time of Quicksort is O(n^2).
    > > Those who care, already know.

    >
    > Quite so. But since we're being so public about it at present, my own
    > preference is xyz_CamelCase for function names and parameter names in the
    > xyz library (or, perhaps, the library for which xyz is a suitable
    > contraction or abbreviation), SEPARATED_UPPER_CASE for type names and
    > macros, and whatever I feel like for local identifiers.
    >

    If I declare a function..
    void * Malloc(size_t);
    ...the compiler is not confused at all. It knows that Malloc is not
    malloc. But what about the linker? Are the symbols and symbol tables
    used in linking alse case sensitive? Can I declare Malloc in one
    translation unit and define it in another and be ensured that they will
    link?
    --
    Joe Wright http://www.jw-wright.com
    "Everything should be made as simple as possible, but not simpler."
    --- Albert Einstein ---
     
    Joe Wright, Dec 21, 2003
    #18
  19. Joe Wright wrote:

    > Richard Heathfield wrote:
    >>
    >> But since we're being so public about it at present, my own
    >> preference is xyz_CamelCase for function names and parameter names in the
    >> xyz library (or, perhaps, the library for which xyz is a suitable
    >> contraction or abbreviation), SEPARATED_UPPER_CASE for type names and
    >> macros, and whatever I feel like for local identifiers.
    >>

    > If I declare a function..
    > void * Malloc(size_t);
    > ..the compiler is not confused at all. It knows that Malloc is not
    > malloc. But what about the linker? Are the symbols and symbol tables
    > used in linking alse case sensitive? Can I declare Malloc in one
    > translation unit and define it in another and be ensured that they will
    > link?


    In C90, you can't be sure.

    "The implementation may further restrict the significance of an external
    name (an identifier that has external linkage) to six characters and may
    ignore distinctions of alphabetical case for such names."

    ISTR that this restriction has been removed (or at least, /effectively/
    removed) in C99.

    --
    Richard Heathfield :
    "Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
    C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
    K&R answers, C books, etc: http://users.powernet.co.uk/eton
     
    Richard Heathfield, Dec 21, 2003
    #19
  20. Malcolm

    Nudge Guest

    Alexander Bartolich wrote:

    > Thomas Matthews wrote:
    > # These aren't really styles. The are typing shortcuts
    > # for programmers with a missing shift key.
    > # The idea was that because capital letters and underscore
    > # required the programmer to hold down the shift key,
    > # they slowed down typing (meaning productivity).


    It was Tisdale who said that.
     
    Nudge, Dec 21, 2003
    #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. Mikael Petterson

    xsl syntax to generate all caps with _

    Mikael Petterson, Sep 10, 2003, in forum: XML
    Replies:
    3
    Views:
    949
    Dimitre Novatchev
    Sep 11, 2003
  2. Kyle E
    Replies:
    6
    Views:
    285
    Kyle E
    Oct 28, 2003
  3. Robert Brewer

    RE: Simple Problems: Caps and Commas

    Robert Brewer, Oct 27, 2003, in forum: Python
    Replies:
    5
    Views:
    363
  4. darrel
    Replies:
    2
    Views:
    288
    darrel
    Dec 12, 2006
  5. Ben Gun

    small caps

    Ben Gun, Feb 12, 2007, in forum: HTML
    Replies:
    25
    Views:
    1,451
    Bergamot
    Feb 15, 2007
Loading...

Share This Page