Bruno Peeters Technical Blog

When it comes to commit your work to a software versioning system like git, and putting a message to the commit, it feels like for most developers this is something that needs to be done but they don’t want to spend much time on it. You see cryptic messages within the commit message, which doesn’t add any real value to it. When looking at the goal of a commit (message), what is needed to achieve this goal? In the end, when having a proper clean commit with an accompanied commit message, it will eventually help you speed up your development process.

Since I see writing code as a craftmanship, I’m also very keen on writing high quality code. In the beginning it might take more time to write your code with a high quality, but in the end this will pay back. For sure the bigger a project becomes, more time it will take to add or change functionality or fix bugs in poorly written code.

When it comes to high quality code, of the aspects that come to mind is that it’s clean code. Clean code helps your team to write and maintain in an efficient way your code base. What properties must programming code have to become clean? Robert C. Martin (a.k.a. Uncle Bob), describes in his book “Clean Code – A Handbook of Agile Software Craftsmanship” a number of aspects clean code could have. In this blog, I want to discuss the key takeaways I found within this book.

In an older post, I suggested that constructors never should call methods, which possibly can throw exceptions. What also that blog entry explained, is that this idea mainly came from unmanaged languages like C++, where you could easily introduce memory leaks when a constructor throws an exception.

I however came back from that idea, since it also pollutes a lot of your code having to have initialization methods. You add hereby a unspoken contract that, after calling the constructor, you have to call the initialization method in order to use the class properly.

Code reviews are most of the time introduced within a team to have an additional pair of eyes. Developing is a human practice, hence can lead to mistakes. When you’re developing a piece of code, you can miss things like wrong assumptions regarding your design or code that might cause issues. Things that your peer might address.

If you as a developer put your work to review, it feels like that you have to go to a jury and people will judge your work. Although this could feel like this, it is also an opportunity for you to grow as a developer. Other people might have different insights and give you hints and tips to different solutions. It will also catch up issues and typo’s in upfront before delivering.

What does it take to have a productive and good code review? It first starts with good preparation; knowing what the code does and behave before actually starting to review it. Then we can wrap it up and give the reviewer some suggestions that he can look at, without being aggressive.

Let’s go through these steps and look them into detail with some suggestions how to tackle them.

Assume you have a layered system, build-up using the separation of concerns principle. We have a UI layer, a services layer and a database layer. The UI layer communicates with a service layer, which communicates with a database layer. As the names describe, the UI layer is responsible for showing an UI to the user, the services take care of main logic of the application and the data access layer communicates internally with a database.

Some argue that you shouldn’t have multiple return paths within our code. What are the benefits of having just one entry and one exit point?

Readability

You will keep the flow simple by having just one entry point and one exit point where the result is returned. In this case the code will be easy to read: you can simply read where the value is changed and where the end result is expected.

Controlling your object lifetime cycle

The main origin of the argue having only one return path, has its origin at languages like C or C++. In these languages you actually have to allocate memory when you want to use an instance of an object and deallocate it when you don’t need it anymore. If you forget the last one, you end up with memory leaks. Let’s say you create the instance and after that you return a value when some condition isn’t met. In this case, the line where your object is deallocated will not be called anymore.

A valid use: checking preconditions

A valid point where you could enter multiple return paths is at the beginning of a method, where you check the preconditions of your method. If a user of your method passes invalid arguments, you can quickly return a default value then have additional checks in your code.

One of the tasks when writing software, give an estimation of how much a certain feature is going to take to implement. For the Product Owner or project leader or some other internal customer, it will define which features he or she will get within an amount of time. So it will help the product owner with his or her decision-making, whether the feature must be in the upcoming sprint or not.

We can also determine the velocity with a software estimation, creating a commitment for the team to meet the sprint goals. By knowing how much a task is gonna take to implement, we can put that number of tasks within a sprint which can be handled by the team. Not meeting sprint goals will bring the team into a negative emotional state: “whatever we do, we don’t make it this sprint”. So, people won’t even try their best to meet the sprint goals.

Task estimation seems to be a difficult part of our job as software engineers. Most of the times, it takes more time to deliver features than initially estimated. Why is this and what can we do about it?

Read More…

When writing software in the object oriented way, we have components that are in a way related to each other. If the software base grows, these relationships can become more complex each time code is added. The SOLID design patterns, defined by Robert C. Martin a.k.a. Uncle Bob, define a way to build up our components in such a way they can easily be extended and maintained. SOLID stands for:

• Single responsibility principle
• Open/closed principle
• Liskov substitution principle
• Interface segregation principle
• Dependency inversion principle

Read More…

Projects often use third party libraries, which code interfaces to. As the same held for your project, the third part libraries also involve during time. Issues are fixed, new features are added, but also possible new issues will be introduced. Should you update, and keep track of the latest greatest library or use the argument “if it ain’t broken don’t fix it” and stay with the old? What are the pro’s and con’s of each scenario?

Read More…

Within C++, you have the const keyword, that can be used to say to the one which calls the method that the argument which passed through the const parameter won’t be changed within the method. This is merely adding a contract. Sure, the compiler does some checking for you, but still it is possible to change the value of your const parameter. See for example this nice example (obtained from https://isocpp.org/wiki/faq/const-correctness#aliasing-and-const):

Read More…