Source control commit messages

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

Magic literals issue – refactoring case 1

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