It’s been a long long time since I last posted in this space. I guess I had been a bit too caught up with life and had been overly focused on my job.
Recently, I realized that I have become quite dormant in the open source communities, and it has been quite some time since I made a worthwhile commit on GitHub / Pagure / BitBucket/etc. My GitHub streak now looks mostly empty which means I have been lazy for over a year now.
So, enough with the slacking around for so long. It’s time to reboot the Bugsmith and get back to the groove of things.
It’s time to draw a line and balance out all the imbalances in my current everyday life. This means fixing my office work schedule, being a bit conscious about my health, and most importantly, getting back to doing something worthwhile with my life.
So, here’s the plan:-
- I’ll start posting more often about anything and everything.
- I’m gonna start sharing as much of my everyday learning related to tech and non-tech using this blog as a medium.
- Finish up all of my pending work [mostly personal stuff which I have been ignoring for a long time now].
- Get back to contributing more pro-actively to Open Source projects which I find interesting.
- Get back to attending tech-meetups in my vicinity and beyond.
- Well basically, get my stuff together and get back to being awesome yet again. 😉
Let’s see how I manage to cope up with my self-expectations! 🙂
For the curious: What made me write this post:
A very good friend of mine called me up today and asked me to go through a web portal that their company is developing to gather some feedback about it. When I opened the page I was quite impressed at first site and everything about the visual styling to the page layout frankly looked quite awesome.
Being a web developer myself, I somehow couldn’t resist the urge of opening up the browser’s developer tools to check out code behind it, and this is where the problems started showing up. As soon as the developer tools window pane opened up eating up half of my screen estate, I noticed the page layout completely fall apart. There was a mess of overlapping texts, visual elements, and what not all over the page rendering the site completely useless.
By instinct I ended up opening the style editor of developer tools to check the CSS to find out where things where breaking, however what I saw was nothing but plain horror for any front-end developer . It had to be one of the most messed up style-sheets I have ever seen! Basically it was nothing but a garbled up mess of style definitions for classes, ids, media queries, etc. What made it even more insane was that there was no homogeneity to the way the document was written, no indentations and to top it all the whole site had the most generically confusing class names that one could ever have nightmares of.
So, I called up my friend to congratulate him about having such a gem of a front end guy work on his team, when I came to know about the most sorry part of the whole story. The person who wrote this code was apparently a man who had quite a large number of years worth of “industry experience” and has been doing front end work since before even I knew what HTML/CSS was!
This is what convinced me to go ahead and post a few simple things about things that one should keep in mind while writing code with a bit of an inclination towards CSS.
For the Restless, Here’s what I want to say:
Here are a few best practices that I personally follow that I’d like to share with everyone:-
- Always remember that any code that you write has a high probability of being extended or needing maintenance in the long term. 70% of most maintenance woes can be avoided by keeping this simple fact in mind while writing code.
- As a direct consequence of this, make sure that whatever code that you write is readable even to the most novice coders out there.
- Adopt good variable naming practices [eg. a variable name “count” is always more desirable than a variable name “i” for a counter variable since it’s name gives a good idea about it’s functionality.]
- Try and write self documenting code, with enough [read: not too less, yet not too much] comments describing what a certain block of code does, and how it does that. The best way to make sure that the comments are of the perfect length would be to make sure that the comments for a block of around 5-10 lines of code is never longer than 2 lines [of 80 characters each].
- One of the places which very often make the biggest mistakes in documenting stuff are the CSS files. A CSS file with a spaghetti mixture of ids, classes, etc. is never a good idea.
- Always try to have a proper document structure for the CSS with logical grouping of style definitions, preferably with an index comment at the very beginning. This helps make the code more readable and thus much more easy to maintain and extend in the long run.
- Indentation is your biggest friend – It helps make the code more easily readable as well as create a well-structured document format. Indentation makes it dead simple to understand the flow of logic within the program and separated different logical groups from each other by creating well nested content for the document.
- Lastly, and more importantly before signing off a piece of code as ready for production, be honest to yourself and ask yourself: “Is this the kind of code that I would like to read through and work upon in a few years time when I have forgotten the minutes of the implimentation?”
I sincerely this helps atleast a few people to understand what it is like to write beautiful code and give them a brief idea about how to do so themselves.