views:

290

answers:

14

It is very difficult to write perfect code because the standards upon which our code is judged is evolving every day. The beautiful as it may be now, is probably going to be ridiculed later.

Have you ever look back at some of your old code and grimaced in pain? If yes, do you have any idea how to overcome this?

+3  A: 

Don't you think it's quite natural, that after some time you become more exprienced, and able to write better code? That's why you can't overcome this.

However, if you are responsible for that code, try to sit down on it from time to time, and refactor. Remember thou, that better is the enemy of good, in other words, if it works leave it alone :)

Marcin Cylke
I wouldn't refactor code, just because I think I could do this in a more elegant way now. I would only refactor it, if I have to fix or extend it.
Tim Büthe
Hear, hear! ;-)
Treb
True, but what about the golden rule of test driven development:- write test, that does not pass- write code, that will cause the test to pass- refactor the codePut aside the TDD if you're not using it, but the rule remains valid.
Marcin Cylke
A: 

It's very difficult to write perfect code because the standards upon which our code is judged is evolving every day.

I don't think that the standards upon which our code is judged is evolving every day.

Have you ever look back at some of your old code and grimace in pain?

Surely.

If yes, have any idea to overcome this?

Use peer review, and read the book "Clean Code".

Andrea Francia
You disagree on "It's very difficult to write perfect"? That's a statement!
Tim Büthe
Maybe he just disagrees with the standards evolvement?
Treb
+2  A: 

It happens on a regular basis. It's called development ;) The only way to "overcome" it is to enjoy the feeling that you know so much more today than you did when you wrote that code.

Fredrik Mörk
+16  A: 

There is no reason at all to want to overcome this. It is a good sign!

If you can see things in your old code that you liked when you wrote it, but don't like today, it shows that you have learned something (most probably while you were coding back then).

Of course, whenever this happens, you have to consider following the Boy Scout Rule of refactoring. Consider, that is, not follow blindly. I agree with Marcin Cylke.

Treb
+4  A: 

The answer is yes, everybody does! And no, you can not overcome this! And, I think it is a good thing, because you see you getting better and better.

Tim Büthe
A: 

Sometimes I find my old code better than I would have written it today, with nice ideas both in terms of design and readability. But this is not usual.

When I find my old code poorly written, I think that it is time to learn from it and identify best practices that were not used then and that would help me writing better code from now on.

mouviciel
+1  A: 

Most definitely. Honestly, I'd be a little worried if I didn't grimace at some of my old code: it would be a sign that I'm not progressing as much as I'd like. Remember, as software developers, we are supposed to be constantly learning and improving: one of our prime objectives is to just be "better than we were a year ago."

htw
A: 

I also think it happens because there is this idea of a "perfect" solution. One that is easy to read, uses the correct idioms and patterns, is exactly as short as it should be, is completely devoid of code smells, and so on. When you implement a solution in practice, this is hardly ever the case. You need to choose between different ways to approach the problems - and whichever path you take, you will end up with something that could be better if you had chosen a different path.

I think you will just have to accept this. And when it's really terrible, you can always refactor.

waxwing
A: 

Of course!

Experience is the answer. To overcome this, when this happens refactor those pieces of code.

Eventually you'll get the the point where you look back at old code and suprise yourself by how smart you were! (Not often, but it happens)

monkut
A: 

I think everybody who does program for a while has. I also think one of the most funny things is to rewrite old, small projects and have a look at the number of lines used in the first try and in a try a (few) years later.

I have wrote some buggy code in one of my frist years which counted 1000 lines, I could rewrite it in a 100 lines or less nowadays. Though when doing this one has to ask himself if it is still readable for any other person, a good thing to ask in this case is if a random developer (with same skill or better) could continue your project.

bastijn
+4  A: 

I do agree with the general sentiment that not feeling the urge to refactor to avoid embarrassment when confronted with any coding you did more than 3 months ago is probably a sign that you have either stopped caring or stopped learning.

That being said, I found that the code that does stand the test of time with less wear than average tends not to be the code that shows the most architectural bravado, the deepest platform insight or the most intellectual prowess, but invariably is the code that was written to be the easiest to read and understand. KISS still rules the roost.

Peter Stuer
+1  A: 

Often when I look at old code my first though is "WTF?!? Did I write that?"

The funniest thing was when I found out how my coding style changed over time:

// 1998
if(a==b){
  doit();
  domore();}

// 2001
if(a==b) 
{  doit();
   domore();
}

// 2002
if (a==b) 
{  
   doit();
   domore();
}

// from 2004
if ( a == b ) 
{  
    doit( );

    domore( );
}

Maybe there is a correlation with the screen resolution supported by my monitor..

codymanix
Are we allowed to say '2002 is more readable than 2004'?
Jonathan Leffler
A: 

It's a pretty natural feeling to be embarrassed, ashamed, etc. over older code.

As far as overcoming it? Two ways:

  1. Develop a positive perspective, that you've learned so much since writing that code. Fix the code based on your updated knowledge, and move on.

  2. Never get better at your craft, and your old code will always look fine to you. :)

The one caveat to watch out for is to not get too critical of your past work, unless you want to be rewriting the same chunk of code every time you take another look at it. Improvements are nice, but keep your priorities straight.

JohnRegner
A: 

You know you are getting better when you have the opposite reaction - 'OMG, this is cool. Wait, I wrote this?'

Doesn't happen often, though.

Andrei Taranchenko
That happens few enough times to normally remember "that awesome piece of code for Project X" or whatever... :)
Splash