Using this Keyword to Call Private Methods

After a recent code review I noticed a lot of code similar to the following:

this.createAUser();

or

if (this.isValidProfile()) {

Our coding standards allow for using this with fields to make the distinction clear:

private int count;
pubic void setCount(int count) {
  this.count = count
}

We adopted The Elements of Java Style for our coding style guide about 2.5 years ago, but this is a case I’d never spent much time thinking about. I find it a lot clearer to write something like:

createAUser() 

or

if (isValidProfile()) {

I always assumed this was a well understood convention, but after spending some Googling around I found nothing specifically on idioms with using this with methods.

I think the best evidence in favor of not using the this keyword is with Martin Fowler’s Extract Method pattern. You often create small methods by doing a simple extract of a code fragment on a method that’s getting a little long. And Martin’s example suggests calling the extracted methods with:

printBanner();
printDetails(getOutstanding())

not:

this.printBanner();
this.printDetails(this.getOutstanding())

For me it all comes down to better readability, but we’ll probably have a short meeting with some of the senior developers to toss it around and come to a final decision. If we hadn’t been doing code reviews on a regular basis we might have never addressed this issue.

Setting Up Acceptance Tests

I’ve been intrigued with Fit/Fitnesse since Bob Martin introduced me to it at a session at SD West 2005. Of course that was about 18 months ago and despite playing with it a fair bit myself and even giving a talk on it at our local JUG, we still haven’t implemented it on any projects. Given that I’m unfortunately the resident expert on it, I think it’s finally time to push it directly even if that means doing some coding to show people how it could work on a real project. Now I just need to find time to keep up with the management duties as well.

Haskell On My Radar

I’ve latched on to the Pragmatic’s suggestion to pick up a new language each year. This year it was Ruby of course. A couple things from Smalltalk to Lisp to Haskell have been buzzing around in my head, but I think I’ve settled on Haskell as the candidate. The main reason is being a functional language it has the ability to stretch my skills the most.

Covering for a Scrum Master on Vacation

Generally if a Scrum Master is off on vacation the role should temporarily fall to someone on the team to cover the standups, attempt to remove impediments, and generally keep things moving.

What doesn’t work that well is having another Scrum Master who has no relation to the project step in help. They don’t have any context to work from and at most they’re going to mechanically record status updates on tasks. Maybe they can try to remove some impediments, but again they lack context.

Given a choice leave it up to the team who fills in the Scrum Master role while they’re on vacation.

Manager Code Reviews

We’ve been holding code reviews for close to a year now and the process has evolved from the first days. We’ve seen many of the common benefits:

  • Better code quality and readability.
  • Catching some defects early.
  • Mentoring opportunities around design.

We’re still a bit informal about it and probably reviewing less code than we should, but overall I’m pretty happy with the results.

That said I’m starting to weed myself out of more code reviews because I simply can’t keep up and I don’t need to be a bottleneck in the process. I really enjoy the break of a good 30-60 minutes of just reading and examining code and maybe running the corresponding tests, but I don’t have much time for it. Luckily we have enough senior developers now who have gotten used to the process and are able handle code reviews on their own projects.

As a manager code reviews can be important, but so are standup meetings, one-on-ones, staff meetings, removing impediments, planning out future project opportunities, and recruiting.