Style. Which would you prefer?

[Vladas Razas]

int looking_for = 20;
int index = 0;
for (int i = 0; i < somearray.length; i++) {
  if (somearray[i] == looking_for) {
    index = i;
    break;
  }
}

or

int looking_for = 20;
int index = -1;
for (int i = 0; (i < somearray.length) && (index == -1); i++) {
  if (somearray[i] == looking_for) {
    index = i;
  }
}

[Lionel Badiou]

Hi Vladas,

As for myself I find the first version clearer, that actually means faster to understand.

Regards,

[Peter Chase]

The first version has a bug. If, after the loop, "index" is zero, you cannot tell if that means that the required value was at position zero in the array, or if it is not there at all.

If "i" was not local to the loop, you could tell, by looking at the value of "i", though that might be considered obscure.

If "index" was initialised to a rogue value, like a negative value, it would be easy to tell.

[Vladas Razas]

Yes there is a bug. I prefer 1st version myself too. Thanks!

[David Harkness]

If you submitted the second version to me, I'd print it out on heavy card stock and flog you over the head with it. You do not get a prize for confusing your peers by being too tricky. There are code obfuscation contests for that.

[Vladas Razas]

I posted this because there some style guides (as well as on this site) that prohibit use of break and continue.

[Vladas Razas]

Here it is http://www.javaranch.com/style.jsp

[M Beck]

remember, style guides are only guides, not law. unless they're given to you by your boss with the admonition "follow this style guide or you'll be fired", feel free to break the style guide any time you can write better, more readable code by doing so. making your code more readable is the point of style guides, after all - don't let them get in the way of their own purpose.

"break" and "continue" can be slightly more advanced concepts to use, because they can be abused too - even by accident - in ways that may make for unreadable code. that may be why style guides aimed at beginners caution against them; you'll need a little bit of experience to know when they're appropriate and when they're not. but if they were entirely inappropriate at all times, they shouldn't be in the language at all!

consider, for example, that the most general way to write a loop is as an infinite loop, with a conditional "break" in it to exit when appropriate. thus:

(preconditions)
while true:
  (do always)
  if (condition) then break
  (do if not exiting)
end while

"continue", for its part, can be very useful for heuristics. when looping over the lines of an input file, for example, it's often possible to quickly identify input lines that can be skipped over; if so, i for one will usually throw in a few "continue" statements right near the top of the loop to handle those. i feel it makes the body of the loop more readable, knowing ahead of time what sorts of input it will not be processing.

but in each case, use them with judgement and good taste. if in doubt, consider not using them.

[Jeff Langr]

Style guides should never say never.

-j-

[Lionel Badiou]

Hi Vladas,

Well, I don't think that java designers put useless keywords or constructs into their language...yet I can understand why Javaranch prohibits use of break/continue.

As for myself, the main point here is readability. There are almost always a lot of solutions to adress a problem, simply pick the one that is clearest to you, even if it uses break/continue.

For example, how will you manage a loop with several (2+) exit conditions ? As far as I am concerned, one of the clearest construct would be :

  
while (true)
{
if (test1)
 break;
 
if (test2)
 break;
 
if (test3)
 break;
}

Best regards,

[Jeroen Wenting]

- don't use undescores in variable names. Use camelCase instead.
- use C++ style bracing, it's much clearer.

[Layne Lund]

Originally posted by Jeroen Wenting:
- don't use undescores in variable names. Use camelCase instead.
- use C++ style bracing, it's much clearer.

What do you mean by "C++ style bracing"? And how is it clearer?

[Jeroen Wenting]

if (x)
{
   y();
}

instead of the K&R style

if (x) {
   y();
}

which when nested several levels deep gets extremely confusing.

[Ilja Preuss]

Originally posted by Jeroen Wenting:
- use C++ style bracing, it's much clearer.

That's more a matter of taste, and what you are used too. I actually prefer the style Vladas used, but find that I can adjust to an arbitrary (consistent) style in a matter of a few days. So I feel that it is important that a team decides on a particular style, but not what style that is.

Regarding deeply nested blocks, I find them to be hard to parse regardless of the brace style used, so I prefer to refactor the code in a way that they aren't needed (by introducing guard clauses and/or extracting methods).

[Lionel Badiou]

Hi all,

The "bracing style debate" is still alive ! As with other never ending debates, I guess that both styles are acceptable.

To my mind, as Ilja has suggested it, the golden rule here is consistency. I do believe that whatever the coding sytle is, it should be the same for the whole application.

Best regards,

[Jeroen Wenting]

of course the golden rule is consistency. When everyone consistently uses C++ style braces there's no further need for arguments

[M Beck]

is this the point where your friendly neighbourhood Python aficionado (yours truly) should pipe up to say, the brace style holy wars would all end if you guys just did away with the braces?

[Jeroen Wenting]

our pants would fall down, what else?

[Layne Lund]

Interestingly, Sun's suggested coding conventions use K&R style braces...

[David Harkness]

Ah yes, the ol' "break" and "continue" are evil advice. For one thing, how then are you to use a switch statement? Oh right, replace it with if-elseif-elseif-elseif-else of course! NOT! And I vastly prefer a continue or break in lieu of gnarly if constructs and more deeply nested logic to get around them.

If you can't read "continue" and drop your eyes down to the closing brace of the for/while, then the loop is too long.

Related to that, I also prefer returning early rather than using a "result" variable that gets set at five places in the method. There's nothing worse than seeing "result = 1" and having to read the rest of the method to make sure no other conditional sets it again. Yes, you could declare it final, but no one does.

Braces? I don't care which method you use. I actually prefer C++ style for class and method and K&R for everything inside the method. The only reasno I don't go C++ throughout is that I have to use a large font and it's just too inefficient to use C++ for everything. Editors nowadays can reformat this in a jiffy anyway.

But I hope we can all agree on one thing about the brace debate. This style

for ( int i = 0 ; i < 10 ; i++ )
{   if ( i % 3 == 1 )
    {   list.add(new Integer(i));
        j += i;
    }
    System.out.println(i + " says hi");
}

is downright horrendous. I've seen it appearing more regularly here over the past month. I had never seen it before. I can only assume some teacher has started this, but anyone know for sure?

Why is it bad? Other than being yet another new way to do it, you can no longer cut-n-paste whole lines consistently. It'd be clever if the source were read-only as you get the best of both worlds. But seriously, is screen real-estate that precious?

</rant> Ahhh, how cathartic.
[ February 02, 2005: Message edited by: David Harkness ]

[Jeroen Wenting]

Maybe some free IDE has a new version that uses it as a default for some reason...
It's indeed got the same problem K&R style has in that you can't take a line out of the code without invalidating the sequence of braces.

[Stefan Wagner]

I'm glad
The "bracing style debate" is still alive!

Here is an example of right formatting:

for (int i = 0; i < 10; i++)
{
        if (i % 3 == 1)
        {
                list.add (new Integer (i));
                j += i;
        }
        System.out.println (i + " says hi");
}

The rules in few sentences:
a) Braces in Allman-Style.
b) Blank after special characters (not before).
c) Blanks outside of braces - no blank inside.
d) A tab is a tab and a tab is 8 spaces, and therefore indentation is 8 spaces. (see: L. Thorvald: Coding Style)

b) and c) are consistent with booksetting practice. They have 500 years of experience, and optimized setting for readability.
a) is simply better readable, especially combined with d), and since most monitors are able to show more than old-times 25x80, nobody should try to argue with space.
Of course you should allways use tabs instead of spaces - fast to insert, fast to remove, and if you have an editor which allows showing a tab as two spaces, (there is no argument for something between 2 or 8 spaces) you may use it secretly if you 're allone in your room.
Without owning a widescreen-display, there is no need to fear of missing space when using an indentation of 8 spaces.

I'm not allways in exclusive control over the truth, but in this case ...

[Jim Yingst]

[Stefan]: I'm not allways in exclusive control over the truth, but in this case ...

Clearly, you're not.

[Jeroen]: It's indeed got the same problem K&R style has in that you can't take a line out of the code without invalidating the sequence of braces.

Mmmh, I've used K & R extensively, and I've used this other nameless style (I'll call it Style 3) on one extended project where my team lead was promoting it, and I'd say that difficulty in editing is almost never an issue in K&R, it does come up somewhat frequently with style 3. The difference is that it's very rare in my experience that I find it useful to move or remove the control statement that comes before the braces - but it's not at all unusual that I decide to reorder statements within the braces. So it a brace is on the same line as a for, while, if, etc, that's OK - it doesn't get in my way, as it's almost never useful for me to remove such a line entirely. I might want to alter code within a for statement, but Pascal style is no different in this respect. Editing expressions within a for/while/if is about the same amount of work in any of the three styles. However if I want to insert a new line at the beginning of the loop - that happens frequently. Pascal style and K & R are equally easy here, but style 3 suffers. So - I agree with you that style 3 is inferior here, but I don't agree that K & R shares that weakness.
[ February 02, 2005: Message edited by: Jim Yingst ]

[Marilyn de Queiroz]

        boolean done = false;
        int lookingFor = 20;
        int index = 0;
        while ( index < someArray.length && ! done ) 
        {
            if ( someArray[ index ] == lookingFor ) 
            {
                done = true;
            }
        }
  

[Jim Yingst]

See, it's stuff like that which prevented me from ever wanting to do the Cattle Drive.

[M Beck]

boolean done = false;
        int lookingFor = 20;
        int index = 0;
        while ( index < someArray.length && ! done ) 
        {
            if ( someArray[ index ] == lookingFor ) 
            {
                done = true;
            }
        }

how about this:

lookingFor = 20
for i in someList:
    if (i == lookingFor):
        break
else:
    pass  # didn't find lookingFor

or, actually, even better yet:

if (lookingFor in someList):
    pass  # found it.
else:
    pass  # didn't find it.

ok, i promise i won't mess up a Java board with Python code ever again. but i just had to show off how much simpler and clearer that loop could be.
[ February 03, 2005: Message edited by: M Beck ]

[Marc Peabody]

Originally posted by Jeroen Wenting:
of course the golden rule is consistency. When everyone consistently uses C++ style braces there's no further need for arguments

Because only then can we all agree that we are doing it wrong!

[Jim Yingst]

i just had to show off how much simpler and clearer that loop could be.

I'd agree, except it looks like the else clause in your middle example isn't indented properly to be within the for loop. Is that intentional?

[M Beck]

Originally posted by Jim Yingst:
it looks like the else clause in your middle example isn't indented properly to be within the for loop. Is that intentional?

it is intentional, to show off a language feature i believe may actually be unique to Python: "else" clauses on loops. such clauses will execute if and only if the loop runs through its entire iteration and "falls off the end"; they'll be skipped if the loop exits early through a break statement.

it's not a commonly-used language feature, but it's surprisingly easy to remember (since whenever you use it, there'll be that "break" to remind you), and on occasion it can make the loop that much shorter and more expressive.

[Jim Yingst]

OK yes, that's cool. I'd forgotten about that feature.

Back in the world of Java, I'd probably be inclined to do something like this:

    public static int indexOf(int target, int[] array) {
        for (int i = 0, len = array.length; i < len; i++)
            if (array[i] == target)
                return i;
        return -1;
    }

Just because I like freaking out people who think braces should be mandatory.

Note that I'm intentionally returning -1 rather than 0 as done in the earlier code, because I think using 0 for no result is probably a very bad idea. How would we know if 0 meant "found at beginnning of array" vs. "not found at all"?
[ February 03, 2005: Message edited by: Jim Yingst ]

[Warren Dew]

David Harkness:

Ah yes, the ol' "break" and "continue" are evil advice. For one thing, how then are you to use a switch statement? ....

If you can't read "continue" and drop your eyes down to the closing brace of the for/while, then the loop is too long.

I'd agree with that. I think the JavaRanch style guide is intended for beginners who are just learning the basics of the language, not for experienced programmers.

[I]But I hope we can all agree on one thing about the brace debate. This style

for ( int i = 0 ; i < 10 ; i++ )
{   if ( i % 3 == 1 )
    {   list.add(new Integer(i));
        j += i;
    }
    System.out.println(i + " says hi");
}

is downright horrendous. I've seen it appearing more regularly here over the past month. I had never seen it before. I can only assume some teacher has started this, but anyone know for sure?[/I]

That's the style I prefer. I invented it for my own personal use after carefully considering the arguments in favor of the "brace on own line" and "open brace at end of line" styles. It has the advantages of both: you can easily match braces like the former, and it has the same grouping and space advantages of the latter. It's not teacher imposed.

However, it has been independently invented by others. If you do some searches, you'll find that it has been advocated here on JavaRanch long before I was using it in Java (I originally used it in C++).

Why is it bad? Other than being yet another new way to do it, you can no longer cut-n-paste whole lines consistently.

I consider cutting and pasting to be a bad thing, so preventing it is a good thing. (Okay, kidding - partly)

It'd be clever if the source were read-only as you get the best of both worlds.

That's really the objective. Bug free code can be read only.

[Warren Dew]

M Beck:

but i just had to show off how much simpler and clearer that loop could be.

It is in examples where there's one statement per block. With longer blocks, I'd rather have the braces to remind me of the groupings.

How does Python handle the situation where one person uses an editor that only handles 8 space tabs, and another an editor that only handles 4 space tabs?

[Jim Yingst]

Generally with a battle to the death. Then the issue is resolved, on way or another.

Actually this is only an issue if some people are mixing tabs and spaces. (As advocated in the Sun standard - this is the one thing I most strongly disagree wih from Sun.) If everyone uses tabs for indentation, there's no problem. If everyone uses spaces, there's no problem. If some people use spaces while others use tabs - they'd better have absolute agreement on how many spaces are in a tab, or there's a big problem.

For better or worse though, Python users are forced to resolve this early on. Once that's done, everything's fine.

[Jim Yingst]

[Dvid Harkness]: Ah yes, the ol' "break" and "continue" are evil advice. For one thing, how then are you to use a switch statement?

In the case of the JavaRanch style guide (which I do not endorse personally), the rules given are: never use continue, and never use break other than in a switch statement. There, that was easy.

[M Beck]

Originally posted by Warren Dew:
It is in examples where there's one statement per block. With longer blocks, I'd rather have the braces to remind me of the groupings.

really long blocks - and deeply indented blocks - can get tricky to read in Python, yes. but then again, they can in any language. for the question of where a block ends, sometimes i've thrown in comments where the closing brace would go, with a note as to which block the comment "closes". that helps, but it doesn't fix my own pet peeve with the language - without braces, i can't use the "%" command in the vi editor to jump back and forth between the block's start and end. i've had to learn to write shorter blocks, and do without that editor feature; no language is perfect.

How does Python handle the situation where one person uses an editor that only handles 8 space tabs, and another an editor that only handles 4 space tabs?

Python only cares that the indenting is consistent within each block. so, this scenario might become a problem if two people were to use different editors to work on the same method or procedure, adding lines with different indenting to preexisting blocks; if it arose, i would recommend a style guide policy stating "all editors should be set to expand tabs to spaces" as the simplest solution. i haven't yet run into any editor serious enough to be suitable for programming that couldn't be configured to do that. writing Python in Notepad might be a pain, yes, but writing almost any code in Notepad is already a pain, so...

in fact, the vi editor i use can be set to read configuration settings from a comment line near the top of the file. so i tend to throw something vaguely like this into the start of all my code:

# vim: set expandtab tabstop=4 shiftwidth=4 textwidth=75 :

and if someone else wants to edit my code with something other than vi, they can just figure out what to do for themselves.

[Jeroen Wenting]

of course in Python you can do some really naughty things by mixing tabs and spaces in your indentation...

[Joel McNary]

Originally posted by Jim Yingst:

Just because I like freaking out people who think braces should be mandatory.

You know, you're freaking me out.

Also, if you don't always use braces, then K&R does suffer the same problem as Style3. But if an if statement always has an open brace, then there's no problem whatsoever.

So the solution? Use K&R style with mandatory braces. You can write longer loops/methods that way, because you have one extra line to fit the entire method on the screen.

Of course, I just use Jalopy to reformat to whatever I need it formatted to....

[Ilja Preuss]

Originally posted by Warren Dew:
Bug free code can be read only.

That's not my experience. Only code that doesn't need to be changed can be read only. And a system for which users don't request changes is very likely a system that doesn't get used at all.

[Warren Dew]

M Beck:

Python only cares that the indenting is consistent within each block.

I'm still confused. Does this mean that a block where the lines start with eight spaces will end if a line is encountered that starts with two tabs? Wouldn't this result in bugs that are rather difficult to find, since the lines look identical in the editor - or even bugs that are caused when an editor silently converts tabs to spaces?

If not, how does Python know how many spaces the programmer has set his editor to show tabs as?

[M Beck]

Originally posted by Warren Dew:
I'm still confused. Does this mean that a block where the lines start with eight spaces will end if a line is encountered that starts with two tabs? Wouldn't this result in bugs that are rather difficult to find, since the lines look identical in the editor - or even bugs that are caused when an editor silently converts tabs to spaces?

um. you know, i'm not entirely sure what Python will do if it finds your code switching from spaces to tabs in mid-flight - that issue has simply never occurred for me.

if i had to guess (and i can't - regrettably - just experiment to find out, as i'm sitting in a computer lab that doesn't have Python installed), my guess would be that Python probably would consider one tab and eight spaces to be equivalent for its purposes. but, really, this situation is incredibly rare in practice, if it even happens at all.

if an editor silently converts all tabs to spaces in a consistent manner, bugs get silently removed from your Python code if your code is indented with all spaces, and the indentation is conformant to the block structure you intended, it can't be wrong. (or if it is, it can't be your editor's fault that it's wrong!) i indent my Python code this way at present, deliberately.

If not, how does Python know how many spaces the programmer has set his editor to show tabs as?

it doesn't, of course - but, as you noted, this can only ever be a problem if you mix tabs and spaces in a single source file. in actual practice, i have never yet encountered this.

as far as i know, Python is smart enough to know that "one tab followed by three spaces" should be deeper indented than "one tab followed by no spaces". but, again, even that situation seems to be very rare in actual practice. i used to indent that way when i first started learning Python, and it never gave me any problems. i can't imagine mixing "one tab, two spaces" with "ten spaces, no tabs" in a single source file - if you actually want to do that, for heaven's sakes, why?