A rant
-
Looking at bad code makes me cringe. When I look at something like a simple function that returns a string and the compiler warns about unreachable code detected and the code itself has multiple return points, I can't help but wonder, if simple code like this is so poorly implemented, warnings aren't fixed, and there's not comment to explain what the if statements and switch statements are even doing, what can I expect in complicated code? I have this visceral emotional reaction to bad code, it makes me not even want to touch the whole project, even if I'm working on an isolated part of it. I'm still associated with the bad code. Do you ever feel that way? Or am I letting my emotions get in the way here? And then I hear the "we need to get something out, and we'll refactor it later". Refactoring is abused, IMO. How much refactoring could be eliminated if you just wrote the code right to begin with? And come now, does refactoring really happen? It's more like a meditation than a practice. What's the sound of one programmer refactoring? Yeah, exactly. Shouldn't code get reviewed frequently, even in the midst of a the continuous fire drill? I mean, after all, if you acknowledge that the fire alarm is always sounding, then you might as well figure out how to do the programming better and smarter, rather than take the McGyver approach and hope the ducttape lasts to end of the episode. Does your team ducttape (I always thought it was duck tape) the code and promise each other to refactor later? About that lying questionnaire below, good intents are almost like lies, but you're never actually caught at the lie because you can always say "it'll happen soon." So, is there some truth my conception that bad, uncommented simple code is a portent of bad, uncommented complicated code? And is there some merit to the conclusion that the bad, uncommented, complicated code will also be really buggy? Is there some merit to the attitude that refactoring should be minimized? What are your thoughts? Marc
Some people believe what the bible says. Literally. At least [with Wikipedia] you have the chance to correct the wiki -- Jörgen Sigvardsson
People are just notoriously impossible. --DavidCrow
There's NO excuse for not commenting your code. -- John Simmons / outlaw programmer -
Looking at bad code makes me cringe. When I look at something like a simple function that returns a string and the compiler warns about unreachable code detected and the code itself has multiple return points, I can't help but wonder, if simple code like this is so poorly implemented, warnings aren't fixed, and there's not comment to explain what the if statements and switch statements are even doing, what can I expect in complicated code? I have this visceral emotional reaction to bad code, it makes me not even want to touch the whole project, even if I'm working on an isolated part of it. I'm still associated with the bad code. Do you ever feel that way? Or am I letting my emotions get in the way here? And then I hear the "we need to get something out, and we'll refactor it later". Refactoring is abused, IMO. How much refactoring could be eliminated if you just wrote the code right to begin with? And come now, does refactoring really happen? It's more like a meditation than a practice. What's the sound of one programmer refactoring? Yeah, exactly. Shouldn't code get reviewed frequently, even in the midst of a the continuous fire drill? I mean, after all, if you acknowledge that the fire alarm is always sounding, then you might as well figure out how to do the programming better and smarter, rather than take the McGyver approach and hope the ducttape lasts to end of the episode. Does your team ducttape (I always thought it was duck tape) the code and promise each other to refactor later? About that lying questionnaire below, good intents are almost like lies, but you're never actually caught at the lie because you can always say "it'll happen soon." So, is there some truth my conception that bad, uncommented simple code is a portent of bad, uncommented complicated code? And is there some merit to the conclusion that the bad, uncommented, complicated code will also be really buggy? Is there some merit to the attitude that refactoring should be minimized? What are your thoughts? Marc
Some people believe what the bible says. Literally. At least [with Wikipedia] you have the chance to correct the wiki -- Jörgen Sigvardsson
People are just notoriously impossible. --DavidCrow
There's NO excuse for not commenting your code. -- John Simmons / outlaw programmerMarc Clifton wrote:
And is there some merit to the conclusion that the bad, uncommented, complicated code will also be really buggy?
I would argue that your statement is too much of a generalization. Bad, uncommented and complicated code can still meet a user requirement and get the job done. And in the absense of any change requirements or a business need to change functionality, why even spend your time refactoring? Experience has taught me that when I'm into a pile of code that only needs a one-liner done to it, don't try and make it into a weeks project. You are just asking for trouble.
Chris Meech I am Canadian. [heard in a local bar] Nobody likes jerks. [espeir] The zen of the soapbox is hard to attain...[Jörgen Sigvardsson]
-
Looking at bad code makes me cringe. When I look at something like a simple function that returns a string and the compiler warns about unreachable code detected and the code itself has multiple return points, I can't help but wonder, if simple code like this is so poorly implemented, warnings aren't fixed, and there's not comment to explain what the if statements and switch statements are even doing, what can I expect in complicated code? I have this visceral emotional reaction to bad code, it makes me not even want to touch the whole project, even if I'm working on an isolated part of it. I'm still associated with the bad code. Do you ever feel that way? Or am I letting my emotions get in the way here? And then I hear the "we need to get something out, and we'll refactor it later". Refactoring is abused, IMO. How much refactoring could be eliminated if you just wrote the code right to begin with? And come now, does refactoring really happen? It's more like a meditation than a practice. What's the sound of one programmer refactoring? Yeah, exactly. Shouldn't code get reviewed frequently, even in the midst of a the continuous fire drill? I mean, after all, if you acknowledge that the fire alarm is always sounding, then you might as well figure out how to do the programming better and smarter, rather than take the McGyver approach and hope the ducttape lasts to end of the episode. Does your team ducttape (I always thought it was duck tape) the code and promise each other to refactor later? About that lying questionnaire below, good intents are almost like lies, but you're never actually caught at the lie because you can always say "it'll happen soon." So, is there some truth my conception that bad, uncommented simple code is a portent of bad, uncommented complicated code? And is there some merit to the conclusion that the bad, uncommented, complicated code will also be really buggy? Is there some merit to the attitude that refactoring should be minimized? What are your thoughts? Marc
Some people believe what the bible says. Literally. At least [with Wikipedia] you have the chance to correct the wiki -- Jörgen Sigvardsson
People are just notoriously impossible. --DavidCrow
There's NO excuse for not commenting your code. -- John Simmons / outlaw programmerMarc Clifton wrote:
"we need to get something out, and we'll refactor it later".
This should make the alarm go off. I have over 10 years of experience in software development (most of them multi-million dollar projects) and there are 2 things that are always true: 1- If you are asked to "get something out", it is certainly how the whole project has been developped and managed. 2- Refactoring never happens, because companies don't see the point of redoing something that already works. From their standing point of vue, it is easy to understand, for they don't know the first thing on software development. Speaking of point number 2, the best approach to refactor the thing is to do it on a on-demand basis. Let me explain. If you are asked to work on code, it is probably to add new features or fix bugs. Take this occasion to refactor your "little piece". Like I said in point 2, refactoring code without improving what it is doing won't fly at management level. If possible, educate your co-workers, especially the junior ones. You know, Marc, the perfect world does not exist, nor do the perfect code. You are out there to make it better, though.
-------- "I say no to drugs, but they don't listen." - Marilyn Manson
-
Looking at bad code makes me cringe. When I look at something like a simple function that returns a string and the compiler warns about unreachable code detected and the code itself has multiple return points, I can't help but wonder, if simple code like this is so poorly implemented, warnings aren't fixed, and there's not comment to explain what the if statements and switch statements are even doing, what can I expect in complicated code? I have this visceral emotional reaction to bad code, it makes me not even want to touch the whole project, even if I'm working on an isolated part of it. I'm still associated with the bad code. Do you ever feel that way? Or am I letting my emotions get in the way here? And then I hear the "we need to get something out, and we'll refactor it later". Refactoring is abused, IMO. How much refactoring could be eliminated if you just wrote the code right to begin with? And come now, does refactoring really happen? It's more like a meditation than a practice. What's the sound of one programmer refactoring? Yeah, exactly. Shouldn't code get reviewed frequently, even in the midst of a the continuous fire drill? I mean, after all, if you acknowledge that the fire alarm is always sounding, then you might as well figure out how to do the programming better and smarter, rather than take the McGyver approach and hope the ducttape lasts to end of the episode. Does your team ducttape (I always thought it was duck tape) the code and promise each other to refactor later? About that lying questionnaire below, good intents are almost like lies, but you're never actually caught at the lie because you can always say "it'll happen soon." So, is there some truth my conception that bad, uncommented simple code is a portent of bad, uncommented complicated code? And is there some merit to the conclusion that the bad, uncommented, complicated code will also be really buggy? Is there some merit to the attitude that refactoring should be minimized? What are your thoughts? Marc
Some people believe what the bible says. Literally. At least [with Wikipedia] you have the chance to correct the wiki -- Jörgen Sigvardsson
People are just notoriously impossible. --DavidCrow
There's NO excuse for not commenting your code. -- John Simmons / outlaw programmerRefactoring, aka sorting your sloppy rushed mess out later, doesn't happen because, on the surface, the code "does its job". Once the code is out in the wild there is little mileage to be gained from smartening it up. "WE" know it needs doing but the bean-counters won't see it as a worthwhile exercise, as your time could be betetr spent on something else that makes money. The simple answer is, as you suggest, to do the job properly in the first place. This usually requires a decent spec, adequate time to work through the spec and then provide good testing time. I think the planets align more often than those 3 simple tasks occur within the same project :)
I still remember having to write your own code in FORTRAN rather than be a cut and paste merchant being pampered by colour coded Intellisense - ahh proper programming - those were the days :)
-
Looking at bad code makes me cringe. When I look at something like a simple function that returns a string and the compiler warns about unreachable code detected and the code itself has multiple return points, I can't help but wonder, if simple code like this is so poorly implemented, warnings aren't fixed, and there's not comment to explain what the if statements and switch statements are even doing, what can I expect in complicated code? I have this visceral emotional reaction to bad code, it makes me not even want to touch the whole project, even if I'm working on an isolated part of it. I'm still associated with the bad code. Do you ever feel that way? Or am I letting my emotions get in the way here? And then I hear the "we need to get something out, and we'll refactor it later". Refactoring is abused, IMO. How much refactoring could be eliminated if you just wrote the code right to begin with? And come now, does refactoring really happen? It's more like a meditation than a practice. What's the sound of one programmer refactoring? Yeah, exactly. Shouldn't code get reviewed frequently, even in the midst of a the continuous fire drill? I mean, after all, if you acknowledge that the fire alarm is always sounding, then you might as well figure out how to do the programming better and smarter, rather than take the McGyver approach and hope the ducttape lasts to end of the episode. Does your team ducttape (I always thought it was duck tape) the code and promise each other to refactor later? About that lying questionnaire below, good intents are almost like lies, but you're never actually caught at the lie because you can always say "it'll happen soon." So, is there some truth my conception that bad, uncommented simple code is a portent of bad, uncommented complicated code? And is there some merit to the conclusion that the bad, uncommented, complicated code will also be really buggy? Is there some merit to the attitude that refactoring should be minimized? What are your thoughts? Marc
Some people believe what the bible says. Literally. At least [with Wikipedia] you have the chance to correct the wiki -- Jörgen Sigvardsson
People are just notoriously impossible. --DavidCrow
There's NO excuse for not commenting your code. -- John Simmons / outlaw programmerMarc Clifton wrote:
So, is there some truth my conception that bad, uncommented simple code is a portent of bad, uncommented complicated code?
Yes
Marc Clifton wrote:
And then I hear the "we need to get something out
Unfortunatly there is some truth to that statement. I have been too often in a position that we just have to show a sample to get the full funding. Then surprise surprise --> oh that is great --> what do you need more funding for. we are happy with what we have! ARRGHH :mad: A fine line between showing the capability in a credible manner and not letting them think it is done. My conclusion is too many managers just accept programing is magic and then are happy believing in magic. No management does not have to be expert programmers but they do have to trust their experts. ok end of my rant.
-
Looking at bad code makes me cringe. When I look at something like a simple function that returns a string and the compiler warns about unreachable code detected and the code itself has multiple return points, I can't help but wonder, if simple code like this is so poorly implemented, warnings aren't fixed, and there's not comment to explain what the if statements and switch statements are even doing, what can I expect in complicated code? I have this visceral emotional reaction to bad code, it makes me not even want to touch the whole project, even if I'm working on an isolated part of it. I'm still associated with the bad code. Do you ever feel that way? Or am I letting my emotions get in the way here? And then I hear the "we need to get something out, and we'll refactor it later". Refactoring is abused, IMO. How much refactoring could be eliminated if you just wrote the code right to begin with? And come now, does refactoring really happen? It's more like a meditation than a practice. What's the sound of one programmer refactoring? Yeah, exactly. Shouldn't code get reviewed frequently, even in the midst of a the continuous fire drill? I mean, after all, if you acknowledge that the fire alarm is always sounding, then you might as well figure out how to do the programming better and smarter, rather than take the McGyver approach and hope the ducttape lasts to end of the episode. Does your team ducttape (I always thought it was duck tape) the code and promise each other to refactor later? About that lying questionnaire below, good intents are almost like lies, but you're never actually caught at the lie because you can always say "it'll happen soon." So, is there some truth my conception that bad, uncommented simple code is a portent of bad, uncommented complicated code? And is there some merit to the conclusion that the bad, uncommented, complicated code will also be really buggy? Is there some merit to the attitude that refactoring should be minimized? What are your thoughts? Marc
Some people believe what the bible says. Literally. At least [with Wikipedia] you have the chance to correct the wiki -- Jörgen Sigvardsson
People are just notoriously impossible. --DavidCrow
There's NO excuse for not commenting your code. -- John Simmons / outlaw programmerI believe Cockburn, Beck, and Cunningham probably intended it to be rather immediate and fearless. When I write a method I initiall my write it messy but I don't call it down. After I write code, I reread it to eliminate obvious logic errors and rewrite bits and pieces to be more maintainable and more efficient (if possible, maintainable is number 1). Then I test and then I may rewrite once again. I tidy up comments put a comment header and then call it done. This is refactoring at its best. Of course when you get to a higher level and can see the bigger picture you can realize that the design is wrong, in which case that should be refactored, immediately. Joel, from Joel on Software, disagress but he is in NYC so his opinion doesn't count towards reality sometimes. My point refactoring is misunderstood by management and paper on the wall programmers. If its done right its beautiful. Oh, yeah, ugly code makes me bash my head on the desk sometimes. I have also been known to throw stuff at people that write brain farts.
A man said to the universe: "Sir I exist!" "However," replied the Universe, "The fact has not created in me A sense of obligation." -- Stephen Crane
-
Looking at bad code makes me cringe. When I look at something like a simple function that returns a string and the compiler warns about unreachable code detected and the code itself has multiple return points, I can't help but wonder, if simple code like this is so poorly implemented, warnings aren't fixed, and there's not comment to explain what the if statements and switch statements are even doing, what can I expect in complicated code? I have this visceral emotional reaction to bad code, it makes me not even want to touch the whole project, even if I'm working on an isolated part of it. I'm still associated with the bad code. Do you ever feel that way? Or am I letting my emotions get in the way here? And then I hear the "we need to get something out, and we'll refactor it later". Refactoring is abused, IMO. How much refactoring could be eliminated if you just wrote the code right to begin with? And come now, does refactoring really happen? It's more like a meditation than a practice. What's the sound of one programmer refactoring? Yeah, exactly. Shouldn't code get reviewed frequently, even in the midst of a the continuous fire drill? I mean, after all, if you acknowledge that the fire alarm is always sounding, then you might as well figure out how to do the programming better and smarter, rather than take the McGyver approach and hope the ducttape lasts to end of the episode. Does your team ducttape (I always thought it was duck tape) the code and promise each other to refactor later? About that lying questionnaire below, good intents are almost like lies, but you're never actually caught at the lie because you can always say "it'll happen soon." So, is there some truth my conception that bad, uncommented simple code is a portent of bad, uncommented complicated code? And is there some merit to the conclusion that the bad, uncommented, complicated code will also be really buggy? Is there some merit to the attitude that refactoring should be minimized? What are your thoughts? Marc
Some people believe what the bible says. Literally. At least [with Wikipedia] you have the chance to correct the wiki -- Jörgen Sigvardsson
People are just notoriously impossible. --DavidCrow
There's NO excuse for not commenting your code. -- John Simmons / outlaw programmerI go through this everyday. The project I am working on was put together by a few developers that just had the attitude of get it working and worry about the rest later. The management throws around the word refactor for everything. They always say oh we will just refactor it later. Well the crap code piled up so high that it started causing hugh problems. They built it with out a solid design, commented nothing and they copied and pasted the same code in multiple classes all of the places, tons of hard coding and no oo design (they had no idea how to use inheritance or polymorphism). My initial roll on the team as the junior developer was to just help the senor guys out. Well 6 months later they fired both senor guys because everything they wrote started to break and I am stuck writing in this mess all day long. Its so bad I really don't like having my name associated with the mess. I go home sick to my stomach some days. Not to mention that sometimes I feel like I am not learning anything and I am starting to become a worse developer because of this mess. So after my rant I would say yes bad uncommented simple code leads to bad uncommented compiled code.
-
Looking at bad code makes me cringe. When I look at something like a simple function that returns a string and the compiler warns about unreachable code detected and the code itself has multiple return points, I can't help but wonder, if simple code like this is so poorly implemented, warnings aren't fixed, and there's not comment to explain what the if statements and switch statements are even doing, what can I expect in complicated code? I have this visceral emotional reaction to bad code, it makes me not even want to touch the whole project, even if I'm working on an isolated part of it. I'm still associated with the bad code. Do you ever feel that way? Or am I letting my emotions get in the way here? And then I hear the "we need to get something out, and we'll refactor it later". Refactoring is abused, IMO. How much refactoring could be eliminated if you just wrote the code right to begin with? And come now, does refactoring really happen? It's more like a meditation than a practice. What's the sound of one programmer refactoring? Yeah, exactly. Shouldn't code get reviewed frequently, even in the midst of a the continuous fire drill? I mean, after all, if you acknowledge that the fire alarm is always sounding, then you might as well figure out how to do the programming better and smarter, rather than take the McGyver approach and hope the ducttape lasts to end of the episode. Does your team ducttape (I always thought it was duck tape) the code and promise each other to refactor later? About that lying questionnaire below, good intents are almost like lies, but you're never actually caught at the lie because you can always say "it'll happen soon." So, is there some truth my conception that bad, uncommented simple code is a portent of bad, uncommented complicated code? And is there some merit to the conclusion that the bad, uncommented, complicated code will also be really buggy? Is there some merit to the attitude that refactoring should be minimized? What are your thoughts? Marc
Some people believe what the bible says. Literally. At least [with Wikipedia] you have the chance to correct the wiki -- Jörgen Sigvardsson
People are just notoriously impossible. --DavidCrow
There's NO excuse for not commenting your code. -- John Simmons / outlaw programmerMarc Clifton wrote:
Looking at bad code makes me cringe.
Standard practice in my case. I'm a contractor and typically do a lot of maintenance programming. Maintaining bad code is the norm.
Marc Clifton wrote:
if simple code like this is so poorly implemented, warnings aren't fixed, and there's not comment to explain what the if statements and switch statements are even doing, what can I expect in complicated code?
Recently had to do post hoc unit testing on a complex piece of software that had virtually no comments, and the few it did have were pretty useless.
Marc Clifton wrote:
Refactoring is abused, IMO. How much refactoring could be eliminated if you just wrote the code right to begin with?
There are different types of refactoring. 1. Refactoring code because it's bad. 2. Refactoring while writing it. 3. Refactoring for extension. Maybe others... Only the first is an undesirable situation. However, I think that's what you mean?
Kevin
-
I believe Cockburn, Beck, and Cunningham probably intended it to be rather immediate and fearless. When I write a method I initiall my write it messy but I don't call it down. After I write code, I reread it to eliminate obvious logic errors and rewrite bits and pieces to be more maintainable and more efficient (if possible, maintainable is number 1). Then I test and then I may rewrite once again. I tidy up comments put a comment header and then call it done. This is refactoring at its best. Of course when you get to a higher level and can see the bigger picture you can realize that the design is wrong, in which case that should be refactored, immediately. Joel, from Joel on Software, disagress but he is in NYC so his opinion doesn't count towards reality sometimes. My point refactoring is misunderstood by management and paper on the wall programmers. If its done right its beautiful. Oh, yeah, ugly code makes me bash my head on the desk sometimes. I have also been known to throw stuff at people that write brain farts.
A man said to the universe: "Sir I exist!" "However," replied the Universe, "The fact has not created in me A sense of obligation." -- Stephen Crane
Ennis Ray Lynch, Jr. wrote:
When I write a method I initiall my write it messy but I don't call it down. After I write code, I reread it to eliminate obvious logic errors and rewrite bits and pieces to be more maintainable and more efficient (if possible, maintainable is number 1). Then I test and then I may rewrite once again. I tidy up comments put a comment header and then call it done.
This is my working style too. :) Sometimes when I'm fixing bugs in code I've not written I have to refactor the existing code first just so that I can see how to fix the bug.
Kevin
-
Looking at bad code makes me cringe. When I look at something like a simple function that returns a string and the compiler warns about unreachable code detected and the code itself has multiple return points, I can't help but wonder, if simple code like this is so poorly implemented, warnings aren't fixed, and there's not comment to explain what the if statements and switch statements are even doing, what can I expect in complicated code? I have this visceral emotional reaction to bad code, it makes me not even want to touch the whole project, even if I'm working on an isolated part of it. I'm still associated with the bad code. Do you ever feel that way? Or am I letting my emotions get in the way here? And then I hear the "we need to get something out, and we'll refactor it later". Refactoring is abused, IMO. How much refactoring could be eliminated if you just wrote the code right to begin with? And come now, does refactoring really happen? It's more like a meditation than a practice. What's the sound of one programmer refactoring? Yeah, exactly. Shouldn't code get reviewed frequently, even in the midst of a the continuous fire drill? I mean, after all, if you acknowledge that the fire alarm is always sounding, then you might as well figure out how to do the programming better and smarter, rather than take the McGyver approach and hope the ducttape lasts to end of the episode. Does your team ducttape (I always thought it was duck tape) the code and promise each other to refactor later? About that lying questionnaire below, good intents are almost like lies, but you're never actually caught at the lie because you can always say "it'll happen soon." So, is there some truth my conception that bad, uncommented simple code is a portent of bad, uncommented complicated code? And is there some merit to the conclusion that the bad, uncommented, complicated code will also be really buggy? Is there some merit to the attitude that refactoring should be minimized? What are your thoughts? Marc
Some people believe what the bible says. Literally. At least [with Wikipedia] you have the chance to correct the wiki -- Jörgen Sigvardsson
People are just notoriously impossible. --DavidCrow
There's NO excuse for not commenting your code. -- John Simmons / outlaw programmerRefactoring is about altering the structure of code/designs to accomodate new requirements (aka features, performance, etc.) It is not about making code "good." Code should always be good, if not fantastic. 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: My WPF Blog[^]
-
Looking at bad code makes me cringe. When I look at something like a simple function that returns a string and the compiler warns about unreachable code detected and the code itself has multiple return points, I can't help but wonder, if simple code like this is so poorly implemented, warnings aren't fixed, and there's not comment to explain what the if statements and switch statements are even doing, what can I expect in complicated code? I have this visceral emotional reaction to bad code, it makes me not even want to touch the whole project, even if I'm working on an isolated part of it. I'm still associated with the bad code. Do you ever feel that way? Or am I letting my emotions get in the way here? And then I hear the "we need to get something out, and we'll refactor it later". Refactoring is abused, IMO. How much refactoring could be eliminated if you just wrote the code right to begin with? And come now, does refactoring really happen? It's more like a meditation than a practice. What's the sound of one programmer refactoring? Yeah, exactly. Shouldn't code get reviewed frequently, even in the midst of a the continuous fire drill? I mean, after all, if you acknowledge that the fire alarm is always sounding, then you might as well figure out how to do the programming better and smarter, rather than take the McGyver approach and hope the ducttape lasts to end of the episode. Does your team ducttape (I always thought it was duck tape) the code and promise each other to refactor later? About that lying questionnaire below, good intents are almost like lies, but you're never actually caught at the lie because you can always say "it'll happen soon." So, is there some truth my conception that bad, uncommented simple code is a portent of bad, uncommented complicated code? And is there some merit to the conclusion that the bad, uncommented, complicated code will also be really buggy? Is there some merit to the attitude that refactoring should be minimized? What are your thoughts? Marc
Some people believe what the bible says. Literally. At least [with Wikipedia] you have the chance to correct the wiki -- Jörgen Sigvardsson
People are just notoriously impossible. --DavidCrow
There's NO excuse for not commenting your code. -- John Simmons / outlaw programmerI agree - refactoring has become a bucket for all excuses. I believe it has its place but at a higher level than the method level. All code should be intended as production at all times. As needs change and grow then refactoring original design is warranted. Recognizing this allows us to not over-design for perceived future needs - especially when they always change and thus our design becomes wrong anyways. A systemic lack of comments and indicators like multiple return points (amongst many other subtleties) by a "senior" developer indicates a lack of personal drive to improve one's self (read a friggin' book!) - a lack of professionalism. These are the shots over the bow of not caring and likely bad, buggy code.
-
Looking at bad code makes me cringe. When I look at something like a simple function that returns a string and the compiler warns about unreachable code detected and the code itself has multiple return points, I can't help but wonder, if simple code like this is so poorly implemented, warnings aren't fixed, and there's not comment to explain what the if statements and switch statements are even doing, what can I expect in complicated code? I have this visceral emotional reaction to bad code, it makes me not even want to touch the whole project, even if I'm working on an isolated part of it. I'm still associated with the bad code. Do you ever feel that way? Or am I letting my emotions get in the way here? And then I hear the "we need to get something out, and we'll refactor it later". Refactoring is abused, IMO. How much refactoring could be eliminated if you just wrote the code right to begin with? And come now, does refactoring really happen? It's more like a meditation than a practice. What's the sound of one programmer refactoring? Yeah, exactly. Shouldn't code get reviewed frequently, even in the midst of a the continuous fire drill? I mean, after all, if you acknowledge that the fire alarm is always sounding, then you might as well figure out how to do the programming better and smarter, rather than take the McGyver approach and hope the ducttape lasts to end of the episode. Does your team ducttape (I always thought it was duck tape) the code and promise each other to refactor later? About that lying questionnaire below, good intents are almost like lies, but you're never actually caught at the lie because you can always say "it'll happen soon." So, is there some truth my conception that bad, uncommented simple code is a portent of bad, uncommented complicated code? And is there some merit to the conclusion that the bad, uncommented, complicated code will also be really buggy? Is there some merit to the attitude that refactoring should be minimized? What are your thoughts? Marc
Some people believe what the bible says. Literally. At least [with Wikipedia] you have the chance to correct the wiki -- Jörgen Sigvardsson
People are just notoriously impossible. --DavidCrow
There's NO excuse for not commenting your code. -- John Simmons / outlaw programmerMarc Clifton wrote:
bad, uncommented simple code is a portent of bad, uncommented complicated code
It's not a portent, it's a guarantee. If the simple stuff isn't done correctly, there's no way that the complex stuff is right.
Marc Clifton wrote:
bad, uncommented, complicated code will also be really buggy
Again, this is guaranteed. Poorly crafted code can't be correct. In both cases, note that the converse isn't true. Code, either simple or complex, can be beautifully commented and well-engineered, and still be full of bugs.
Software Zen:
delete this; -
Looking at bad code makes me cringe. When I look at something like a simple function that returns a string and the compiler warns about unreachable code detected and the code itself has multiple return points, I can't help but wonder, if simple code like this is so poorly implemented, warnings aren't fixed, and there's not comment to explain what the if statements and switch statements are even doing, what can I expect in complicated code? I have this visceral emotional reaction to bad code, it makes me not even want to touch the whole project, even if I'm working on an isolated part of it. I'm still associated with the bad code. Do you ever feel that way? Or am I letting my emotions get in the way here? And then I hear the "we need to get something out, and we'll refactor it later". Refactoring is abused, IMO. How much refactoring could be eliminated if you just wrote the code right to begin with? And come now, does refactoring really happen? It's more like a meditation than a practice. What's the sound of one programmer refactoring? Yeah, exactly. Shouldn't code get reviewed frequently, even in the midst of a the continuous fire drill? I mean, after all, if you acknowledge that the fire alarm is always sounding, then you might as well figure out how to do the programming better and smarter, rather than take the McGyver approach and hope the ducttape lasts to end of the episode. Does your team ducttape (I always thought it was duck tape) the code and promise each other to refactor later? About that lying questionnaire below, good intents are almost like lies, but you're never actually caught at the lie because you can always say "it'll happen soon." So, is there some truth my conception that bad, uncommented simple code is a portent of bad, uncommented complicated code? And is there some merit to the conclusion that the bad, uncommented, complicated code will also be really buggy? Is there some merit to the attitude that refactoring should be minimized? What are your thoughts? Marc
Some people believe what the bible says. Literally. At least [with Wikipedia] you have the chance to correct the wiki -- Jörgen Sigvardsson
People are just notoriously impossible. --DavidCrow
There's NO excuse for not commenting your code. -- John Simmons / outlaw programmerIMO, refactoring has to happen. Even if you wrote code the right way to begin with, requirements change. When requirements change, your code architecture has to change to reflect that. Often times, that's where refactoring comes in for us.
Marc Clifton wrote:
And come now, does refactoring really happen?
Absolutely. I do a little everyday at work.
Marc Clifton wrote:
Does your team ducttape (I always thought it was duck tape) the code and promise each other to refactor later?
We refactor when it's needed. I think the only exception is large refactors that would takes many, many months to complete. For example, after working in the same codebase for 2 years, we've recently started using test driven development. Much of our code up to this point wasn't designed with testing in mind, so if we really want to test a piece of code, it often has to be refactored. UI code is a big example here: I now see that most of the logic in our UI code simply cannot be tested because it's too intertwined with the UI code. So we've started to use the MVP pattern to seperate the logic and the UI code, thus allowing us to test the logic of the UI without getting entangled in UI code. But to take a timeout and refactor our hundreds of controls and forms to use the MVP pattern with unit testing would just be too huge a refactor. We simply don't have time to spend a couple months to do this. Instead, I'm migrating pieces at a time. Also, all new pieces use the MVP pattern with unit testing. So the code migrates over time. Besides the rare huge refactoring like that (maybe refactor isn't even the right word in that scenario), we do smaller refactors often, every day. Pulling interfaces out of classes, having consuming classes use interfaces (which can be mocked in unit testing) instead of concrete classes, renaming classes and namespaces to better reflect their usage (again, things evolve), making things simpler, the list goes on. In that sense, we refactor all the time. p.s. By the way Marc, [happy birthday](http://judahhimango.com/music/the beatles - birthday.mp3)[[^](http://judahhimango.com/music/the beatles - birthday.mp3)] man! Have a great, happy birthday weekend. :cool:
Tech, life, family, faith: Give me a visit. I
-
I agree - refactoring has become a bucket for all excuses. I believe it has its place but at a higher level than the method level. All code should be intended as production at all times. As needs change and grow then refactoring original design is warranted. Recognizing this allows us to not over-design for perceived future needs - especially when they always change and thus our design becomes wrong anyways. A systemic lack of comments and indicators like multiple return points (amongst many other subtleties) by a "senior" developer indicates a lack of personal drive to improve one's self (read a friggin' book!) - a lack of professionalism. These are the shots over the bow of not caring and likely bad, buggy code.
Cotter wrote:
indicates a lack of personal drive to improve one's self (read a friggin' book!) - a lack of professionalism
Most programmers don't read books about the art of programming - according to a C++ guru I once read.
Kevin
-
I agree - refactoring has become a bucket for all excuses. I believe it has its place but at a higher level than the method level. All code should be intended as production at all times. As needs change and grow then refactoring original design is warranted. Recognizing this allows us to not over-design for perceived future needs - especially when they always change and thus our design becomes wrong anyways. A systemic lack of comments and indicators like multiple return points (amongst many other subtleties) by a "senior" developer indicates a lack of personal drive to improve one's self (read a friggin' book!) - a lack of professionalism. These are the shots over the bow of not caring and likely bad, buggy code.
Cotter wrote:
A systemic lack of comments and indicators like multiple return points
What do you have against multiple return points? What's wrong with this?
public int Foo
{
get
{
if( muck )
return 0;
return 42;
}
}:josh: My WPF Blog[^]
-
Cotter wrote:
A systemic lack of comments and indicators like multiple return points
What do you have against multiple return points? What's wrong with this?
public int Foo
{
get
{
if( muck )
return 0;
return 42;
}
}:josh: My WPF Blog[^]
Josh Smith wrote:
What do you have against multiple return points?
It used to be that the stack would not get cleaned up if a function returned from more than one spot. That was several generations ago, however.
Josh Smith wrote:
What's wrong with this?
How would you set a breakpoint to know which return point was going to be used? I'd prefer:
public int Foo
{
int x = 42;
get
{
if( muck )
x = 0;
}
return x; // set one breakpoint here
}
"Money talks. When my money starts to talk, I get a bill to shut it up." - Frank
"Judge not by the eye but by the heart." - Native American Proverb
-
Ennis Ray Lynch, Jr. wrote:
When I write a method I initiall my write it messy but I don't call it down. After I write code, I reread it to eliminate obvious logic errors and rewrite bits and pieces to be more maintainable and more efficient (if possible, maintainable is number 1). Then I test and then I may rewrite once again. I tidy up comments put a comment header and then call it done.
This is my working style too. :) Sometimes when I'm fixing bugs in code I've not written I have to refactor the existing code first just so that I can see how to fix the bug.
Kevin
In large teams I feel guilty but rewriting crap code is required for understanding. Plus I delete some comments:
//assign 5 to x
int x = 5;
//loop through 5 times
for(int i=0;isnip
A man said to the universe:
"Sir I exist!"
"However," replied the Universe, "The fact has not created in me A sense of obligation."-- Stephen Crane -
Josh Smith wrote:
What do you have against multiple return points?
It used to be that the stack would not get cleaned up if a function returned from more than one spot. That was several generations ago, however.
Josh Smith wrote:
What's wrong with this?
How would you set a breakpoint to know which return point was going to be used? I'd prefer:
public int Foo
{
int x = 42;
get
{
if( muck )
x = 0;
}
return x; // set one breakpoint here
}
"Money talks. When my money starts to talk, I get a bill to shut it up." - Frank
"Judge not by the eye but by the heart." - Native American Proverb
that's fine for a 7 line function. in practice, however, functions can be substantially more complex, and slavishly following the 'one return point' rule forces you to use logic tailored more towards following that rule than to solving the actual problem at hand.
-
Looking at bad code makes me cringe. When I look at something like a simple function that returns a string and the compiler warns about unreachable code detected and the code itself has multiple return points, I can't help but wonder, if simple code like this is so poorly implemented, warnings aren't fixed, and there's not comment to explain what the if statements and switch statements are even doing, what can I expect in complicated code? I have this visceral emotional reaction to bad code, it makes me not even want to touch the whole project, even if I'm working on an isolated part of it. I'm still associated with the bad code. Do you ever feel that way? Or am I letting my emotions get in the way here? And then I hear the "we need to get something out, and we'll refactor it later". Refactoring is abused, IMO. How much refactoring could be eliminated if you just wrote the code right to begin with? And come now, does refactoring really happen? It's more like a meditation than a practice. What's the sound of one programmer refactoring? Yeah, exactly. Shouldn't code get reviewed frequently, even in the midst of a the continuous fire drill? I mean, after all, if you acknowledge that the fire alarm is always sounding, then you might as well figure out how to do the programming better and smarter, rather than take the McGyver approach and hope the ducttape lasts to end of the episode. Does your team ducttape (I always thought it was duck tape) the code and promise each other to refactor later? About that lying questionnaire below, good intents are almost like lies, but you're never actually caught at the lie because you can always say "it'll happen soon." So, is there some truth my conception that bad, uncommented simple code is a portent of bad, uncommented complicated code? And is there some merit to the conclusion that the bad, uncommented, complicated code will also be really buggy? Is there some merit to the attitude that refactoring should be minimized? What are your thoughts? Marc
Some people believe what the bible says. Literally. At least [with Wikipedia] you have the chance to correct the wiki -- Jörgen Sigvardsson
People are just notoriously impossible. --DavidCrow
There's NO excuse for not commenting your code. -- John Simmons / outlaw programmerMarc Clifton wrote:
I have this visceral emotional reaction to bad code, it makes me not even want to touch the whole project, even if I'm working on an isolated part of it. I'm still associated with the bad code. Do you ever feel that way?
Yes. Worse, though, is when I'm forced to write code that's not up to my quality standards, because the project manager doesn't want me to take the time to write it the right way. It makes me feel... well... dirty. :~
Marc Clifton wrote:
How much refactoring could be eliminated if you just wrote the code right to begin with?
And how much time could be saved even before the release that you're skimping so that you can meet? Chances are pretty high in many cases that that code you rushed and did a bad job on will come back to haunt you sooner, not just later.
Marc Clifton wrote:
And come now, does refactoring really happen? It's more like a meditation than a practice.
Refactoring happens in my code quite a bit - but it's less likely to happen in convoluted code that is hard to make sense of later when you come back to refactor. And the type of people who use "we can refactor later" as an excuse to write poor code are the ones who are the least likely to actually take the bother to refactor later.
Marc Clifton wrote:
Shouldn't code get reviewed frequently, even in the midst of a the continuous fire drill? I mean, after all, if you acknowledge that the fire alarm is always sounding, then you might as well figure out how to do the programming better and smarter, rather than take the McGyver approach and hope the ducttape lasts to end of the episode.
Exactly.
-
Looking at bad code makes me cringe. When I look at something like a simple function that returns a string and the compiler warns about unreachable code detected and the code itself has multiple return points, I can't help but wonder, if simple code like this is so poorly implemented, warnings aren't fixed, and there's not comment to explain what the if statements and switch statements are even doing, what can I expect in complicated code? I have this visceral emotional reaction to bad code, it makes me not even want to touch the whole project, even if I'm working on an isolated part of it. I'm still associated with the bad code. Do you ever feel that way? Or am I letting my emotions get in the way here? And then I hear the "we need to get something out, and we'll refactor it later". Refactoring is abused, IMO. How much refactoring could be eliminated if you just wrote the code right to begin with? And come now, does refactoring really happen? It's more like a meditation than a practice. What's the sound of one programmer refactoring? Yeah, exactly. Shouldn't code get reviewed frequently, even in the midst of a the continuous fire drill? I mean, after all, if you acknowledge that the fire alarm is always sounding, then you might as well figure out how to do the programming better and smarter, rather than take the McGyver approach and hope the ducttape lasts to end of the episode. Does your team ducttape (I always thought it was duck tape) the code and promise each other to refactor later? About that lying questionnaire below, good intents are almost like lies, but you're never actually caught at the lie because you can always say "it'll happen soon." So, is there some truth my conception that bad, uncommented simple code is a portent of bad, uncommented complicated code? And is there some merit to the conclusion that the bad, uncommented, complicated code will also be really buggy? Is there some merit to the attitude that refactoring should be minimized? What are your thoughts? Marc
Some people believe what the bible says. Literally. At least [with Wikipedia] you have the chance to correct the wiki -- Jörgen Sigvardsson
People are just notoriously impossible. --DavidCrow
There's NO excuse for not commenting your code. -- John Simmons / outlaw programmerYes crap code happens every day. Why... lots of reasons, like crap developers (spend some time in the forums) and crap managers and crap companies.
Marc Clifton wrote:
And then I hear the "we need to get something out, and we'll refactor it later". Refactoring is abused, IMO.
Refactoring "should" occur when the design must change due to an analysis error or requirement change, not as an excuse to do crap work originally. And all of this is under the guise of "it's faster", which in my experience has never proven to be true, it's all bullshit. Anyway you don't need to believe me, see the web for Technical Debt[^]
led mike