The Java programming style posted on this site stated that 'break' are prohibited unless it is in a 'switch'... But I've been using it massively in my code, what can I do to replace all those goofy 'break's?
Can you show us an example of one of your "goofy breaks"? Here's an example of using 'break' in a for-loop and how you could change it. Note that programming style is often a matter of personal preference and should be used as a general guide, not as an unbreakable law. In the example below, I'm not sure if avoiding 'break' is a good idea - it doesn't really make the code more clear.
that's exactly what i was saying, thank you for your fast response... (As a beginner, I really don't know how much i should stick to those programming style). Anyway, Is there anyone who really writes all his code in that way?
Originally posted by Wilson Yang: that's exactly what i was saying, thank you for your fast response... (As a beginner, I really don't know how much i should stick to those programming style). Anyway, Is there anyone who really writes all his code in that way?
The style guide on this site is intended for the folks in the Cattle Drive (our Java programming course.) The style is a little peculiar, but one of the main reasons for its existence is to teach folks to write code to meet a style guide, whether you agree with it or not. If that's what your employer asks you to do, then that's what you'll have to do.
The reluctance to use "break" like that is to fulfill the conventions of an older programming paradigm, structured programming. This emanates from a paper by Bohm and Jacopini in 1966 where they demonstrated that every program can be implemented with a combination of
iteration (or, as apparently shown by Alan Turing in the 1930s, recursion), and
A "break" in the middle of a loop breaks the integrity of the iteration and is therefore incompatible with structured programming.
There are different opinions about how strictly one should adhere to structured programming; I think it is best learning to follow it strictly is the best training.
Yep. Learn to follow it strictly, for the learning experience. Then ignore it after that.
Nah, I exaggerate. But I'm one of those who believes that break, and embedded returns, and sometimes even continue, can lead to simpler, cleaner code. Sometimes. So unless I'm on a job where there's a coding standard that prohibits it, I would merrily use a break in an example like the one Jesper posted. Well, in that case I'd probably write it with a return statement instead, but same general idea:
Well in this case, the contains() method would also work, but that's beside the point. Multiple returns like this are also considered unstructured, and therefore bad, according to some people. To me, they seem like the most straightforward way to code something like this. Either way, it's important to be able to understand each of these styles when you see it, and also to be able to write your code in a particular style, when required to.
To summarize: You should always avoid break, except when you shouldn't.
I've seen breaks misused far more often than I've seen the lack of breaks hamper readability. And this is likely the reason for flat out rules in larger environments. It's easier to espouse "Just Say No" (ask Nancy Reagan) than to elucidate a reasonable but detailed stance on a complex topic.
Bill Shirley - bshirley - frazerbilt.com
if (Posts < 30) you.read( JavaRanchFAQ);
Originally posted by Jim Yingst: Well, in that case I'd probably write it with a return statement instead, but same general idea:
I find the return statement to be more readable, because it's easier to reason about where the program flow will continue when it gets executed.
Also, it forces me to write smaller methods, which is A Good Thing (TM).
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Joined: Jan 30, 2000
Agreed, that's why I favor return over break. And with short methods, other concerns about readability (for return/break/continue) tend to go away too; it's a non-issue. [ May 09, 2008: Message edited by: Jim Yingst ]