Comments on ThoughtWorks Anthology

I’ve just finished reading the “ThoughtWorks Anthology” book, motivated by Guilherme Silveira and learned some really useful things on it, that I would like to expand a little.

Besides the less technical articles published on it, I really enjoyed the chapter written by Jeff Bay called “Object Calisthenics”, where the writer propose 9 exercises in order to improve the reader way of writing code, making it’s code cleaner and easiear to understand therefore easier to test.

I’ll just sum up the 3 ones that I found more interesting and add a few things:

Do not have more than one identation level inside a method

Take the following method, which simply increase the price of some products if it’s value are above 50:

public void redefinePrices(List products, Integer toIncrease) {
	for(Product p : products) {
		Integer actualValue = p.getActualValue();
		if(actualValue > 50) {
			p.setActualValue(actualValue + toIncrease);

As you can see, inside this method there are two identation levels, which makes the code easier to read if we had only one, like the following:

public void redefinePrices(List products, Integer toIncrease) {
	for(Product p : products) {
		increaseValue(p, toIncrease);

private void increaseValue(Product product, Integer toIncrease) {
	Integer actualValue = product.getActualValue();
	if(actualValue > 50) {
		product.setActualValue(actualValue + toIncrease);

Ok, now there’s two methods, but, there’s no doubt that the redefinePrices method is clearer than in the first version. The advantage of this approach is that your code becomes self-descriptive, with the method call inside it. When you need to read the method redefinePrices, instead of interpret conditional logics or loops, just read what is being done inside the nested method described by the increaseValue method name.

Avoid abbreviation on names

One of the largest mistakes I see on projects nowadays are the use of abbreviation on classes, methods and variables name. The use of abbreviation often leads to a code full of hard to understand names, which affects mostly those who are new to the project, increasing their learning curve on the domain model and consequently from the software itself.

I use to say that abbreviation is a plague that exists on software development, and it’s hard to get rid of it. It’s tempting to, for instance, instead of writing generateCardCode to write generateCC. This may also indicate that you have some problems regarding ubiquitous language on your project.

Jeff Bay also says that you may try to make your names to take no longer than 2 words. I’m not so severe on that, but I believe that 3 words are enough to make a good name (of course, this do not include test names).

Do not use else clauses

When using if/else clauses, it’s common to make the code inside these clauses hard to understand. This is even more evident when you have a complex block of if/else clauses, making the logic cumbersome and complex. There are some approaches used to deal with this problem. The first, and simpler one is to just return the value you want. Say, that you have the following code:

public boolean shouldAcceptRequest(Destination destination) {
	if(destination.address().equals("foo")) {
		return true;
	} else {
		return false;

You can simplify it to just one line, and also improve the readability of this piece of code:

public boolean shouldAcceptRequest(Destination destination) {
	return destination.address().equals("foo");

However, there are some cases when only returning the value is not enough, you may want to perform a small check before deciding what to return, like in the following example:

public Integer divideValues(Integer a, Integer b) {
	if (b == 0)
		return 0;
		return a / b;

You can introduce ternary operator to make the code above cleaner:

public Integer divideValues(Integer a, Integer b) {
	return b == 0 ? 0 : a / b;

There’s also the classical case when what you’re wanting to test against an if/else clause can be abstracted on objects, and you can introduce the Strategy pattern, so you can remove the if clauses, and the executed behavior will be decided from the implementation it’ll be passed to be executed, like the example below:

public void applyDiscount(Customer customer, Product product) {

In the previous example, it doesn’t matter if it is a RegularCustomer or a SporadicCustomer, they have different discount rates, but since I’m using polymorphism (note the Customer interface), I can treat them the same way, but the discountRate method return different values for each kind of customer.


While reading the book, there are others techniques proposed by Jeff Bay, that I didn’t went into here. Some might say that a few of these issues are very radical, in fact, as proposed as an exercise from the writer, you won’t need to do this everyday, but just try to save some 1000 lines of code, or a time-box (say, a week) to follow these advices, and you’ll see how this changes the way you’ll write your everyday code.

Etiquetado , ,

First impressions from a coding dojo

I know I’m quite outdated at this post from my first coding dojo (which was last friday), but never is too late.
I had never been at a coding dojo before, so at the start I felt myself kind of noob, on its formula.

What is a coding dojo?
Imagine a coding dojo as a meeting of programmers, where you put to work some of XP practices, like TDD and pair programming to solve any given problem. The main goals of a coding dojo is that you firstly have fun programming and seeing other people programming (the computer output is project to everybody at the dojo session). And also, acquire new skills, such as learning new techniques, languages, tools, frameworks and so on.

Coding Dojo formula
In a coding dojo, people are arranged in a way that 2 persons stays at the computer pairing for a certain amount of time (in our case, 7 minutes). Past this time, there’s a pair switch, where other pair take control from the computer, and also from the code, cotinuing from where the pair before were.
While the pair is working on how to solve the problem, the audience cannot take part on it suggesting ways of solving the problem or also suggesting refactorings to the code, while the tests developed under TDD are not passing (red).
And also the problem to be solved and the programming language to be used are chosen just before the dojo session starts.

The whole scenario
My first coding dojo was also the first coding dojo held at Caelum (where I do work), and like me, there were also some other people who was at a coding dojo for the first time. So for not pushing it too fast, we had chosen a common language (Java) and a really cool problem (How to divide a number represented as String without using the / operator?)

What I’ve learned
It’s interesting when you are in front of a crowd coding, and there’s everybody looking at what you’re doing. I’ve never had experienced that before, and it kind of intimidate myself a little bit at the beggining, but past some time I’ve got used to it, and it flowed pretty good.
Also, I’ve learned how boring it is to pair to someone who is tired, or whose mind is at the moon or mars. It just don’t work.
From the language there was nothing much to learn, because we used pure Java, which I work with everyday. So, nothing new on it.

What I’ve liked
It’s amazing when the crowd is all there looking at the problem and figuring out a way to solve it. Everybody, with the same goal and motivated. The feeling of being there was very intense and how the problem challenged us was also very interesting, and I really appreciated it.
By the way, when a test goes from red to green the feeling is very good.

What I disliked
I’m not sure if dislike is the best word to describe it, but I couldn’t figure out a better one, but I think that 7 minutes wasn’t time enough for a pair to fully participate on the problem. Maybe 10 minutes would be a best try (the ones who were there and also had experiences in a coding dojo said that 7 minutes are ok). Or maybe, It’s just a noob impression :).
By the way, sometimes people talked aloud when the tests where red, this can take away your mind and concentration on the problem. So silence while the tests are red is essential.
We also hadn’t prepared a source control environment (lack of time), so we couldn’t integrate our changes at each pair switch.

Future Coding Dojos
We scheduled to run a coding dojo every friday. With a github repo available, so we can integrate our code at each pair switch.
And now with different languages, so we can learn much more on it. After all, that’s what a coding dojo is about. Learning.

Etiquetado ,

Mirror DSL 1.2 – reflection made easier


Last sunday was released the Mirror DSL 1.2.

Mirror is a simple DSL layer over the Java Reflection API, with the intent of helping writing reflection code in a cleaner and non-intrusive manner.

Nowadays, if you have to write code that takes advantage of the Java Reflection API for setting a property value, for instance, you should write a cumbersome code like that:

Field toSet = null;
for (Field f : target.getClass().getDeclaredFields()) {
    if (f.getName().equals("field")) {
        toSet = f;
if (toSet != null && ((toSet.getModifiers() & Modifier.STATIC) == 0)
        && ((toSet.getModifiers() & Modifier.FINAL) == 0)) {
    toSet.set(target, value);

While, with mirror you could do everything that this awful code does, in a single line, and also in a very expressive way. You could just say to mirror: “Hey, Mirror, please on the object referred by “target” set the field called “fieldName” with the value of this variable here”.

But, how to do that with Java code? Simple:


You can find more information about Mirror at:

We hope that everybody find it useful, and it would be of an enourmous pleasure to get your feedback about it.

Etiquetado ,

Get Involved And Participate

Recently, I’ve attended to Rails Summit Latin America, and among some brilliant talks, there was one which impressed me the most. It was from Dr. Nic Williams, a well-known Ruby on Rails programmer, talking about how can everyone participate at the open source community.

During his talk, he explained about some tips for those who wants to get involved and participate in the open source community, like doing unit tests, knowing a versioning system such as git and svn, and taking part at some open source project, independently at the role that you play on that project.
But the tip that made me considering write this blog post was: “write a blog”. :) It doesn’t matter that you sometimes make mistakes on what you’re posting, the most important thing is, someone will always know a subject more than you do, and will post a comment correcting you if you’re wrong, and that way, the blogger will be able to learn from it’s own mistakes. And if you’re not wrong, awesome, other people will be able to learn from your blog. So that writing a blog becomes a learning cycle. Always.

In this space, I’ll discuss agile, TDD, algorithms, programming languages, tools and some other random stuffs that comes to my mind. Feel free to join the blog, post comments and interact.

So lets go get involved and participate. :)


Obtenha todo post novo entregue na sua caixa de entrada.