A rant
-
charlieg wrote:
I call it code slamming
That's a great phrase! Marc
People are just notoriously impossible. --DavidCrow
There's NO excuse for not commenting your code. -- John Simmons / outlaw programmer
People who say that they will refactor their code later to make it "good" don't understand refactoring, nor the art and craft of programming. -- Josh SmithYeah, it tends to fit too. Analogy is "mule marks" in carpentry. This is where you miss the nail and leave a dent in the wood. Why mule marks? Because only an ass would make them... Geeze, I'm feisty today. I posted a rant in Dell's support forums, and they deleted it. Seems I put too much #$%#$^%$^ in the forum for their taste (it was all directed at Dell). Mistakes I can handle but making part of your process, pisses me off. Anyway, back to the code - the problem with code slamming, errr, it isn't good, everyone forgets the schedule pressures, so don't be *too* hard on the developer. There is usually more than enough blame to sling even though I would argue that one should get better at code slamming with more practice :mad:
Charlie Gilley Will program for food... Whoever said children were cheaper by the dozen... lied. My son's PDA is an M249 SAW. My other son commutes in an M1A2 Abrams
-
Surely 2 does happen? Don't you ever write a method, get it working then go back and tidy it up - rename, extract methods, etc? Or do you mean that you do this yourself but most others don't?
Kevin
Kevin McFarlane wrote:
Don't you ever write a method, get it working then go back and tidy it up - rename, extract methods, etc? Or do you mean that you do this yourself but most others don't?
Sure I do, but yes, it seems that on this project I'm helping out on, others are not doing that. Marc
People are just notoriously impossible. --DavidCrow
There's NO excuse for not commenting your code. -- John Simmons / outlaw programmer
People who say that they will refactor their code later to make it "good" don't understand refactoring, nor the art and craft of programming. -- Josh Smith -
Kevin McFarlane wrote:
Don't you ever write a method, get it working then go back and tidy it up - rename, extract methods, etc? Or do you mean that you do this yourself but most others don't?
Sure I do, but yes, it seems that on this project I'm helping out on, others are not doing that. Marc
People are just notoriously impossible. --DavidCrow
There's NO excuse for not commenting your code. -- John Simmons / outlaw programmer
People who say that they will refactor their code later to make it "good" don't understand refactoring, nor the art and craft of programming. -- Josh SmithMarc Clifton wrote:
Sure I do, but yes, it seems that on this project I'm helping out on, others are not doing that.
Seems to be the norm I'm afraid. It's rare that I maintain code that shows any courtesy to the maintenance programmer. :mad:
Kevin
-
Yeah, it tends to fit too. Analogy is "mule marks" in carpentry. This is where you miss the nail and leave a dent in the wood. Why mule marks? Because only an ass would make them... Geeze, I'm feisty today. I posted a rant in Dell's support forums, and they deleted it. Seems I put too much #$%#$^%$^ in the forum for their taste (it was all directed at Dell). Mistakes I can handle but making part of your process, pisses me off. Anyway, back to the code - the problem with code slamming, errr, it isn't good, everyone forgets the schedule pressures, so don't be *too* hard on the developer. There is usually more than enough blame to sling even though I would argue that one should get better at code slamming with more practice :mad:
Charlie Gilley Will program for food... Whoever said children were cheaper by the dozen... lied. My son's PDA is an M249 SAW. My other son commutes in an M1A2 Abrams
charlieg wrote:
the problem with code slamming,
LOL! I thought you meant that as a phrase for how coding is done, not how code is criticized.
charlieg wrote:
everyone forgets the schedule pressures, so don't be *too* hard on the developer.
True, but somewhere there's the line between doing something to save time and doing something, erm, dumb. Marc
People are just notoriously impossible. --DavidCrow
There's NO excuse for not commenting your code. -- John Simmons / outlaw programmer
People who say that they will refactor their code later to make it "good" don't understand refactoring, nor the art and craft of programming. -- Josh Smith -
charlieg wrote:
the problem with code slamming,
LOL! I thought you meant that as a phrase for how coding is done, not how code is criticized.
charlieg wrote:
everyone forgets the schedule pressures, so don't be *too* hard on the developer.
True, but somewhere there's the line between doing something to save time and doing something, erm, dumb. Marc
People are just notoriously impossible. --DavidCrow
There's NO excuse for not commenting your code. -- John Simmons / outlaw programmer
People who say that they will refactor their code later to make it "good" don't understand refactoring, nor the art and craft of programming. -- Josh Smithoh this is priceless :) I *do* mean how coding is done :doh: the fact that it might be interpreted either way makes it that much funnier...
Charlie Gilley Will program for food... Whoever said children were cheaper by the dozen... lied. My son's PDA is an M249 SAW. My other son commutes in an M1A2 Abrams
-
Chris S Kaiser wrote:
That's a lot cleaner than
Actually, I'll disagree. Ironically, you'll see exactly your example of "not cleaner" in my code. And the reason is because at some point, I actually needed to code an else statement when connection failed, which didn't require my having to check if there's a return statement earlier. Trivial example, but still. Marc
People are just notoriously impossible. --DavidCrow
There's NO excuse for not commenting your code. -- John Simmons / outlaw programmer
People who say that they will refactor their code later to make it "good" don't understand refactoring, nor the art and craft of programming. -- Josh SmithYeah, it was a trivial example. I've had to work on code where the method isn't broken out into multiple methods, and the ret val has to be checked again and again for validity for further processing. Which could get deep with regard to if blocks. So really I use it in the case where I didn't use exception handling. So the "correct" method in my case would be to throw an exception, but for some stuff I just return instead. But I don't think its a valid representation of a senior developer that doesn't care enough. Its situational.
This statement is false.
-
I generally aim for the single return but not religiously. I think in the case you mention where you have a return false at the top and then a single return at the bottom that's fine. Any other multiple return sceanrio is to be avoided. It's not such a big issue when methods are short, which they're supposed to be in good OO. But most programmers seem unable to write sufficiently short methods. Then multiple returns become a menace.
Kevin
Yeah, I won't disagree with that. Mostly though in a case where if block indentation goes more than three levels deep I'll use this mechanism if possible. But really as I said in my reply to Marc, I probably should be using exceptions in the extreme cases. I think this is bad if its not responsibly done. Blanket statements tend to grate on me. I don't write them but I still see the occaisonal goto used this way, and its argued that for errors that need to be further processing regardless of where they occured its "ok". Well, I guess we have the finally block to argue with now. ;)
This statement is false.
-
Graham Shanks wrote:
The similar circumstances that I see all too often is "we'll skip unit testing because of time pressure and catch all the errors in integration". Firstly the project will never catch up and second the integration will take longer without unit tests.
Yup. I've got a situation where the following has been said: "we'll refactor in the unit tests when we've shipped the first version of the product." :laugh: :(( :laugh: :(( Marc
People are just notoriously impossible. --DavidCrow
There's NO excuse for not commenting your code. -- John Simmons / outlaw programmer
People who say that they will refactor their code later to make it "good" don't understand refactoring, nor the art and craft of programming. -- Josh SmithMarc Clifton wrote:
I've got a situation where the following has been said: "we'll refactor in the unit tests when we've shipped the first version of the product."
Let me guess - it never happened :)
Graham My signature is not black, just a very, very dark blue
-
Yeah, I won't disagree with that. Mostly though in a case where if block indentation goes more than three levels deep I'll use this mechanism if possible. But really as I said in my reply to Marc, I probably should be using exceptions in the extreme cases. I think this is bad if its not responsibly done. Blanket statements tend to grate on me. I don't write them but I still see the occaisonal goto used this way, and its argued that for errors that need to be further processing regardless of where they occured its "ok". Well, I guess we have the finally block to argue with now. ;)
This statement is false.
Yes, a lot of these rules are guidelines which you should follow unless you have a reasonable reason not to. There are often good exceptions. Also a comment explaining why you've violated the guideline is often worthwhile, e.g., a typical case might be a swallowed exception. At least this tells the code maintainer that you've thought about what you were doing. Re: goto, there's an example in Steve McConnell's Code Complete 1st edition (dunno whether it's in the 2nd ed) where there's some code with a goto in it and virtually everyoe who tries to rewrite it without the goto does so incorrectly!
Kevin
-
Yes, a lot of these rules are guidelines which you should follow unless you have a reasonable reason not to. There are often good exceptions. Also a comment explaining why you've violated the guideline is often worthwhile, e.g., a typical case might be a swallowed exception. At least this tells the code maintainer that you've thought about what you were doing. Re: goto, there's an example in Steve McConnell's Code Complete 1st edition (dunno whether it's in the 2nd ed) where there's some code with a goto in it and virtually everyoe who tries to rewrite it without the goto does so incorrectly!
Kevin
Another example would be in an assignment operator in C++:
SomeObject &operator=(const SomeObject &rhs)
{
if(&rhs == this)
return *this;//assign other members return \*this;}
This is recommended by Scott Meyers. So I still say its a matter of intelligent use and style. I worked with people from both camps. Some prefer one, as it makes it more readable, and others prefer the second as its safer as a habit. But that's what I'm getting at. People consider it bad style because of irresponsible usage. And this brings up another point. For greenhorns this might be a good rule. But to say that a senior developer doesn't care about his code because of multiple returns, is a bit brash and not qualified as a blanket statement. -- modified at 13:10 Saturday 19th August, 2006 ~Added pre tag to code section.
This statement is false.
-
Another example would be in an assignment operator in C++:
SomeObject &operator=(const SomeObject &rhs)
{
if(&rhs == this)
return *this;//assign other members return \*this;}
This is recommended by Scott Meyers. So I still say its a matter of intelligent use and style. I worked with people from both camps. Some prefer one, as it makes it more readable, and others prefer the second as its safer as a habit. But that's what I'm getting at. People consider it bad style because of irresponsible usage. And this brings up another point. For greenhorns this might be a good rule. But to say that a senior developer doesn't care about his code because of multiple returns, is a bit brash and not qualified as a blanket statement. -- modified at 13:10 Saturday 19th August, 2006 ~Added pre tag to code section.
This statement is false.
Chris, you've just reminded me of some code I was maintaining several years ago that was generally well-written. However, the author did religiously follow the single return rule and in one case it led to a bug which would have been avoided had he relaxed the rule. A bit similar to McConnell's goto example.
Kevin