The longer we do anything in life, the more bad habits we will inevitably accumulate. And the same holds true for programming. Sometimes we are in a rush and we have deadlines and so we jump to these poor habits in order to get things done. Eventually, we always have to pay the price of those moments.
So before you type another line of code, here are 6 things that you might be doing without even noticing.
Note, I have been guilty of all of these in the past.
6. Not checking in your code
We get it. You'll do it later. You're busy right now and having to come up with a clever commit message and comparing files isn't necessarily the highest priority at the moment. Most of the time that might be true.
But it is a bad habit, by definition. I'm guilty of it myself. In the past at various companies, several days would go by without a single commit on my end to the master repo. In my defense, I was only one of two people on this particular project. So there was less urgency in having me sync code constantly.
But this article is about bad habits, and not about their potential side-effects. There's a few reasons why you should have consistent code check-ins.
- Gives you a stable place to stop
- Reduces conflicts with other programmers code
- Prevents code loss in case of an emergency
- Better safe than sorry
You might think that nothing bad could ever go wrong, and so maybe that last point isn't very valid. Well, let me tell you right now, they call them accidents for a reason.
I worked at a company once where an overnight water sprinkler malfunction managed to turn my cubicle into a makeshift fishing hole. The result? A fried PC with essentially unrecoverable files and work. It wasn't a huge deal overall, as most of the vital work had been checked in. But had it not been, I would of been looking at several weeks of staying late in order to catch up.
5. Commenting too much
Comments are a great tool for further clarifying logic that isn't clear. For example:
// returns discounted sales amount for the month
function postProcess(salesAmount){
return salesAmount * .83;
}
In that case, anyone looking at the code at some future time would have no issue deciphering just what was going on with the logic.
But I've also seen the following in the past:
// function to calculudate new sales amount
function postProcess(salesAmount){
let multiplier = .83; // the amount used to reduce the overall amount
let newamount = salesAmount * multiplier; // the newly calculated sales amount
return newamount; // return the result
}
Both of those examples essentially say the exact same thing. The second version however takes longer to read and is more prone to misinterpretation.
It also just feels like there's more complexity there, when in fact it is a relatively straightforward operation.
Assume that the person whom will read your code one day is a fully capable engineer and that they can fill in the gaps in terms of what's happening.
As mentioned, commenting code should be used for clarification on nuanced sections of logic and not so much as documentation.
4. Commenting too little
As mentioned above, some things do require further clarification in order for anyone looking at it to make sense of what's in front of them.
If you are doing any type of mathematical operation that isn't clear or seems random, then a comment stating the purpose is in order.
In my professional career I've spent considerable amounts of time digging through uncommented legacy code essentially treading on eggshells as the slightest change could have a substantial cost associated with it.
The same holds true for my own code as well however. We would all like to think that we can remember every single line of code written forever and ever. But after a few weeks, they might as well have been written by a wizard eons ego.
You're not just commenting for other programmers. You are also leaving behind useful tips and hints for your future self just in case that code needs to be revisited.
To reiterate, too many comments can lead to complexity and confusion, but too little can also lead to the same thing.
3. Writing short concise code
I'll start by saying that writing short and concise code is not a bad thing. In fact, it's what many programmer's strive to do early on in their careers.
But at some point, it gets old. When I see something like the following:
let newdata = data.filter('').sort('').filter('').find('')...
I don't particularly applaud the person that did it. The code might work just fine and make total sense to the person who wrote it.
But writing one-liners and chaining functions together makes future debugging incredibly hard to do. I can't, for example, output the first set of filtered data to analyze and review.
While it may seem tedious and pointless, breaking down every step into its own declaration is overall a more secure and simpler to work with mechanism.
let newdata = data.filter('')...
newdata = newdata.sort('')...
newdata = newdata.filter('')...
The not so obvious benefit here, is that I can add a breakpoint to each individual item when debugging.
I can also interject other logic before or after any of the steps listed in case the need arises.
It important to realize that at some point everything changes. Logic changes, programmer's change, frameworks change. And the easier it is to make that transition, the less chance there is of something going wrong.
2. Counting lines of code
This is something that I've seen project managers do more so than actual programmers. So if you're a project manager, then this one is for you.
Using the number of lines in a project as a barometer for success is like rating a book by the number of sentences. In a race to see who wrote the most sentences, then yes, the longer books win. In a race to see who wrote the most entertaining and cohesive story however, things get complicated.
Don't use the amount of code that you write as a barometer for anything. A thousand lines of hard to read, error-prone and unsafe code is not better than 100 lines of clear and well defined code.
It's all about the quality and not the quantity.
I've easily written millions of lines of code during the past 20 years. But that doesn't make me a better programmer. Most of those lines probably weren't that great and odds are that I've deleted a fair number of them already.
Having said that though, you will write a tremendous amount of code in this field. And that isn't something to shy away from. A programmer who has written 200,000 lines of code probably does have more experience than one who has written 10,000. They have seen more errors and have encountered more scenarios and that's definitely a good thing.
Just don't use that number to assume that the piece of software in front of you is of high quality.
1. Not documenting enough
I assure you, if there is an error that you encountered that was insanely complicated and that you never thought you would overcome, but then in a dream one day you suddenly found the solution, odds are you are going to encounter that error again over..and over.
Maybe not tomorrow and maybe not the week after. But in a month, when you get that cryptic error message in red taunting your ability to code, you are going to wish you remembered what the solution was.
This is why most companies have some form of documentation protocol in place. And why you should have your own as well for your personal projects.
My documentation strategy is pretty straightforward. I essentially blog about any challenging issues that I encounter. Some of the most popular articles on this blog are the ones in which I solve my own issue, such as the following:
How to setup an SSL certificate with GoDaddy
I don't typically setup SSL certificates on servers. I do it perhaps 3-4 times per year. But when I do, I'm as human as everyone else, and I tend to forget the process. That article jogs my memory every single time and I am always glad to have it around just in case.
You don't have to blog about it of course. There are plenty of note taking apps, such as OneNote, that you can use. Being consistent with your documentation is the important part and building that habit does take time.
At the end of the day, the easiest way to get rid of a bad habit, is to replace it with a better one.