Code Will Tear Us Apart

There's nothing worst than read the code of someone you consider a good programmer and find tons of anti-patterns. Of course often there are good reasons behind some choices. Such as deadlines.

Jokes aside, I am conscious that my old code sucks too. This is because I continuously try to improve my knowledge and learn from my colleagues and from my mistakes. And also from my colleagues' mistakes.

Are We Writers?

Sometimes I read about parallels between novel writers and programmers (yes, I'm guilty too). It may work, but only on a superficial level. Because the code we write is not judged for the style. This is also why there are more "good" programmers than good writers.

From the customers' point of view, the only thing that matters is that the software does what he wants. But we know that this is quite impossible: bugs happen. In addition, new features are required.

From a developer's point of view, it's important that the code is understandable and easily extensible. The problem is that sometimes it's more convenient to rewrite a part of code instead of understanding and fixing it.

Just as an example, once in a file, I found a function called manage_parameters(). It was quite long, so I didn't analyzed in deep its code but it seemed correct. The next function in the file was manage_parameters_without_making_mess(). The developer that wrote the latter told me that he didn't have time to understand why the first function sometimes failed.

The Truth (?)

The truth is that we forgive (and often forget) our own mistakes, hiding behind poor excuses. But, at the same time, we are ready to point our fingers against other developers, especially if they are considered good programmers.

Bottom Line

If you think I've read your code and this post is about you, maybe you should spend some time to review what you have developed in the past.

Image by Miguel Angel licensed under a Creative Commons Attribution-NonCommercial-NoDerivs 2.0 Generic License.

development, personal, working life Wednesday, May 27, 2015 No comments

4 Easy Tips To Work Better With Git

Maybe they are quite trivial and only come from common sense, but sometimes it's useful to repeat. By the way, these are general purpose suggestions that can be used also with other versioning systems.

1. Use Tags To Label Versions

Every single release of your software that leaves your PC must have a commit tagged with the version number, this way:

git tag ver_1.02

Remember to push the tags to the remote repository with:

git push --tags

This will help you to understand which release you have to use to reproduce issues that testers or users find. It's also useful when you need to create a changelog from a previous release. But this is related also with the next point.

2. Write Meaningful Commit Messages

Explaining why you made a commit and which parts are involved can help other developers (and especially you, in the future) to quickly understand the change made without having to deal with differences in the code.

If you are using a bug tracking system, always mention the id of the issue that usually include detailed information on how to reproduce a particular bug. And this may help when that code will be changed in the future.

Besides, good written commit messages can help you to create a complete changelog, even with automatic tools.

For a quick reference about the style to adopt for commit messages, you can look here, while a more complete explanation can be found here.

3. Signal Particular Commits

When you work in a team, it's possible that someone does not respect the conventions about tabs/spaces, position of curly braces, etc. If you are a coding style nazi, you'll fix all of these as soon as you notice them.

The important thing is to not mix these kind of changes with modifications on the behavior of the code. Another good practice is to make clear in the commit message that you are just doing cosmetic changes.

A good way is to start the message with the word "[WHITESPACES]" or "[COSMETIC]". On some projects  I also use prefixes for changes on test cases and documentation.

4. Each Commit Should Leave The Repository In A Good Status

This means that your project must always build without errors, no matter which issue you fix. The repository is not your daily backup.

If for some reason this is not possible, for example because your modification needs someone else's work to be completed, it must be signaled in the commit message (see also previous point).

Conclusions

Following these suggestions is not a waste of time. Believe me, when you are in trouble you'll be grate to easily access all the information you need. The following infographic can help you to remember these tips (click for a larger version).

Git, tips Friday, May 22, 2015 No comments

Studio Vs Live In Software Development

I like rock music. And I love live performances. Well, you know, studio albums provide a great sound quality and the cure of small acoustic details. But songs registered during a tour are on another planet.

Because a song evolves during time. It is never played in the same way twice. In some cases, it is completely different, with another rhythm, other arrangements or with a new guitar solo. There may be some small imperfections but they are quickly forgiven by the energy provided by the musicians. And eventually there is the interaction with the public that sings and claps.

The first release of a software is just like a studio version of a song. It's perfect, right? It has a wonderful structure, meaningful variable names and good comments before each function. Then the testers find some bugs and slightly your code starts to change. Then the project manager asks you to modify the behavior of a particular dialog. Then the customers want to add new functions. Eventually the code becomes a mess and you do the refactoring.

If you try to execute git blame on your code at this point, you'll find that more than 50% of the functions have been changed since the initial release. But this is not a problem. It's tested, reviewed and appreciated by users. Now your software is absolutely better. Just like a good song played live.

development, music Sunday, May 17, 2015 No comments

Which Programming Language You Should Not Learn

Lately, I've seen many times young developers asking which programming languages are worth learning. Obviously I've seen a lot of superficial answers, mainly because people tend to suggest things they like. Programming has many levels of complexity, so, before providing an answer, it's better to understand why you want to learn a new language.

What Is Your Goal?

If you want to find the best paid job, you should focus on languages that are old but with a large base of existing legacy code (such as ADA or COBOL or Fortran) or vice versa, on brand new ones (Go, Rust). Both choices have a couple of drawbacks. There are few workplaces in the world (this is why they are well paid) and you cannot know if your job will still be required in five years.

But maybe you just want to get a job quickly an not too far from home. In this case JavaScript is your choice. You can use it client-side, server-side, and even in mobile app development. Pretty cool, isn't it? Unfortunately for you, the world is full of good JS developers, so you'd better become a damn good one if you want to stay over the average and be noticed by some company.

Do you want to explore the Object Oriented paradigm? You have multiple choices: C++ (you'll need just some years to master it), Java (if security issues won't kill its virtual machine before) or Python (when you'll understand its concept of reference).

If you want to understand better how things works at a lower level, C is still a choice, especially in embedded systems but you have to be ready to deal with raw data management, dirty pointers, and memory leaks.

If you are an Apple fan, try with Objective C and Swift. If you love MicroSoft, C# and Visual Basic are for you. But be conscious that you are tighten to a single company that tomorrow can decide to completely change the language and make you throw away your old code (who said VB 6?).

Conclusions

I can go on with many others (Lua, Scala, PHP, Ruby, Perl...) but I think you have understood: the perfect language does not exist. In any case, having a good experience of a couple of widely used programming languages and knowing the basis of some of the newcomers is probably the best choice you can make.

development, personal Tuesday, May 12, 2015 No comments

Eclipse: Good Editor, Bad Build System

For a large C/C++ project I'm involved in, Eclipse has been chosen as default IDE.

I have to say that I really like the editor. It has some functions that make me save time, such as the automatic highlight of the variables, the search for references inside a single project or the whole workspace, the possibility to work with gdb remotely (you know, I work on embedded systems), etc. I also think that some other things can be improved, for example the search, but all in all it's a good tool, in my opinion.

There's only one thing I have to complain: the build system. Because:

• it is really slow,
• the management of dependencies doesn't work as expected, and
• errors and warnings are presented in a misleading way.

For this last point, I suppose this is because when running the compiler and the linker, stdout and stderr are parsed separately and then printed in the same window. The result is that error messages may appear after an unrelated build command.

The dependencies are another thing that in my opinion needs to be improved. For example, it would be great if the build stops as soon as one of the related builds fails. I'm really surprised this doesn't happen.

Speaking about the build speed and why it's so important, I totally agree with this post. Please consider spending five minutes of your time and read it.

The solution to these issues is to use custom makefiles. You may spend some time to set them up but, believe me, you'll save precious time when compiling and you won't be losing the concentration.

development, Eclipse, IDEs, personal Thursday, May 07, 2015 No comments

Narcissus Vs Getting The Things Done

"Narcissus by Caravaggio"

Do you know who Narcissus is? He is a character of ancient Greek mythology, so attracted from his own beauty to forget to eat only to look to his reflection in a river. And what about you, my dear developer? Are you like Narcissus? Do you spend hours in creating wonderful structures and classes, fancy functions and stunning algorithms? Don't you feel just like Narcissus?

Assuming you are a developer, for what purpose do you write code?

If you answered anything else from "solving problems", I'm afraid you are similar to Narcissus. This is what we are paid for: to solve someone else's problems. Possibly in the best way. But the amount of work should not be excessive.

I've been there before, I know what I'm saying. Once, when I was a (bad) C++ programmer, I've designed a wonderful class hierarchy to solve a trivial problem. The worst thing is that the function that uses those classes is probably used by 1% of the customers.

The general rule is: the effort must be proportional to the importance.

The most important thing is to complete a project. And right after it comes code readability. Beauty is on the bottom. Not because beauty is not important, but because it is not the purpose of your job. And you must be open to dirty your code when needed. But this is material for another post.

development, working life Saturday, May 02, 2015 No comments