Archive | November 2016

To sort members or not to sort members?

In the last couple of years, I developed all of my codes in the way that all members and statics of every class were sorted by Eclipse. I recently joined a new project and it was surprising to me how much the other members of the team were against sorting the members. As always, I tried to understand their motivation and find the differences in our opinions.

Their main reason was the following:

I want to put the functions and variables that belong together next to each other, so I can see them together.

I saw their point. However, I did not agree with it and I could not convince them about my right. I told them:

If you used Git and code review before accepting pull requests, you would find it very annoying if non-fucntional code changes would divert your attention. By non-functional, I mean changing the order of functions or doing some code formatting.

That was not enough. How do you explain the benefit of code reviews and the drawbacks of non-functional changes in the code to someone, who has never used Git neither code reviews?

I still felt that there was something else, too. What did I miss in the argument? Why do I not care if the functions that are called from each other are not close to each other in the source code?

You can call me uppish, but in every development team in my life, I was much faster at code investigation than others. It had one reason. While the other programmers started to analyze the code as a book, I wanted to know only what I had to.

Imagine you are looking for the reason why a label has a specific value on the screen. While the others see the code snippet below:


I see only the following:


You see the difference? I care only about the code I need to know. After I find this code snippet, I will push CTRL+ALT+H to see where the current function is called from. I do not care if the caller function is before or behind this one. I will jump there and continue my investigation.

I look around myself, and see that most of the developers do not even know the most basic keyboard shortcuts of Eclipse:

  • CTRL+SHIFT+T: Open a type
  • F3: jump to definition
  • CTRL+T: Type hierarchy in a pop-up. This is very useful during an investigation if we want to know where a method of an interface is implemented.
  • CTRL+ALT+H: Call hierarchy. Where is this variable used or where is this method called from?
  • CTRL+L: Jump to line. Very useful if we have a stacktrace and we want to start investigating the issue by line number.

I might have missed a couple of useful shortcut keys. What I wanted to express is that the ones who do code investigations without these, cannot call them experts. Their effectivity is way beyond the ones who know the tricks.

As soon as you start reading the code effectively, you will not care about the grouping of variables and functions at all. However, it will be very annoying if you see that others spend much energy on grouping, instead of concentrating on the business logic they want to implement. If you start thinking of grouping, you waste time and effectivity. You will never be as effective as others.

So why do I care about sorting the members at all? Why should I sort the members if it does not matter during code investigation? Because I want to make only those changes visible in my commits that have actual functional meaning. Without automated-sorting and very strict automated code-formatting in my IDE, I should spend a high amount of energy on reviewing my own commits before pushing them for code review.