Coding styles for C-family languages

Discussion in 'Programming' started by Chaotic42, Jan 19, 2013.

  1. Chaotic42

    Chaotic42 Lifer

    Joined:
    Jun 15, 2001
    Messages:
    30,220
    Likes Received:
    2
    I was looking around online about various coding styles since I'm actually taking a proper programming class instead of trying to patch together various code from various sites to get something working. I don't really have a style, so I figured I'd read up on what people thought was best and why. I'm finding some interesting debates, so I thought I'd ask you guys if there were any specific idioms (I guess that's the right word) that you all use on C, C++, C#, etc.

    The one thing that I found interesting is that people use spaces for indentation instead of tabs. Since I thought this was the entire point of the tab key and since it's customizable in virtually every editor, it seems like a no-brainer to use the tab key. What's your take?

    Also, any thoughts on "Camel Case" vs using tons of underscores? I really like the underscore thing for variables but tend to use Camel Case for objects, since that's how most of the code samples I've seen do it.

    What are your favorite idioms and what other idioms really bug you?
     
  2. Markbnj

    Markbnj Elite Member <br>Moderator Emeritus
    Moderator

    Joined:
    Sep 16, 2005
    Messages:
    15,677
    Likes Received:
    3
    An old, old debate :). Theoretically everyone should use tabs, and then you could set your local indent to what you want it to be. In practice, for whatever reason, it rarely works that way, and instead you end up with your code structure getting mangled on different machines. People who prefer all spaces (me, for one) would rather just have a set format based on the character width.
     
  3. mv2devnull

    mv2devnull Senior member

    Joined:
    Apr 13, 2010
    Messages:
    939
    Likes Received:
    0
    Herb Sutter has published an opinion or two about style and idioms. You may or may not disagree with him.

    Personally, I don't care.
     
  4. Merad

    Merad Platinum Member

    Joined:
    May 31, 2010
    Messages:
    2,470
    Likes Received:
    1
    Main main rules are:

    Class/struct and function names ShouldBeLikeThis
    Prefix virtual function names with a V
    Macros and preprocessor symbols SHOULD_BE_LIKE_THIS
    Variable names shouldBeLikeThis
    Prefix member variables with m_
    Prefix global variables with g_
    Prefix static variables with s_
    Prefix constants and enum values with k_
    Other than the above do not use hungarian
    Braces always go on a new line
    Always use braces, even when optional
    All documentation should be Doxygen compatible
    Try to keep things to < 80 characters per line

    That said you must be flexible. Different languages have different "standard" styles. If I'm writing Java, I write java style. And unless you're the boss, in the real world the odds of you getting everyone you work with to write in your preferred style is just a hair above 0.

    As already said, it just doesn't work out that way. Never really bothered to figure out why. I use 2 spaces per tab.

    Waste_of_space. And it's actually more difficult to read than camelCase IMO.

    The one that irks me most is pointer and reference notation. The * or & is part of the type. There's no logical reason to separate it from the the rest of the type name (eg use int* instead of int *). But that's a losing battle.
     
  5. iCyborg

    iCyborg Golden Member

    Joined:
    Aug 8, 2008
    Messages:
    1,147
    Likes Received:
    1
    It might not be tab key per se. Most of modern editors support "replace tab with spaces". You can use tabs for your work, but it will not affect others or other editors. At work, I'm actually required to do this. I have 0 problems with this, and it makes sense if you're not the only one working on something.

    I've already expressed my opinion on Camel Case etc. here, maybe more than once...
     
  6. douglasb

    douglasb Diamond Member

    Joined:
    Apr 11, 2005
    Messages:
    3,163
    Likes Received:
    0
    camelCase for instance variables. CAPITALS_WITH_UNDERSCORES for constants. UpperCamelCase for object properties and methods.

    Lots of my coworkers use Hungarian notation but IMO, it is a dated practice and pretty much worthless with modern IDEs. Not to mention, it makes the code harder to read IMO.
     
  7. degibson

    degibson Golden Member

    Joined:
    Mar 21, 2008
    Messages:
    1,389
    Likes Received:
    0
  8. Chaotic42

    Chaotic42 Lifer

    Joined:
    Jun 15, 2001
    Messages:
    30,220
    Likes Received:
    2
  9. Net

    Net Golden Member

    Joined:
    Aug 30, 2003
    Messages:
    1,587
    Likes Received:
    0
    #9 Net, Jan 21, 2013
    Last edited: Jan 21, 2013
  10. degibson

    degibson Golden Member

    Joined:
    Mar 21, 2008
    Messages:
    1,389
    Likes Received:
    0
    Well, enums are compile-time constants, so it does sorta follow that enums and compile-time constants would have a similar style suggestion.

    As for why kSomething is used instead of SOMETHING for compile-time constants, it's to differentiate from MACROS.
    "Until January 2009, the style was to name enum values like macros. This caused problems with name collisions between enum values and macros"
     
  11. Fallen Kell

    Fallen Kell Diamond Member

    Joined:
    Oct 9, 1999
    Messages:
    4,909
    Likes Received:
    1
  12. Staples

    Staples Diamond Member

    Joined:
    Oct 28, 2001
    Messages:
    4,431
    Likes Received:
    0
    I use

    Tabs
    camelCase for variables
    Classes, Namespaces and Methods start with capital letters

    I rarely use underscores although some languages like Python seem to prefer them.
     
  13. Chaotic42

    Chaotic42 Lifer

    Joined:
    Jun 15, 2001
    Messages:
    30,220
    Likes Received:
    2
    What about project organization in general? I've been working on a program which has a class that is getting kind of large. I'm splitting it up into multiple files:

    ClassName.Function1.cs
    ClassName.Function2.cs

    and so forth. Is this good tradecraft? It seems easier to work on than just having a single class file with several hundred lines of code.
     
  14. Scooby Doo

    Scooby Doo Senior member

    Joined:
    Sep 1, 2006
    Messages:
    947
    Likes Received:
    1
    I guess it would depend on the size of the functions. No sense in having tons of little 5 line functions in seperate files, it would make visual scanning annoying.
     
  15. Markbnj

    Markbnj Elite Member <br>Moderator Emeritus
    Moderator

    Joined:
    Sep 16, 2005
    Messages:
    15,677
    Likes Received:
    3
    I assume this is c#, and you're using partial classes? They are a strange feature, and I'm not sure I like seeing them used this way. They're sort of a hack, imo, to allow the combination of generated and edited code in one class at compile-time, which was necessary originally for ASP.NET and then for WPF/XAML, etc.

    I guess there's nothing really wrong with decomposing this way, although if one class is really getting that larger my inclination would be to look at refactoring it, rather than splitting it up. Perhaps it is doing the work of several classes that can be composed.
     
  16. Train

    Train Lifer

    Joined:
    Jun 22, 2000
    Messages:
    13,648
    Likes Received:
    1
    I would take that naming convention as a code smell telling you that your functions are way too large.

    And then your classes are probably too large as well.
     
  17. Munashiimaru

    Munashiimaru Junior Member

    Joined:
    Jan 14, 2013
    Messages:
    23
    Likes Received:
    0
    Disclaimer: Most of the below is in regards to java/c# (netbeans/eclipse/VS). Especially with naming anything that's more loosely typed, it is going to be a different beast. If you're doing something like windows API calls in C++, you're going to definitely want something like hungarian notation.

    Depending on the IDE doing what's quoted tends to just be extra clutter. Most modern languages/IDEs it's very easy to distinguish these things with a mouseover. Only time I use any sort of type notation (hungarian is what I use) in names is when I'm declaring stuff in a GUI/webpage and then dealing with it in another class where it becomes an immense convience to have all checkboxes prefixed with ckb (or whatever you define in your stands) (especially in VS not so much in Eclipse but still somewhat good).

    My personal coding standards are: Never abbreivate unless it's a business abbreviation (any abbreviations used should be defined in the requirements documention ideally). Put some thought into your function/class/variable names. If you're using single letters (besides for indexes) or names like temp, 99% of the time there's a better name that can be used. Declare variables in the highest part of the scope that it's used. You don't want variables that are floating around; it then has to be decyphered where and only where it gets used by later programmers. In the same vein, avoid reusing variable names; it almost never saves you any real memory/performance due to how garbage collection works and makes a place that needs to be decyphered like having variables in a scope where they're useless. For example, a string is immutable. Using the same temp variable 30 times over doesn't save you any processing or memory. Reistantiating objects at best generally just leads to a tiny amount of memory available to be garbages collected microseconds sooner (but it probably won't be).

    Always use small functions/classes (prevents ginormous naming and immensely helps readbility). I'm a little looser than each function doing strictly one thing, but never more than one plus other function calls. Rule of thumb is functions shouldn't be much more than a page height and classes no more than 2-3, but that's a very loose rule.

    Vertical white space is an asset you spend to get readibility. Using it to seperate logical pieces helps a ton with readibility, but if you use too much it makes it hard to take in what's going on in the overall flow of code.

    Comment all classes/functions/global variables with autodocumenting code (/** in eclipse and /// in VS). That way people can get a description of these things with a mouse over. Comment any underlying code that's using some funky logic to get things done (in a perfect world this wouldn't happen but it does especially when dealing with code out of your control). Everything else should be explained by using good names/keeping classes/functions small.

    Sticking to the above makes it so that a lot of extra clutter other people tend to add becomes obsolete.

    On tabs, when I was using notepad to write java I used spaces. On any decent, IDE you should be using tabs. Basically if tabbing is likely to be a mess don't use them otherwise do.

    I never use underscore. It's just added clutter especially for classes/variables where camel/pascal case is the norm. I usually just all cap constants without underscores, but that's really a debatable thing to do.

    The number one rule though is to follow the coding standards of the project you're working on even if it's different from what you like. Don't just say screw it I'm doing my own thing whether it fits in or not.