Take a moment to reflect on how bad your code once was

I don't have to look back very far. I can be disgusted in the afternoon by code I wrote in the morning.

I wrote a primitive 3D engine in high school, in qbasic. But this was before I knew linear algebra or the idea of z-buffers so it worked based on the math I knew at the time, which ended up being fairly convoluted and a little buggy. And it achieved texture occlusion through drawing the closest shapes last. Also, it didn't have a buffer at all it just drew directly on the screen. It actually worked though, which I thought was pretty cool, but I can only imagine how I would judge the code today.

P.S. Oh man, I found it. OK, here's the code: http://pastebin.com/Hi2wYSmW and I think this is a data file for it: http://pastebin.com/eF1WuhVb

Also, it looks like at some point I learned about z-buffers while writing the thing. I seem to have a couple different versions on backups.

For reference I wrote this when I was a teenager and it ran on a 286 (IBM PS/1).

This would be a great topic for a blog...every few days, a guest blogger submits a chunk of code they wrote a month ago and then their reflections on it today. The chunks could be small enough that it hopefully doesn't violate any intellectual property rights of the employer.

No, absolutely not. To view my old code is to acknowledge that I am not infallible. I'm totally infallible therefore that code simply does not exist. Never happened.

Yet, every so often you have a flash of genius and looking back have no idea how you actually came up with that piece of code - this is where creativity trumps engineering.

Hey pretty good for a 13 year old. Basic doesn't encourage structure ... Nor the 'ide' for that matter. A+

It's even more important to reflect on how bad your code _is_.

I'm a new developer and just had my first experience with this. Went back and looked at something I wrote three months ago and cringed a little. It's good to see how far we come. It's also nice to hopefully think I'll be that much better 3 months from now.

I think every introductory programming language must make it easy to play musical notes with a command as simple as:

    PLAY "T180 DF#A L2 A L4 O4 AA P4 F#F# P4 O3 D"

and draw simple shapes with a statement like:

     LINE (0,0)-(100,175),2,BF

Code in BASIC might have not been the most well-written. But it was certainly fun to program in!

I look at my code from college (our teacher required us to print out everything we coded and physically hand it in along with digital source) and that stuff was actually pretty good. Once I got a real job and learned web programming, my quality went down the toilet though. Now I'm trying to get my skills back.

I was looking back on some old code of mine a month ago or so, and found this amazing bit of ERb I wrote a year or so ago when I just started working with web things. https://gist.github.com/IanChiles/5560787

Oh man, I just dug out my first project - a clone of Breakout written in Turbo C++ when I was 16. I think I managed to make every software design mistake on the way: https://gist.github.com/pathikrit/5848927

I have one of my oldest code with me all the time:

  10 PRINT "KEYFRAME"
  20 GOTO 10

also, on c64 i always made sure to do this first, just to make sure it looks like a terminal to a big machine (for unknown reasons):

  POKE 53280,0 : POKE 53281,0

I've got code that I wrote for the TI-99 4A when I was in high school. It's probably better than the code my boss wrote for a client two years ago that I get to refactor and convert to a new platform. (Yes, the alcohol bill on this project will be high...)

Every single day I look at my code and I think how bad it was yesterday. Sigh.

Any code we write today will be garbage in 10 years looking back. Depending on what you're measuring, you'll look back on did you build something useful, interesting or problem solving?

I did that just yesterday - I needed to modify some code which I wrote in 2005. I could write decent code back then, it worked, it was mostly easy to follow. It was very bad compared to what I'd write these days though... But I learned a lot things from it that I need to keep in mind in the future. Today, I could probably criticise every single line of it...

So - here are my lessons - maybe someone will find them useful (keep in mind this is C code for attiny chip - it's really minimal stuff):

    signed short int P[P_NUM]={0};      // real points
    unsigned short int A[P_NUM]={0};        // meas points

Never name global variables with single letters. Even these are "the" global variables everything else in the code uses. Also comments do not have character limit - if it's "measured points", spell it out. It's useful for grepping.

    unsigned char last=0; // last point+1

I have no idea what +1 means at this point, since it starts at 0. Was the last point -1? I don't think so - again, always add details to comments.

    if(lcd_buff[j]&_BV(i))
        PORT_LED|=_BV(PIN_AB);
    else
        PORT_LED&=~(_BV(PIN_AB));
    PORT_LED|=_BV(PIN_CLK);
    PORT_LED&=~(_BV(PIN_CLK));

Horizontal whitespace matters - code above is barely readable. Defines for constants are good, but could be more descriptive than "PIN_AB". At least PIN_CLK is self-explanatory.

    eeprom_busy_wait(); eeprom_write_byte((uint8_t *) 0x00+1, last);
    eeprom_busy_wait(); eeprom_write_word((uint16_t *)(2+setup_pos*4), A[setup_pos]);
    eeprom_busy_wait(); eeprom_write_word((uint16_t *)(4+setup_pos*4), P[setup_pos]);

If some function repeats so often that you end up prepending it before "actual work", you're probably missing a level of abstraction.

    a*=2;
    a/=dif;
    if(a&1)
        a++;
    a/=2;

Even if some code is specific to that project and crucial to the way it works - comment on "how" and "why". I guess it tries to round the division... but it could be a lot clearer.

    //#define CORRECT(a,b) ((A[b]-A[a])/(P[b]-P[a]))
    //#define CORRECT2(a,b) ((A[b]-A[a])/(P[b]-P[a])>>1)

Never comment out unneeded code. Delete it and let the version control keep the old things. Now I'm not sure if that was commented out for testing, or was it never needed...

Also found out that any in-line state machine will grow until it fills the memory (not hard on attiny ;) ). If you don't design proper macros to construct it, it will become a single function with lots and lots of copy-paste code. It doesn't matter that it was clear at the start and only had 4 states that fit on the screen. Code grows on it's own :)

Also I found a CVS folder in that project. There's one issue with it - I only have the client part - so I can't see any history anymore. DVCSs are a really cool idea.

And for the end -> writing code for a very small chip doesn't mean you have to make the code itself really short, but somehow it seems I was trying to do that. It's the resulting binary that is supposed to be small. Keep in mind how separated are you from the end-result.

I reflect every few months, even though the previous code I wrote isn't "bad", I always find things I would of done differently. It's always good to reflect & refactor :).

I believe the earliest program I'd have written was something on the school computer that printed profanity to the screen; probably rude things about a classmate. Good times.

I don't have my oldest code, probably it was in C. a simple calculator. God I am so embarrassed :-)