Sorry, I guess I’ve not been clear enough. I wrote a C++ example of it because what I wanted out of that little exercise was for them to get their heads around the idea that they can eliminate unnecessary code. These are absolute beginners who don’t yet know what they’re doing, and my point to them was ‘Don’t write a book when a sentence will do.’
That piece of code was not production programming, and it never will be. It’s an example to people who have been in a programming class for around four hours to watch their code and not add unnecessary shit. If the objective of the lesson is ‘make this code as concise as possible’ and the students don’t really know how to program at all yet, you give 'em a simple example.
Error checking and handling come after the first class, and by the end of the last class I’d expect that their programs could handle unforseen circumstances such as a memory allocation error storing something other than an integer 0 or 1 in that variable location.
For example, if the program is supposed to continue normally when the result is 1, but throw an error and tell the user they have bad data if the modulo was any other number but 1, I would not expect to see someone write:
if( x == 1)
{
//do good stuff
}
else if(x != 1)
{
//bad data given message
}
else
{
//bad data given message
}
I have seen both of those, as well as a user trying to compare a string value to ‘Yes’ by doing every single permutation in upper and lower case rather than comparing to ‘YES’ and converting the user’s input to uppercase.
It can be done on a short string, but it’s not efficient, and it was an absolute nightmare when I saw a student try to compare a longer string like ‘Pennsylvania’.
If you’re thinking they’re bad as junior programmers, you should see how they arrive in school.
A very bad man indeed. Why not make a function that does your tests on “$Variable”, give it a descriptive name, and stick it in the “while” clause of a “do…while” loop instead of doing the above?
Oh wait–that would be readable, which isn’t the Perl way.
I’ve been a professional C and C++ programmer for 8+ years and I’ve never gotten in the habit of using for loops with test conditions other than simple integer incrementing or decrementing. for and while will compile to equally efficient code, and are equally capable of being abused, so I have no problem with that.
The thing I’m having to deal with recently, due to the pre-existing codebase of the project I’m now working on, is arrays being treated as if they were unions. So we have this function that reads data out of animation. Sometimes it reads a position. Sometimes a rotation. Sometimes a sound ID (an int). Sometimes a box (a pointer). Etc. The way the code was written, an array of floats was passed in, and when something other than floats needed to be returned, it was just crammed into the array of floats. Worse yet, there was no commenting or documentation for any of this.
My other pet peeve is function/member names which are ambiguous. The worst example in this project involved a system we have in which things which get too far away from the player/camera will be put to sleep. So the base entity class had a function called “CheckSleep()”. What the hell does that do? Does it check if something is asleep? Check if it can sleep? (Nope: It turned out that what it did was check if it could sleep, and then GO TO SLEEP if possible.)
I’m a big fan of extremely long function names. If your function checks if something can sleep and then goes to sleep, name it “CheckSleepabilityAndMaybeSleep()” or something.
(Stupid programming story: a few days ago, I spent several hours trying to track down a bug in my code… turned out I had gotten the arguments to memset() in the wrong order!)
I understand your frustration, LordVor. Unfortunately (as you know), this is something we have to just deal with, when a programming language (C/C++) provides a lot of redundancy (all loops can be re-written as a while loop; there are several ways to incrment a variable; etc).
Amen, Metacom. When I was familiarizing myself with some Perl syntax a couple of years ago, I was really worried that my CS education had failed me. Then I began to come to the realization you mention.
The loop is actually in a function. There is a second function that generates some random thing, the outer function which loops until the test that it is sufficiently random passes. All I have to call in the code is $var = Function(); YMMV of course. Standards of “Readability” vary wildly.
There are times when that won’t work, but those times are nothing at all like the example that I quoted and was referring to. If you read what Mtgman wrote (which I quoted), you’d see that he was saying that he doesn’t like to put long predicate expresions in the conditional clause of loop statements, and the proceeded to give an example where he used an explicit “exit if” type statement at the end of an infinite loop (which is essentially a “do…while” loop). If there was something happening after his “exit if” statement, he could have put a “#stuff” indicator after that statement like everyone else in this thread has been doing in their examples.
I think Max was wondering what happened when his first post was truncated. I think you jumped on a “what the heck” aimed at the hamsters.
Anyway, yep, that’s the whole of the loop. All I’m doing is checking the output from this one other thing for compliance with big nasty test. Pretty much a do-while situation. I could have used the do-while and I’m not sure why I didn’t. I remember an instructor in college who had it out for the do-while and I specifically remember arguing with him about it and how it had its place. Some sort of karmic payback was probably influencing me when I wrote that snippet. It is well-commented though, and I don’t have any fears of anyone else having trouble with it if ever it transitions to someone else to maintain. In the meantime, it works and that is fine with me.
Yeah, and I could’ve been clearer in the initial description, which was my fault.
The example to the students involved only positive integers, so the possibility of a -1 or other result in that very controlled example was nil. Yet some of them came up with up to thirty lines of code just for the if conditions.
catsix I didn’t mean to come out snarky. I would say that I prefer an overly cautious programmer to a carelss one, so I have difficulty getting annoyed by two many else clauses even if they trap impossible errors. My real gripe would be with people who underuse comments, or leave missleading comments in edited code. Somewhat draconian, but I would like to reject any code which is less than 20% comment as a matter of principal. Not that that is ever likely to work in the real world.
As an Oracle DBA I also agree with the missuse of commit statements to esentialy devalue the hole transaction based capability of the db. But worse is people who write SQL that includes completely unnecessary links to tables, and can’t see why doing such a thing mucks up their query. Sure understanding the nuances of inner and outer joins is difficult and I don’t mind fixing that sort of problem. But just because an invoice table and a quote table have user key fields, does not mean you need to join to the user table when you are not reporting anything from that user table…
It’s hard to be efficient. Gosh knows I look back at old Perl scripts, or Actionscript codes in Flash files, and think, “Damn, look at the clumsy way I did this instead of just doing this,” and shaking my head. Just look at these as learning stages and know that eventually the inherint laziness of the programmer will compel them to be better programmers.
They say every computer program can be shortened by one line. They also say that every computer program contains at least one bug.
Carried to its logical conclusion, every computer program can be reduced to one line, but that line will have a bug in it.
BTW, I am reluctant to use “while”-- if the condition will have a predictable finish, I can usually for, and if it isn’t, I’m afraid to use it and cause the program to spin its wheels forever.
I think the amount of commenting that is necessary depends greatly on (a) the complexity of the algorithm, and (b) the length and amiguity of variable and function names.
I really hate seeing things like this:
//Gets the player’s position
Player::GetPos();
Well, DUH. A lot of good that comment did.
(Of course, the video game industry is probably a lot less comment-oriented in general than some others because we’re usually not trying to write code that will be maintainable 10 years from now by strangers…)
Here’s a can of worms. GOTOs. Never? Or rarely? And if you said “never”, how would you code the following situation:
for (x=0; x < 100; x++)
{
OK, I figured out why my posts keep getting truncated… when I’m writing code, I instinctively hit “tab” to move over a column, which activates the “submit reply” button. What a pain.
OK, let’s try again.
(Ack! all the spaces I inserted to emulate tabs vanished) (oh well)
for (x=0;x<100;x++)
{
for (y=0;y<100;y++)
{
for (z=0;z<100;z++)
{
if (DidFindNugget(x,y,z))
{
goto found;
}
}
}
}
DidNotFindFunc();
found:
This is about the only case I would EVER consider using a GOTO in, but in particularly performance-critical code, it’s slightly more efficient than any other way I can think of to implement that precise functionality. And it doesn’t really have the normal problems of GOTOs associated with it. It’s basically functioning as a break;