Friday, July 11, 2008

Coding Style

We were having a fun debate today about coding style.

My style is:
if_(_condition_)
{
body;
}

However, I was informed that there was some mutiny going on and people were trying to over throw my spaces inside parenthesis in preference of:
if_(condition)
{
body;
}

I asked around a bit and found out another senior developer here uses this coding style:
if(_condition_)
{
body;
}

Oddly enough, when it's an if statement I like that space between the if and the opening paren. But when it's a method, I don't include it:
private void MethodA(_formal params_)

Without question I'm a huge fan of the spaces between the parenthesis. I find this makes code WAY more readable. After all, the parenthesis are entirely syntax. The stuff you care about is between them. When the stuff you care about is directly touching the syntax noise, things get a bit more cluttered.

However, a quick google search for C# coding standards indicates that this is a rare stance. From what I found, most standards seem to call for:
if_(condition)

My current style is influenced by style guidelines we have at work. However, if I had my way, I would go back to The Elements of Java Style guidelines and do my curly braces differently:
if_(_condition_)_{
body;
}

I had a professor in college who recommended that book's style guidelines. I hated them at first. But after about 2 days of coding with them I learned to really like it.

Sure, it's a religious debate... But I'm curious, what's your style? And what would your style be if you had your way?

7 comments:

  1. I prefer ”if_(condition)”. Like you, I did use to add extra spaces within the parenthesis (in C/C++), but I stopped doing it when I started developing in C#, partly because Microsoft didn’t do it in its C# sources, partly because it didn’t really enhance readability. However, I need to use spaces between operators, or else I’ll go mad. :-)

    Generally, I always try to follow the style that is the most common on the platform. Hence I write

       public void DoSomething()
       {
           ...
       }

    in C#, but

       public void doSomething() {
          ...
       }

    in Java. I don’t believe pascal casing and the Allman style is any more readable than camel casing and the K&R style, but I very much do believe it’s important to be consistent and to go with the flow. I also know that Microsoft did invest quite a bit in creating the .NET Framework Design Guidelines, and I don’t think there are many well thought-out reasons to go against it when coding in C#.

    ReplyDelete
  2. I'm with the crowd on
    if_(something)
    {
    }

    However i have recently started leaving off the curly braces on single line if statements and im really starting to love the ? operator.

    I also put spaces between operators and on complex ifs i favor using a lot of ()s

    I never liked the curly brace on the same line as the if. i dont know why.

    For methods I think i tend to do
    MethodName()

    As for capitalization i favor Capital First letter (is that allman style) properties and methods, camel case for variables internal to a method and parameters, and some sort of prefix for member variables usually either m or _

    ReplyDelete
  3. as a up-until-recently primarially Java guy ... I always did

    public void doSomething(int a) {
    if(condition) {
    body
    }
    }

    ** with indenting

    It was hard on my last project developing both .Net and Java web service implementations where I had to switch between them going back and forth ... I ended up having to go back and uppercase my methods and whenever I did a ReSharper reformat, it always added the if_( space.

    I don't mind that space, although I don't write it in in my normal flow. I am more inclined to tweak the reformating feature of the editor and use it (adjusting if necessary to fit in with the development team's common form) and use it all the time to clean stuff up after I hack at it a bit... that way I am not worrying about it while I type.

    on the other hand ... the last few weeks I have been working entirely in Ruby and have a love/hate relationship with not-needing the () for method calls. For most stuff it is a lot easier and cleaner but occasionally, especially when you have calls with trailing option hashes containing other calls it can get confusing not having them in there.

    Also, tracking down random names to figure out if they are a variable or method takes some getting used to but it much better than getter and setters (while I don't think they are perfect, C# properties are better imo)

    I agree on the consistency but really don't like {} on new lines in C# ... I am too used to having them on the same line and having them on the next line doesn't add anything, to me, as far as readability. I use them on even one liners (b/c in refactoring I have had it bite me the butt when I changed something and didn't add them back in

    ReplyDelete
  4. Oh, and about the ternary operator (?:) .... I saw this in a blog post the other day and really like it:

    while you often "(w/s)hould" refactor the below sitauation into a inheritence hierarchy and use polymorphism to pick the correct factory method ... sometimes you still want to set a variable with a value conditionally on another value.

    Instead of something like:

    if(c = 1) {
    var = one;
    } else if(c = 2) {
    var = two;
    } elise if(c = 3) {
    var = three;
    } else {
    var = four;
    }

    or something similar with a switch ... I did this:

    var = (c == 1) ? one :
    (c == 2) ? two :
    (c == 3) ? three :
    four;

    indented correctly, it makes for a cleaner, imo, setup to show that different conditions result in different values and the default is on the end.

    many may not like it, but I did.

    ReplyDelete
  5. Truthfully, as far as if statements go, I don't hold fast to any code styles. I think I typically use if(param1,_param2), but I don't pay much attention to spaces after the if and at the ends of the parameter list.

    As far as capitalization, it really depends on what language I'm using. I tend to prefer C#'s capitalization style for methods.

    I really love opening curly braces on the same line as a method declaration/if/else/try/catch. It just seems to make the code more compact while still being readable. The more I think about it, I'm not sure that having an opening curly brace on its own line really provides any extra readability. I ignore the curly brace since indentation would provide the info the brace would provide.

    One thing I've debated with a co-worker is the use of multiple return statements in a method. I wasn't a fan of them. I'm still not that big of a fan, but I'm starting to get used to it. I think it was only because some professor made that rule and it stuck for some reason.

    The ternary operator I don't use at all. I just never remember it while I'm coding. Maybe I'll start using it more.

    I did see some code today that used goto statements. Man, that was some horrible code to follow, especially since the formatting was horrible.

    ReplyDelete
  6. I rarely see ?: these days. Waaaay back when I was doing straight C programming, it was used all the time, but it seems to have fallen away with C#. To be honest I don't know for sure if C# supports it, I'm guessing it does. I always though it was a good shortcut, but I suspect today usage of it in C# code would result in a lot of maintenance developers scratching their heads :)

    Oh, and the style should be:

    if(_something_)
    {
    somethingelse;
    }

    Without a doubt. Spaces between the if and the opening parenthesis? No way. Visual Studio drives me nuts when it puts spaces between all your parenthesis on a line!

    ReplyDelete
  7. Not to be a spoil sport, but coding style in this context is really last century.

    If you have ReSharper it is somewhat easy to keep this guideline, or some other type of formatter. Problem is, you're always going and setting this and blagh blagh blagh it requires maintenance.

    As long as the developers are following good pattern development and good OOP principles the "style" is absolutely irrelevant. Once should be able to look at the structure and design of the classes and figure out what is going on.

    ...but I digress, too much time is spent on such things...

    but hey, if the converstation entertains then I suppose the entertainment is worth it.

    ReplyDelete