
Take a moment to reflect on how bad your code once was - earlz
https://gist.github.com/Earlz/5848045
======
DanWaterworth
I don't have to look back very far. I can be disgusted in the afternoon by
code I wrote in the morning.

~~~
froh42
When I read own code that is older than a month or so I'm annoyed because that
code should have been a lot better from my current perspective.

If this feeling ever stops it means I've stopped learning and stopped personal
progress. I'll stop coding that day.

Thankfully it didn't go away for the last 30 years I was programming, so it
will probably stay with me a little longer.

~~~
taude
I dont think its necessarily skills getting better, but more often than not,
it's just seeing a solution differently after your mind took a break from the
initial work on it. I've never written code that couldn't be made better and
better over time.

------
InclinedPlane
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](http://pastebin.com/Hi2wYSmW) and I think this
is a data file for it:
[http://pastebin.com/eF1WuhVb](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).

~~~
hippich
This is VERY clean code :) Luckily, I do not have any of my code from that age
available :)

------
danso
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.

~~~
IvyMike
> The chunks could be small enough that it hopefully doesn't violate any
> intellectual property rights of the employer.

I would advise never assuming this, and would always get explicit permission,
in writing.

I have worked on projects where even accidentally leaking the language being
used would have revealed something my employer considered secret at the time.

------
yardie
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.

------
dwd
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.

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

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

------
FajitaNachos
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.

------
arocks
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!

------
joeblau
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.

------
IanChiles
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](https://gist.github.com/IanChiles/5560787)

------
pathikrit
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](https://gist.github.com/pathikrit/5848927)

------
Keyframe
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

------
xradionut
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...)

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

------
j45
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?

------
viraptor
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.

------
dutchbrit
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 :).

------
Chris2048
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.

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

