never using break statements
DuckDuckGo. Privacy, Simplified.
duckduckgo.com
I think the main problem (at least for me whenever i review code) is that you have multiple conditions for exiting the loop scattered all over, and keeping track of them all can be really hard sometimes as a reader. It also makes the position of your code within the loop really important when it doesnt need to be.
Its not like its definitely bad to use break statements, its more like its one of those code smells that tells you that you need to pay extra attention on whatever comes next because it might give you unpleasant surprises...
3
https://www.reddit.com/user/Nicksaurus/
level 3
Nicksaurus
· 4 yr. ago
But then on the other hand sometimes setting up the logic to only exit the loop at a single point can be way more complicated than just using an innocent little break;
7
https://www.reddit.com/user/Terofin/
level 4
Terofin
· 4 yr. ago
Sure, sometime its perfectly fine. You just need to be aware of the cost of doing it. Often it seems harmless when implemented, but becomes a problem when changes are made to the loop at a later point.
-
View: https://www.reddit.com/r/cpp_questions/comments/bc8k0l/comment/ekp8yxu/?utm_source=share&utm_medium=web2x&context=3
(same thread: )
In simplistic terms, your teachers are correct. Understanding your own code is the key to writing software the behaves predictably. Any kind of jump statement will make your code harder to understand. break and continue, in particular, can be used to write code that is quite challenging to follow, and there is almost always a better alternative. In other words, if you learn to structure your code without relying on these crutches, you will be a better developer for it.
The origin of this idea lies in the structured programming movement started by Dijkstra when he famously wrote
Go To Statement considered harmful[PDF]. Dijkstra describes the problem with unstructured goto as destroying your ability to reason about the behavior of your program without also knowing its entire execution history.
This topic became somewhat religious through the 80s and 90s, with huge debates for/against, despite Dijkstra himself claiming not to be dogmatic. Even today, whenever this comes up - as you can see for yourself in this forum - you will have people making stupid arguments for/against despite being unable to articulate the reasons behind it.
All that said, keep in mind that you use goto statements all the time: for-loops, function calls, return-statements, etc. The key idea here is to restrict your usage to a subset of well-behaved jumps that do not interfere with your ability to reason about the behavior of your program. The higher-level idea is code-tractability (i.e. How well can my software's behavior fit in the head of a mere mortal?). You should feel free to use any construct - including break and continue - that makes your system easier to understand.
(idk how it is in Java tho)
It is considered bad practice because it can lead to many unwanted situations like exiting loop/method after creating stream and not closing it. But if you use it carefully then it is OK.
-
https://stackoverflow.com/questions...-exit-a-loop-in-java#comment26651734_18188123
Why should we not use a "break" statement in programming?
Sage (Quora AI)
The "break" statement is a control flow statement that allows you to terminate the execution of a loop prematurely. While it can be useful in certain situations, its use can also make your code harder to read and maintain. One reason to avoid using "break" is that it can make it difficult to understand the flow of your code.
When you use "break", it can be unclear where the loop will terminate and what the final state of your program will be. This can make it harder for other developers to understand and modify your code.Another reason to avoid using "break" is that it can make it harder to test your code.
When you use "break", it can be difficult to ensure that all possible paths through your code have been tested, since the loop can terminate prematurely.There may be situations where using "break" is the best solution, but it is generally a good practice to avoid using it unless it is absolutely necessary.
Instead, consider using other control flow statements, such as "continue", "return", or "throw", to achieve the desired behavior in your code.
https://www.quora.com/profile/Akshita-Agarwal-80
Akshita Agarwal
·
Follow
Studied Computer Programming (Graduated 2020)
3y
As per the standard guidelines while writing code, there must be single point of exit in a loop or function or program.
If you use too many break statements then you are violating the guideline by creating more that one point of exit.
This is just to enhances the readability of the code. And allow other developers to understand the code fast and better.
***
Musfequr Rahman
·
Follow
Amature Programmer
5y
Because it might cause your program to have a memory leak or crash.
The Break command was originally meant for (as far as I know) Switches.
When a break is used outside of a switch, it forces a loop to abruptly end. Without allowing it to resolve.
***
Andrea Cesaro
·
Follow
working as Software Engineer
5y
Using break is fine but it can make hard the refactoring, in this case use a specific condition in your loop. In general use break only when your intentions reamin clear reading the code and when you think it can give you performance advantage (and measure it!).
(- quora)
You could read Donald Knuth's 1974 paper
Structured Programming with go to Statements, in which he discusses various uses of the go to that are structurally desirable. They include the equivalent of break and continue statements (many of the uses of go to in there have been developed into more limited constructs). Is your boss the type to call Knuth a bad programmer?
(The examples given interest me. Typically, break and continue are disliked by people who like one entry and one exit from any piece of code, and that sort of person also frowns on multiple return statements.)
(-
https://softwareengineering.stackexchange.com/posts/58257/revisions)
(--
Most of the people who like functions and procedures to have single entry and exit points grew up on Pascal. Pascal was not the first language that I learned, but it had a profound impact on how I structure code to this day. People always comment on how easy it is to read my Java code. That's because I avoid multiple exits points as well as intermixing declarations with code. I try my best to declare every local variable used in a method at the top of the method. This practice avoids code ramble by forcing me to keep methods succinct.
–
bit-twiddler
Mar 15, 2011 at 15:37
-
- 6
Pascal also had nested functions. Just sayin'...
– Shog9
Mar 15, 2011 at 17:32
- 6
From what I remember, back in the day, the main reason that people didn't like multiple return statements in functions was because debuggers didn't handle them properly. It was a real pain to set a breakpoint at the end of a function but you never hit it because of an earlier return statement. For every compiler I use nowadays that is no longer an issue.
- ;***
- I do not believe they are bad. The idea that they are bad comes from the days of structured programming. It is related to the notion that a function must have a single entry point and a single exit point, i. e. only one return per function.
This makes some sense if your function is long, and if you have multiple nested loops. However, your functions should be short, and you should wrap loops and their bodies into short functions of their own. Generally, forcing a function to have a single exit point can result in very convoluted logic.
If your function is very short, if you have a single loop, or at worst two nested loops, and if the loop body is very short, then it is very clear what a break or a continue does. It is also clear what multiple return statements do.
These issues are addressed in "Clean Code" by Robert C. Martin and in "Refactoring" by Martin Fowler.
)
***
The "badness" is dependent on how you use them. I typically use breaks in looping constructs ONLY when it will save me cycles that can't be saved through a refactoring of an algorithm. For instance, cycling through a collection looking for an item with a value in a specific property set to true. If all you need to know is that one of the items had this property set to true, once you achieve that result, a break is good to terminate the loop appropriately.
If using a break won't make the code specifically easier to read, shorter to run or save cycles in processing in a significant manner, then it's best not to use them. I tend to code to the "lowest common denominator" when possible to make sure that anyone who follows me can easily look at my code and figure out what's going on (I am not always successful at this). Breaks reduce that because they do introduce odd entry/exit points. Misused they can behave very much like an out of whack "goto" statement.
---
How do you break out of a loop without a break statement? My professor HATES break statements and tells us not to use it. I'm just curious how would I break out of the while-loop if the number I go...
stackoverflow.com