My yearning to read Code Complete started early in 2012 - I came across the book in thelibrary. Most of it didn't make sense to me then but I made a mental note to return to it. Alhamdulilah I eventually got a copy of the book around August 2012 but I couldn't bring myself to read it because of the many pages. Instead I read a couple of .I finally stumbled uponthis year and it helped to revive my long-lost book-reading habits.
I made a simple rule - I would make sure I read for about 30 mins everyday: no more no less; I wasn't bothered about how long it would take or my reading speed, all I cared about was my consistency and understanding of the concepts. I finally finished the book about five months later (sounds like eternity huh?). The book is a little on the verbose side however I learnt a lot - I mean a REAL LOT - and here are my top five lessons from it.
1. Comments Might Actually Imply Bad Code
It was surprising for me to learn that code with LOTS of comments might actually be bad code, strange huh? Yeah you're right! Heavily commented code actually implies that the underlying codebase is abstruse and not self-documenting. Ideally code should be simple, straightforward and not need heavily commented
Moreover if comments are not updated when the original code changes, then they'll become misleading which is even worse than having no comments at all. If you have excessive comments; maybe you should do a review and rework your code. Trust me, most times you'll end up with cleaner codeOK,well hopefully .
Oh, and for those times you write 'rocket science' code (aka impossible to simplify), please save future maintainers the stress and do add comments.
2. Project Management
I think one of the most difficult aspects of the software development profession is getting requirements right. Customer perceptions always change and most times people do not even know WHAT they WANT and when they finally do, they want it delivered last week .
I picked up a couple of ways on how to make this a pleasurable acceptable experience for everyone involved - from developers to project managers to clients. Learn how to say no, estimate project times and methodologies.
3. Leveling Up As A Programmer
I especially love the 'Program into your language, Not in it' quote. Programmers should NOT be limited by the languages or tools they use. If a language does not have a highly desired feature (e.g. asserts, exceptions etc), there is nothing stopping you from implementing your own such features.
Another important point I picked up was the continuous need to consciously improve the quality of my development process. I always get the urge to write quick dirty fixes to problems and the instant gratification of 'working' code fuels this bad habit. No, don't give in! Resist the urge, fight it and crush it! Try to go the extra mile every time you code, that's the way to grow.
I admit that writing 'beautiful code' takes more time and effort however the future savings far outweigh the immediate gains of bad fixes. What is the use of writing quick code in 2 hours and then spending 12 hours to maintain it? It would have been better to spend 6 hours to get it all right.
I once spent about two days trying to get a really critical function to work, I could have written it very quickly (< 2 hours) in sub-optimal ways however it would not have been reusable or flexible or neat.
4. Code Is Written To Be Maintained!
I have known for some time that duplicated code is bad and I finally got to really understand why; the issue is with maintenance. Assuming there are three replicated instances of the same code block; if a new programmer updates only one and forgets to update the others, then 'miracles' will happen during execution and it is going to be extremely difficult to find the issue.
It is also good to create config files that allow you to make platform-wide changes easily ( I use this a lot now); it makes code much more flexible and you do not really need to dive into some 'evil' forest to make changes.
Finally deleting code is a good idea - strange? The smaller the codebase, the fewer the chances of mistakes happening and the smaller the number of things you have to worry about.
5.The Importance Of Planning And Design
Do not just rush into code, think carefully about the design, how to create re-usable components, how to properly name variables and ensure that code is clean and can be easily extended in the future.
I also adopted the Pseudocode Programming Process (PPP) which has saved me a lot of trouble with coding and design; this is how it works: you write pseudocode of what you want to do and how you are going to go about it - I normally just create a list of numbered steps - then you think through your plan and validate all assumptions.
Afterwards coding should be a breeze and even better, the pseudocode (assuming you leave it in the code) can be converted into cool comments. This approach also helps you to prevent second guessing when you get to tricky situations because you already went through the scenario in the past and wrote it out.
I noticed remarkable changes when I stopped diving into code without thinking. For example, I was able to re-use someof my existing code to create an admin dashboard in just about 120 minutes; I bet I would have had to start from the scratch otherwise.
Final Thoughts
The size of the book and its verbosity still, is a great book and all programmers should read it - you will learn a lot and know what habits to drop.
If you also find it too difficult to understand, put it away for some time and make sure you return to it in about six months. The following quote explains this best:
If you're a beginning programmer you won't understand a lot of the material, and if you are experienced, the book will only confirm what you already know. Robert Harvey
Full Post
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment