Top 7 Programming Habits Make You a Better Programmer

Programming Habits Make You a Better Programmer

Programming habits, we all have them. Both good and bad. But when you start adopting the right programming habits you can seriously boost your efficiency. Not only will these good habits impact you, but most likely they will also impact the people around you.

Like Denis Waitley said: “The truth is, you don’t break a bad habit; you replace it with a good one”. So that’s exactly why we’ll go over this list of seven programming habits that I think will make you a better programmer.

Here is the List of Top 7 Programming Habits

Small commits

Small commits make it possible for the developer to give a descriptive commit message. I’m sorry, but “fixed some issues” is not a descriptive commit message.

Your code gets easier to debug as well once you start making small commits. It’s easy to roll back to a previous commit to check whether a bug was introduced in that commit. Once you’ve found the commit where the bug was introduced there’s not a lot of code that could have caused this bug, since the commits are small.

Large commits can have a lot of bad consequences. Because so many things have changed in the commit, it is unclear what has actually changed.

And what about the person that has to do the code review? The reviewer will be afraid of merging the code because it’s just too many things to merge that can potentially break the code.

Code reviews get much easier with small commits. They make it possible to review one change at a time, giving the reviewer the opportunity to understand what is actually being changed.

Don’t repeat yourself

You’ve probably more than once reached the point where you look at a piece of code and think; well… this piece of code kind of looks the same as some code that I’ve written before.

This should ring a bell. Since it’s a situation that you want to avoid. Duplicate code makes your code smell really bad. Code gets harder to maintain since adjustments to this piece of code have to be made in multiple places. This makes it more likely that bugs sneak into the code.

It is considered good practice to follow the DRY (Don’t repeat yourself) principle. This means that once you start typing the same code you should probably refactor your code. Divide your code and logic into smaller reusable units and use that code by calling it where you want.

Once you think you’re done, refactor

Most programmers, especially those with not a lot of experience, think that their job is done once their code works as intended. But the word “done” includes more than just writing a piece of code for a fancy feature.

The code works, right? So what’s the point?

Yeah, you’re right. But before you hop on to the next task you should refactor your code. Refactoring your code will improve readability. Chances are that you didn’t produce the cleanest piece of code you’ve ever written. Some things may be clear to you, but how will other programmers feel about your code if they take a look at it? Be critical about this.

Refactoring can also help to reduce the complexity of the code, which will improve maintainability. In the long run, refactoring your code will pay for itself.

Focus on the business

Most programmers tend to be so focused on learning the tech stack that the business gets out of sight. On the journey to becoming a master of your tech stack, it’s important to keep the business in mind. Why are you building this?

Some developers are only interested in the technical aspects of their job. They don’t care about the business or the economic factors that justify their job’s existence.

Is what you’re working on creating value for the business or are you spending too much time on something that doesn’t really matter? It’s an important question to ask yourself.

Consistency is key

If you’ve decided to do camel casing for your variables, stick with it. Want to use spaces instead of tabs? Great! Whatever you’re doing in your code, at least do it consistently.

The problem with being inconsistent comes from the unavoidable fact that time destroys software. The longer a piece of software exists, and the more people that work on it, the more chaos comes in.

So what can you do to be more consistent?

One of the first things that you should do is pick a style guide. Once you have your style guide, stick to it. You could use a linter that checks your code for style issues.

The second thing is consistent naming. Variables, methods, and classes should be named in the same way. If you want to read more about creating good names in your code.

Just know that consistency has a high impact on the maintainability of your codebase!

Touch it once

I’ll fix it later. Yep, we’ve all heard that before. And we all know how often things got fixed “later”. You’re right. Never. Every time you see a TODO-comment you know someone failed to touch it once.

Also Know: Web Application Development Frameworks

Work on a piece of code or user story from zero till it’s completely finished.

But what does completely finished mean?

It means that your code is refactored, for a start. Just like we discussed before. On top of that, your code needs to be tested. And testing is for most developers probably the least favorite part of their job. But there is more to testing than just clicking through the happy-path scenario. Make sure to test some other scenarios as well. And if you want to go the extra mile you could write some automated tests.

What’s left is the documentation. Is documentation required for this feature? Did you let the tester know how the feature can be tested? Are there any prerequisites that the tester needs to know about?

Never stop learning

New technologies emerge on a daily basis. And sometimes it might seem hard to catch up with all the latest trends. Though you should never stop learning. Because the day you stop learning is the day that you stop growing.

Learning new things is the only way to stay relevant in this ever-changing technology era that we’re living in.

Also Know: Powerful Node.JS Frameworks