// do stuff
// do other stuff
// commence screaming.
You can say “if this equals something, then do this, otherwise do that”. You can say “if this equals something, then do this, otherwise if this other thing equals something else, do that, otherwaise, do a third thing”. But if you’re saying “if this equals something, do this, if it equals something else, do that, otherwise do the other thing”, use a switch statement.
What? In the code fragment I gave, both loops initialize, test, do stuff, then advance the condition variable, in that order, then test, do stuff, and advance until the test fails. They (should) compile to the exact same set of opcodes.
Granted, a “continue/break” statement would work differently in the while (wouldn’t increment the condition variable) case, and I’ll assume that that’s what you were referring to, but that’s not an issue in a vast majority of programs.
>>I’m talking about an instance where x is a variable that cannot ever be anything other than a 1 or a 0.
huh. i take it you haven’t maintained much code in the real world, then?
the RISKS digests are full of stories about code that assumed variables would always be in a certain range, only to have modifications which violated those boundary conditions and cause rockets to go spiraling out of control.
from a performance aspect, the extra else costs nothing, and as pointed out is a useful catch when (not if) something changes later on.
while i won’t argue that your students write great code, you certainly aren’t teaching them how to write maintainable software.
catsix, in that case I’d suggest making your students write a test plan for their code that ensures 100% code coverage. Not only will I then have a chance of hiring a junior programmer that knows how to write a bloody test plan (since that aspect of coding seems to not be covered in college), but they’ll have an incentive to not add unneeded code.
“break” behaves the same, I was thinking of “continue”.
No, it won’t crop up very often, but that fact that it could crop up means you have to pay that much more attention to the “while” loop when reading the code. Which makes using “while” when “for” will do that much lamer…
(Personally, I’d rather see neither–
(loop for i from 1 below 10 do
(loop for item in some-list do
I’ve dealt with massive piles of shit code left behind by other programmers who tested for everything under the sun when a goddamn int number modulo 2 cannot possibly result in any other answer than an int 1 or 0, especially in a program that verifies the data before the modulus is performed.
And this is a rather large problem with programmers today. Extra code doesn’t cost anything, so they throw it in wherever in the most haphazard manner, not knowing whether their asses are actually covered or the code does absolutely nothing, thereby constantly increasing the size of programs.
I teach them to write concise, efficient code that is not such a mess that it becomes an unmanagable chore to figure out just why the hell an entire function that’s never called anywhere by another function or in the main function exists in a program. You ever tried to maintain code where people left in absolutely everything they typed?
Yeah, they tend to hate the fact that they fail projects for such things. They of course also think there is no actual need to ever begin any kind of plan before writing a program, which is a belief I cure as quickly as possible. Shit, lots of them will actually try to begin coding before they even understand what the hell problem they’re being asked to solve.
For sufficiently large sizes of “//do stuff” they’re not equally clear.
The first line of the “for” loop tells you instantly that you’re iterating over some sequence. The “while” loop may require you to read through a significant chunk of code to figure that out. And as I mentioned previously, they have different semantics under some circumstances, so the “while” loop might require more careful analysis.
The while case is less clear. It leads to infinite loops like:
i = 0;
while (i < 10)
if ((something_else == SOME_SPECIAL_CASE) && (i==8)
//We don't want to do "other stuff" for this special case
//do two screenfulls of other stuff
That said, I believe I did mention that this was a lame rant, right?
I agree with the OP, but disagree with CATSIX good programing requires both good standard style, and protection from the unexpected having apparently impossible else clauses that lead to error handling is of great importance in good programming. These ensure that when your code is missused or incorectly updates it will give meaningful messages that will allow the users of your code to fix the problems they create. Also such code is a godsend if there is a memory leak from another application into your own.
Hi, did I talk about a program that interacts with any other application?
I talked about modding a freaking integer by two. If you check to make sure the number you’re going to mod by 2 is an integer already, what other results are you going to get from that particular division?
I see useless, redundant idioms all the time. I spend a lot of time wearing an “Oracle DBA” hat, and one of my pet peeves is when I see people doing stuff like:
create table foo(a number);
select * from foo;
drop table foo;
No matter how many times I tell people that there’s no point in commiting after a DDL operation, they still do it. And regardless of the fact that doing so completely defeats the purpose of transactions, they commit after every single fricking statement. It’s almost like people insist on not “getting” transactions (kind of like how many people insist on not “getting” relational databases in general…)
Sometimes, it’s the little things that grate for no rational reason.