Category Archives: Code quality

Code quality, Tools

Source control commit messages

2 Comments

It might seem to many that this topic is quite insignificant, and should not take much space in the programming blogosphere. If you ever had to browse the history of several dozens of commits, trying to figure out which changes could have introduced a bug, and more importantly why, you understand the importance of it, for sure.

The issue with the generic commit messages is that they don’t provide enough history information. Once you find yourself looking into the file history, you’ll appreciate all the additional effort to which you, or your colleague, has put into thinking of a meaningful commit message. When you think about it, it’s not that much of an effort to think about what you have done and put it into writings for your future self.

Continue reading Source control commit messages →

Code quality, Techniques

Magic literals issue – refactoring case 1

1 Comment

Recently I got to fix a bug that was reported in our system, that the system does not allow PINs of odd length. So, when I looked into the code, I was really surprised to see the way that PIN block Format-1 encoding is implemented. It had several really bad coding practices. I thought it would be good to share it with you, and point out the things that are problematic, in my opinion.

Below you can see how the basic method looks like.

PIN format 1 original implementation

As you can see, there are several hardcoded literals in the method. For me, it was difficult to understand the algorithm for PIN block format 1 (a.k.a ISO-1) encoding is supposed to be applied, just from the reading this method. To understand it better I had to look at the actual definition of how should the PIN block format 1 be implemented. This is, in my opinion, the first issue with the method above – you have to move away from the code to be able to understand what and how the code works. For some complex things it’s always good to consult the available documentation, to make sure you understand the flow. On the other hand, for something simple such as PIN block encoding, I think the code should be written well enough that you don’t have to look further.

Continue reading Magic literals issue – refactoring case 1 →

Code quality, Personal development

On consistency

3 Comments

Personal

One of the most important traits of a good software developer, in my opinion, is consistency. Consistency is needed in so many different aspects of a daily programmers life, and yet it can be easily forgotten when hard times come.

Consistent learning

This one is, I’d say, the most obvious. If you want to get on top, and stay there, you have to consistently invest your time and energy to learn new things. Be it new technologies, new concepts or a new version of a language in which you consider yourself as an expert, you have to constantly devote some time and energy to be able to grasp it. Constant and consistent wish for learning new things is something that puts you on a good path of becoming a better software engineer.

Continue reading On consistency →

Code quality, Code review

Code reviews – checklist

Leave a comment

While writing the post on code reviews, it occurred to me that I could also write about the things I look at while doing it and provide you with a checklist that you could use to perform your own reviews. I will try to explain why I find each of these points important, but you can use or modify the list however it suits you.

So, without further ado, here is the list.

Continue reading Code reviews – checklist →

Code quality, Code review, Techniques, Tools

Code reviews

Leave a comment

Before I dwell into practices that I find useful for improving the code readability, I would like to describe one of my favorite tools for keeping the code clean – code reviews. While it may seem cumbersome and overhead to some, having someone else to have a look at your master piece, you will be surprised how many different things one can find in it. The reviewer might point out to some things that you might’ve overlooked or forgotten, or even point out to a better way to implement a feature, or a piece of it. For example, in the simplest case, a reviewer could have a better knowledge of the source code of the system, or part of it. During the review, he can point it out for you that a method that does exactly the same thing already exists, so that you can remove it. Even better, you could analyze both methods, choose a better implementation, and remove the other one. You know the saying: “Less code, less bugs.“?

Continue reading Code reviews →