Fog Creek Software
Discussion Board




Is This Code style/Standard Useful?

I am working with an ex-colleague's code, and I'm getting used to a few of his style habits. One thing that comes as a surprise is his habit of leaving a space between a method name and the parenthesized paramater list:

foo.doSomeWonderFullThing (withThis,andThis);

He also *doesn't* leave a space with if statements:

if(somethingIsTrue) ...

Is this one of those half a dozen of one, six of the other things? Or is there a useful and compelling argument in favour of or against his style?

I'd like to hear some opinions before I refomat everything to my usual coding conventions... perhaps I can learn something?

http://www.braithwaite-lee.com/

Reginald Braithwaite-Lee
Wednesday, August 06, 2003

My only concern is your statement: "my usual coding conventions"  Are your conventions any better than his? 

I strongly support a standard in code, if it is consistent across the application/enterprise.  If none exists, I like to use what I consider the implementation standard.  For example JAVA, I use Sun's,  C++ I use MS.    Mainly because they have one most developers should recognize, even if they don't agree. 

However, before reworking code merely for convention, unless you can automate it with 100% accuracy, I would leave it alone.  The chance you may feel the urge to change something else at the same time, that results in a problem, will have a negative ROI. 

I usually fix this type of issue, when I am changing the code for some other reason.  And again, only when I can be certain with 100% accuracy.  (i.e. replace: foobarbarfoo with FoobarBarfoo) or something the IDE will reformat for me.


-=-=-=-=
The problem with giving a "penny for your thoughts" is most people put their two cents in.

BigRoy
Wednesday, August 06, 2003

I just hit "Tools, Reformat Code" and move on.

Nimoy's Bilbo
Wednesday, August 06, 2003

Perhaps he's got some other stylistic quirks that are more significant, but I don't really see why a space here and no space there matters.  (This is coming from a really anal-retentive person, too...)

Sam Livingston-Gray
Wednesday, August 06, 2003

He's wrong. You're right. Reformat it.

Dennis Atkins
Wednesday, August 06, 2003

My basic feeling is that if there's no compelling reason one way or another, consistency is helpful. Since I'm working on the code and he has moved on, I'll reformat things to my preferences.

I agree with the poster who eschews wholesale refactoring. I'll just change things as I need to rework his code.

Sadly, for other reasons, I expect that will be almost all of his code.

But I was curious to see whether anyone would be able to advance a great argument one way or the other. I'm not too old to change my ways!

Reginald Braithwaite-Lee
Wednesday, August 06, 2003

I think Borland got it right when they released an official styleguide for Delphi/Object Pascal people could follow; not only does it GREATLY improve readability, but it also ensures a form of "official" standard people can cling to in discussions like these :)

The only problem is, though, most coders are too hung up with their own styles and have no real interest in changing 'for the better good'.

Style guide in question:
http://community.borland.com/article/0,1410,10280,00.html

Mickey Petersen
Wednesday, August 06, 2003

With respect to the specific example given, I can think of one (I think modestly compelling) reason why your ex-colleague's style is to be avoided. In the case of the function call, separating the argument list from the function name makes it not *look* like a function call. In the case of the if statement, it makes a conditional control structure *look* like a function call. This seems bass-ackwards to me.

Jeff Kotula
Wednesday, August 06, 2003

> In the case of the function call, separating
> the argument list from the function name
> makes it not *look* like a function call.

Not to the code's original author. To that person, it looks exactly like what it is. He has his own internally consistent world view with a regular mapping to syntax.

You can argue that most people don't write in that style, but you cannot claim that spaced-out function call doesn't look like a function call. If the grammar permits the space, and the parser respects that grammar, then anything accepted by the parser as a function call is a function call.

I don't advocate flouting convention; I just take issue with your argument.

Steven E. Harris
Wednesday, August 06, 2003

==>He's wrong. You're right. Reformat it.

I know you're joking, but you'd be surprise how many people actually do this. Makes reliable deltas/diffs from your source control system a freaking nightmare as you can't tell which lines actually changed code, and which were simply reformatted. I hate the people that do such things and they should be pounded over the head -- hard, fast, and continuously, with a giant Clue-By-Four!

Go ahead. Reformat my code. I dare ya!

Sgt. Sausage
Wednesday, August 06, 2003

Comments along the line of "anything accepted by the parser as a function call is a function call" aren't relevent.

At issue is standards for humans not computers.

The best way of dealing with minor issues in formatting styles is to use a "pretty printer" program (at leas for C) like "cb" or gnu's "indent" before things get checked in.

It would be much easier doing this than continually arguing about boring formatting uses.

njkayaker
Wednesday, August 06, 2003

I prefer a space after "if", "for" and "while", but it's really not a big deal as long as your editor is highlighting keywords.  And to echo what another poster said, I wouldn't change little things like this if they are going to show up as changes in your source control system.  It ends up distracting from the syntactically significant changes.

Brian
Wednesday, August 06, 2003

I don't see any value in coding standards for things this trivial. Not only that, but having minor differences between programmers in the way they write their code makes it easier to identify who wrote what, which may give you clues you need to debug it.

I have worked on projects where function calls of the form f( x,y,z ) -- with the space -- meant either I or Person X wrote the code, and it was probably right, so if I didn't understand why the code was doing something I tried harder to understand it. But if the function call was of the form F(x,y,z) without the space, it was wrtiten by Person Y or Person Z and if the code was strange it was probably simply a bug.

Joel Spolsky
Wednesday, August 06, 2003

To the person who pints out that an if statemsnt shouldn't look like a function call:

I agree. "if" is not a function, it's a special form ;-)

Sorry, I couldn't resist...

Reginald Braithwaite-Lee
Wednesday, August 06, 2003

A foolish consistency is the hobgoblin of small minds.

Does his unorthodox placement of spaces make the code (a) confusing or (b) hard to maintain?  If not, then stop being a control freak.  Different does not equal wrong.

Alyosha`
Wednesday, August 06, 2003

There's no reason for his style, just as there's no reason for your style. If you add in any whitespace, newlines, or indentation other than any mandated by the language's grammar, you're in the realm of personal preference.

So, it's just down to whichever you (and everyone else working with you :) likes, or dislikes the least...

Tom
Wednesday, August 06, 2003

Foolish consistency is what enables you to use regular expressions for refactoring programs :)

Tom
Wednesday, August 06, 2003

I'm all for some degree of coding standards, but when it gets down to the level of one-vs-none whitespaces...Jeez. 

Is the code otherwise so great that the biggest issue facing your company's code is how many whitespaces this guy uses?

Mister Fancypants
Wednesday, August 06, 2003

There's nothing particularly bad about leaving a space between function names and the '(' (though it's an uncommon idiom) except that it's probably going to confuse some code tools (Intellisense, refactoring plugins etc etc).

I ran into a similar problem once on a huge lump of C++ code. The source analyzer we were using (I forget which) couldn't cope with people writing

int MyClass::
foo(int blah)
{
}

instead of the more usual

int MyClass::foo(int blah)
{
}

Andrew Reid
Wednesday, August 06, 2003


Now that I am "mature", I always try to code to established coding standard of whatever language I am using, no matter how much it annoys me.

In college I had 1000 persnickety personal rules about how C code should be formatted.  Now I am slightly less idiotic.

Unless you are coding in a language of your own creation, when you use a programming language, you become part of a community, like it or not.  When you decide to break with community norms, let it be for something big like a new type of application or a novel algorithm.  Knock them dead with your ideas, not with your bracket placement.

Having your own personal coding style is the programming equivalent of walking down the street of Branson Missouri dressed like Marilyn Manson.  You simply prove you are pointlessly different, and nothing else.

Manuel M. Garcia
Wednesday, August 06, 2003

1) If a code refactoring tool can't handle code that is valid according to the language's specification, the tool is broken.

2) I agree that coding to language standards is a good idea, and I follow accepted standards when programming in Java and C#.  But what about C++?  There is no one style standard because none was ever established at the get-go.  You tend to have two camps, the Microsoft-style camp with full hungarian notation and then the UNIX-style camp.  Then you have lots of people who use something in between (eg, not hungarian, but MS-style camel-case instead of UNIX-style underscores, etc).

Mister Fancypants
Wednesday, August 06, 2003

The number one reason I've seen people put those extra spaces in there is to compensate for their editor's "next word" feature. Some editors won't stop at a paren, so when you "next word" from the function name, trying to go to the first param, it jumps over it to the second param.

Troy King
Wednesday, August 06, 2003

Manuel M. Garcia is right.
Stop this stupid thread

Geert-Jan Thomas
Thursday, August 07, 2003

Thanks everyone!

What I've learned is:

Almost every poster thinks there is no useful distinction between x.f(z.f()) and x.f (z.f ()). The general idea is that humans like myself should learn to parse both at a glance.

Leaving both styles of code intact is suggested to avoid confusing the SCCS and to mark the work of different developers. This is especially pertinent in this case, as the sole developer using the x.f (z.f ()) style has left.

One person pointed out that the x.f (z.f ()) style can be useful when using editors/IDEs that do not parse source code very well. This is the *exact* answer to the question I was asking.

Many people questioned whether this is worth thinking about. What can I say... I am curious about almost everything in software development. I had never seen this style of coding before, and now that I am maintaining the code written in this style, I wanted to know whether there was a new trick for my collection.

Indeed there is: if I am ever using an editor that skips over my function/method parameters, I can switch to this style.

Thanks again to everone who posted.

http://www.braithwaite-lee.com/

Reginald Braithwaite-Lee
Thursday, August 07, 2003

If you write in Java, I recommend to use Sun's Java Code Convention, excellent document. You can download it from javasoft.com

Evgeny /Javadesk/
Saturday, August 09, 2003

*  Recent Topics

*  Fog Creek Home