So today my prof was going over loops and went on a rant about how goto and break/continue statements are bad coding practice.
this was in relation to our first assignment that was required to take input test, send either an error, quit the program or proceed, I used a while(true) loop and an if statement to test if the program should exit with a break statement.
He claimed this was "poor" coding, I'm rather novice so I feel my opinion doesn't hold much water, what are the more "experienced" programmers thoughts on this?
This was some of the "official" teaching I learned as well. I would say that it actually depends on the coding standards being set by the organization. For example, a team at a company may decide whether or not it's preferred, along with a variety of other things like indentation, variable names, comment requirements, etc.
So the easy answer is that if this is the standard the professor has laid out, you should probably stick with it for the class.
However, overall, I generally use break and continue statements only when they make the most sense (so sparingly). E.g., if a loop condition is sufficient to cause a break, I'd use that over a break statement. I think it's easier to read. I never use gotos because I think they're hardly ever necessary and just make the code harder to follow. But to give you an idea of just how varied the opinion is out there, Linus Torvalds doesn't have a problem with gotos and they're in the Linux kernel. It really depends on the structure of the program.
Personally I would not group goto statements and break and continue statement into the same category of “bad code.” Goto statements—unless you are writing assembly code—are pretty much universally viewed as bad code. Back when I was in college this was called spaghetti code, and for good reason. The problem with goto statements is that it is very easy to lose context of the code’s logic flow, and it makes debugging code a nightmare, especially if you inherit it from a previous developer. When you use structured programming and divide you logic into a set of discrete methods/functions, it is very easy to follow the logic flow. This makes debugging easier and three years after you have completed your development, and some other developer needs to make changes to your code, he/she can very easily understand the functionality of the code.
With regards to break and continue statements, I would have to disagree with your professor. To be honest, I rarely use break statements and very rarely use continue statements. I can kind of see his point with regards to continue statements. Many times people will use them inside gargantuan loops that should have been further decomposed into discrete functionality. In these cases, yes the continue statement pretty much becomes almost like a goto statement. But there are cases where continue statements can be used effectively in concise loops and the logic is very easy to follow. And break statements I think are fine to use. All that means is you have hit a condition and the loop terminates. Any loop with a break statement can certainly be rewritten without a break statement, but you can run into a situation where the exit condition for the loop becomes so complex that it is hard read, where adding a break statement could greatly simplify the logic and make the code more readable. That would be the one piece of advice I would leave is always, always write your code using the method that makes your code the easiest to read and debug. Believe me the person who inherits your code will thank you for it.