Syntax/formatting questions

M

Magix

Weaksauce
Joined
Jul 27, 2012
Messages
109
So I started learning programming in Visual C#, and that tends to generate code as

Code: 
method ()
{
    //code
}

Now I am getting into java in Netbeans, and the code gets generated as

Code: 
method () {
    //code
}

And for single line methods I've also seen people do

Code: 
method () { //code }

Is there any sort of standard as to which one should be used? To me the first version seems easiest to read, but I might just be the most used to it.
 
Either the first or the second is fine; the better IDEs can even enforce minor formatting while you are typing. Just agree on a standard with your team, and stick with it.

Depending on what "//code" evaluates to in the third option, you could wind up wearing the team's dunce hat for a while.
 
Visual studio has an auto format comman which helps keep code clean. The real answer is that it doesn't matter what you choose, as long as you're consistent. When multiple people work on the same code, consistency is even more important.
 
Whether you might want to use the third approach rather depends on line length limitations. If you can fit your single-line function body in on your 80 or 100 character/line budget (or whatever you're targeting), then go for it.

I would argue that you should generally avoid having multiple statements per line in the third example, but semicolon-delimited statements do afford you that opportunity. Think about using that approach if the situation seems acceptable to you.
 
PTNL said:
Either the first or the second is fine; the better IDEs can even enforce minor formatting while you are typing. Just agree on a standard with your team, and stick with it.

Depending on what "//code" evaluates to in the third option, you could wind up wearing the team's dunce hat for a while.
Click to expand...

Breath_of_the_Dying said:
Visual studio has an auto format comman which helps keep code clean. The real answer is that it doesn't matter what you choose, as long as you're consistent. When multiple people work on the same code, consistency is even more important.
Click to expand...

These
 
When I do C# I use the first C# example. When I use Java, javascript, and css I use the second example.

I rarely use the last example. If I do it is usually at the beginning of a method and something really short that I want to keep on one line so it doesn't clutter up the space and take focus away from the real logic. Like this
Code: 
if(!Valid()){ return; }


But the most important thing was already mentioned which is to be consistent.
 
Depends, like all other consisitency is most important, that said I normally use option 1. I do use option 3 for auto-properties

Code: 
 public bool IsActive { get; private set; }
 
It doesn't matter do whatever you think is most readable or you think is most common in the language you are writing.

Visual Studio can bet setup under the options to format the code either way. Its default is as you mentioned which is what most C# developers will probably use. (I've been developing in .NET for years). However, you may find others doing differently, and as long as you are consistent it doesn't matter. I bet that Netbeans can be reconfigured as well.
 
While consistency is the key for stylistic standards, I would find:

Code: 
if ( !value() ) { return; }

enormously irritating. What practical value do the {} around your return statement add?

Another irritation I have is with unnecessary "else" clauses (plenty of cases where they are necessary and/or add clarity, but this one bugs me):

Code: 
if ( x )
{ 
    return x
}
else
{
    // remaining 15 lines of function ...
}

This is logically identical to:

Code: 
if ( x ) return x;

// remaining 15 lines of function ...

and this version is less cluttered and no less obvious in what it does.

This is, of course, mostly subjective ... if there's anything close to a religion for many engineers it is their own personal preferences when it comes to coding style!
 
RandemTox said:
While consistency is the key for stylistic standards, I would find:

Code: 
if ( !value() ) { return; }

enormously irritating. What practical value do the {} around your return statement add?

Another irritation I have is with unnecessary "else" clauses (plenty of cases where they are necessary and/or add clarity, but this one bugs me):

Code: 
if ( x )
{ 
    return x
}
else
{
    // remaining 15 lines of function ...
}

This is logically identical to:

Code: 
if ( x ) return x;

// remaining 15 lines of function ...

and this version is less cluttered and no less obvious in what it does.

This is, of course, mostly subjective ... if there's anything close to a religion for many engineers it is their own personal preferences when it comes to coding style!
Click to expand...


What bugs me more

Code: 
if(x)
{
     //code
}
else if(!x)
{
     //code
}
To me that reeks of not understanding logical branching and coverage.
 
Yes, I've seen that one!

That would drive me up the wall and someone would be getting slapped/denied commit rights until they cut it out!

It reminds me of Excel users putting every bloody formula in an =SUM() container! =SUM(A1*A2) ... arrggggh!
 
Breath_of_the_Dying said:
What bugs me more

*Snip*

To me that reeks of not understanding logical branching and coverage.
Click to expand...

I've (honest to god) seen code from large corporations that is similar to the following:

Code: 
if (x && y && z && a && b)
{
    // Code
}
else if (a && z && b)
{
    // Code
}

Where they were parsing command-line arguments. I felt physically ill looking at the code, there were about a dozen conditional statements like this, and it was much worse, handling pretty much every possible combination of argument.
 
Breath_of_the_Dying said:
What bugs me more

Code: 
if(x)
{
     //code
}
else if(!x)
{
     //code
}
To me that reeks of not understanding logical branching and coverage.
Click to expand...
Yeah that stinks!

With one line if statements and loops with a single line body I drop the curly brackets. So:
Code: 
if(x)
     //code
else //if(!x) <- The person who added the polar condition needs shooting!!!
     //code
Which is much more readable, especially on a laptop.
 
I tend to use method 1 across the board, and use indent quite a bit. Can make it look a bit comical at times, but it makes it easier to troubleshoot issues in the end. I'm tend to actually be a bit OCD about it, as whenever I'm creating a string of html in php or something similar, I also add all the spacing if there's anything nested, like elements of a form, or table, etc. Just helps me glance at it quickly to find out what I goofed up.
 
Exactly, it could get even worse.

Code: 
if(expensiveOperationToReturnBool(x))
{
     //code
}
else if(!expensiveOperationToReturnBool(x))
{
     //code
}

Oversimplification, sure, but I have seen code that does extra calls to determine the else. Some type of search or contains call is the most common culprit I've seen.
 
Jesse B said:
Where they were parsing command-line arguments. I felt physically ill looking at the code, there were about a dozen conditional statements like this, and it was much worse, handling pretty much every possible combination of argument.
Click to expand...

Why did it bother you so much? What did your doctor say?
 
Breath_of_the_Dying said:
I'm still not seeing where you're trying to go, can you show a more expressive example? Your example was a single if with two lines of ellipses
Click to expand...

I'm saying that if you have:

if (x) {
}
else if (!x) {
}

that will catch any value of x. But if you change the first one:

if (x > 5) {
}
else if (!x) {
}

You're not accounting for when x <= 5. Which is what you may, or may not wnat.

As compared to:

if (x > 5) {
}
else {
}


The ellipses meant that the rest of the code continues as posted.
 
Still not making sense, in the second example your evaluating x as an int in the first evaluation, then as a bool in the elseif eval. At least in C# that wouldn't even compile.

No on said if, if/else, or chained if/else statements are wrong in any fashion. What I'm saying (and I believe others have expressed) is that some coders don't have a clear understanding of mutual exclusivity and collectively exhaustive evaluations of logic, which is why they would put the "else not if" statement when it is completely unnecessary. To me, if they can't grasp that level of basic logic, I bring a lot more of their code into question: such as poorly designed loops or even worse bad exception handling.
 
While the code may logically not be necessary, it may enhance readability and maintainability.
 
You must log in or register to reply here.
Back
Top