That was my first reasonable project in programming. I had written a parser for 2-pass macro assembler using C. It was around 2500 lines of code, I was happy that my code worked in my machine. Better yet, my code worked during the demo as well.That’s a miracle. So I had a great milestone to brag about– THE WORKING CODE. But after I finished the project, I sat after a few weeks to just review the beautiful art that I had created (hehe, I am talking about the code that I had written). I was hardly able to understand anything in my own code !!!!!!!! :)That’s when I learnt some important lessons in programming.
Modules please
My working code contained 2500 lines of C code in the main function. Wow… What an achievement, I thought. But when I reviewed it, I realized that things should not have been this way!!
Lesson Learnt: I should have split the code into nice modules, that would have saved a lot of time during maintenance.
Comments please
I didn’t put comments wherever necessary, so I was caught trying to figure out what each and every line or piece of code did. It was difficult as hell and I wasted a lot of time literally trying to find out what the code did. Remember, this was just few weeks after I wrote the code.
Lesson Learnt: I should have added enough comments for even myself to understand the code in the future
Segregation please
There were not enough segregation between variable declaration, assignment and re-initialization. That caused a lot of confusion when trying to read it through.
Lesson Learnt: I should have segregated the code into blocks of reasonable size and functionality.
Naming conventions please
I was great at naming conventions, I named variables as i1, i2, i3, i4, ii1, ii2, etc.. I thought I understood the code when I wrote it. But when I tried to review it, that’s when I realized that I did a horrible mistake by naming the variables in a clumsy manner.
Lesson Learnt: I should have followed proper naming conventions for variables (No worries about functions, as Ididn’t even bother to write them in the first place)
The code is not just about me
When I was reviewing my own code, I thought “What if someone else would have to maintain this piece of GREAT working code?”. They would have run away seeing the code in the first place.
Lesson Learnt: I should have written code that even someone else should be able to understand.
Both inside and outside of a software are equally important
My code worked great. I was able to show a demo. But what if someone had asked to review the code that I wrote. Luckily there was no marks for the way I wrote the code, so I escaped !!:)That’s when I realized that both the presentation and internals of the software are equally important. Presentation is for the customers and internals is for the programmers.
Lesson Learnt: I should have bothered about writing code in a good way and focus on the internals also !!
Your code will bite you, if you don’t take care of it
Sure it bit me many times when I reviewed the code. Imagine if I were to maintain the code, make some changes here and there. I would have been frustrated to get the output and worse is, it would have taken a lot of time.
Lesson Learnt: If I write bad code, it will start biting either me or who is going to maintain the code.
Short term gain = long-term loss
Initially I had the focus to create the working software. So even though I realized that there were places where I could have improved, I deliberately left them in the interest of time, not to deviate, or from my pure laziness. I took short-term gains, I kept on taking those short-term gains. They were nice, but in the end, I had to lose in the long-term.
Lesson Learnt: I should have focused on long-term rather than shortterm.All said, I was very satisfied with the working code I had. Because that’s a measure of success and a critical source of encouragement. There is no better thing than to see your own code working and producing results that you expected. But in the process, if you also take care of the code that you are writing, over a period of time, you will have 2 things to brag about. One is the working software or output and second thing is the actual Code and the way it is written.