Subscribe to Adventures in Spaghetti code        RSS Feed

Don't make the mistakes I made

Icon Leave Comment
The biggest mistake I made coming to coding was thinking that it was easy and that there was not that much to learn. I hated reading books about coding. I made a very strong and sincere effort to read these books but every time I tried reading them after 45 minutes my head would grow numb and nauseous. I find this very paradoxical because I love books on math, logic and academic philosophy. For some reason coding books were the one nut I could not crack. What is also strange is that I really took to coding like a fish in water. Since I could not read the books, I had to hire personal tutors to teach me how to do it (7$ an hour from India). This is how I learned coding, I just watched them code and after about 6 weeks it finally clicked. However, once it finally clicked I made the mistake of underestimating the science of coding and thinking there really wasn't much to learn. The best analogy I can use is: writing a paragraph is easy, writing a whole book is hard. Sure, I had enough coding skills to write simply programs but from the very beginning I was working on developing software that could find contradictions in natural language sentences. I eventually wrote 9000 lines of python code. I slowly began to realize that there is something called code rigidity and fragility. I had known about these concepts very early on but thought "doesn't apply to me". But did I ask myself the following question: how do you know your code is not fragile or rigid? No, I didn't. I just assumed that my code must not be rigid and fragile because I'm so brilliant that those types of things only happen to lesser minds. I was wrong in a very major way. I then learned about cyclomatic complexity and was able to download the program and measure my code's cyclomatic complexity. Now, admittedly cyclomatic complexity is not a perfect measure, there are some problems with it, but it's the only metric that I'm aware of that can reasonably measure the complexity of a code. My code turned out to have a rating of 20 (the lower the better) and some coders set a goal of no greater than 10. There were also about 8 functions which had a rating higher than 100 or 200. Of course, there are ways to cheat and all that, you can just write little tiny functions that have a CC metric of 2 or 3 to bring your score down, but the bottom line is you have to have a code where you have as few moving parts as possible. For the last 6 weeks I have put a lot of time and energy into refactoring my code and it it is a lot of work.

I've read quite a lot of those articles roughly called 15 tips to write better code. So here are three principles that I think are hinted at in those articles but are not very well emphasized. Also, these three principles only apply to code that you plan on writing for a very long time and updating constantly.

1. Make it so that you have to remember the fewest number of things.

I am constantly having to look stuff up so as to refresh my memory as to what I decided a long time ago. If I made fewer decisions and invented fewer rules then I don't have to look up stuff. The time spent relearning old code is very high and that number has to be reduced as much as possible.

2. Organization is everything.

I have a list of the most important lists and dictionaries in my program. It's quite easy to let this list go to rot and just try to keep in your head but this is bad practice. Always keep that list of the most important info on your code up to date so that it is easy to look up obscure information.

3. Spend 1 hour refactoring now, rather than 2 hours refactoring later.

The temptation to not refactor is very strong. After all, it's so much more exciting to code some new feature because then you get to see your program becoming more powerful. But I've found that if I do not refactor immediately after writing a code and discovering a better way to do it then I will just lose time later. If I continue to work with a disorganized code then this will accumulate in numerous amounts of wasted time debugging in the future.

0 Comments On This Entry


Trackbacks for this entry [ Trackback URL ]

There are no Trackbacks for this entry

October 2017

151617 18 192021


    Recent Entries

    Recent Comments

    Search My Blog

    0 user(s) viewing

    0 Guests
    0 member(s)
    0 anonymous member(s)