Links of the week

http://www.noop.nl/2012/06/managers-should-not-be-coaching-developers.html
Good hint about what managers should actually manage and what they shouldn't.

http://www.forbes.com/sites/frederickallen/2012/06/27/inside-the-new-deskless-office/
Old, but great idea for better office rooms.

http://www.javacodegeeks.com/2012/06/demeter-law.html
A simple, but powerful law. Hopefully well known and widely used :-)

http://css.dzone.com/articles/no-browser-left-behind-html5-0
Really good article about a cautious switch to HTML 5.

http://glazkov.com/2011/01/14/what-the-heck-is-shadow-dom/
An older article, but I needed it for a different topic, and this article is still excellent, so give it a try, please.

http://css.dzone.com/articles/top-10-css3-forms-tutorials
http://css.dzone.com/articles/mastering-css3-7-cool-text
Some CSS 3 tutorials and samples.

Real Story: One of my favorite pieces of code (including advanced tutorial)

<sarcasm>

This is a real piece of code I found some time ago and I a still think, it has some great internal greatness, so I decided to publish some kind of a special tutorial about it:

 1 public boolean falseBoolean( boolean trueValue ) { 2   boolean returnValue = false; 3   if ( trueValue == true ) { 4     returnValue = false; 5   } 6   else { 7     returnValue = true; 8   } 9   return returnValue;10 }

One can easily see the advanced mind of the programmer who wrote that exceptional piece of code.
So why we don't take the code and analyze the important Java idioms and rules one can find there, and maybe we can also improve it a little bit.

First it is a good idea to change names accordingly: the name of the method variable 'trueValue' is probably not so good, because one might think that this variable always contains a true value, or if there are some 'wrong variable' somewhere, so I will change this to 'value' which is quite neutral.

Also 'returnValue' is a little bit long and it might confuse to have all variable names containing 'value', so I change this to the shorter name 'result'.

Then there is the idea that variables should be final, what actually means that they are not real variable, but fixed, but let us ignore this tiny point now.

If we change the local variable to final, we are not allowed to assign anything to it in line 2, because otherwise we would not be able to assign a new value to it in lines 4 and 6.

So here is the slightly improved code:

 1 public boolean falseBoolean( final boolean value ) { 2   final boolean result; 3   if ( value == true ) { 4     result = false; 5   } 6   else { 7     result = true; 8   } 9   return result;10 }

You see the code confirms to an old rule: "Not more than 1 return statement in a method". Well, to be quite direct, let me say that I don't like that rule. It does not make sense for me, because there  might be of course some situations where it is OK, to return from a method in the middle of the method. I really think that it depends on the context or on the coding conventions you have to use at your office.

Let's assume that I can do what I want..., so I will use two return statements here, so that the method is quite shorter. In order to do so, we will remove the local variable.

1 public boolean falseBoolean( final boolean value ) {2   if ( value == true ) {3     return false;4   }5   else {6     return true;7   }8 }

Another small issue is that I do not like comparisons of the kind 'a == true', where a is a boolean variable. So I change this, too.

1 public boolean falseBoolean( final boolean value ) {2   if ( value ) {3     return false;4   }5   else {6     return true;7   }8 }

As I like to use what Java offers, I also like the ternary (conditional) operator. Some people do not like it, because the code might be more difficult to read then, but I think one can use it for short statements, as follows:

1 public boolean falseBoolean( final boolean value ) {2   return value ? false : true;3 }

I hope, everybody got that last change...

Now we should check how this method is actually called, maybe somehow like as follows (ignoring that it is a static method and should perhaps have the class name before the method name):

1 boolean dump = ...;2 
3 boolean garb = falseBoolean( dump );

Here dump gets a boolean value somehow and later the new value is assigned to garb by calling our optimized method.

As the method is quite short, one might consider inlining the contents of the method. Then one would have:

1 boolean dump = ...;2 
3 boolean garb = dump ? false : true;

Yes, this is it...

This is my final version for all the programmers who have never heard of the ! operator.
I thank you for your attention.

In my next post I will show you how to convert a long value to an int value. Stay tuned.

</sarcasm>

I don't like NullPointerExceptions

Actually I don't like the message of NullPointer Exceptions, i. e. "null". Such a message is usually not very helpful.

I created a few rules for myself how to avoid certain exceptions and actually define pre- and post-conditions for methods. Let me please give you a few examples.

In the beginning of a non-private method I usually check all method arguments.

public void foo( String x, int a, Person p ) {
if ( x == null ) throw new IllegalArgumentException( "Argument 'x' must not be null." );
if ( a < 0 ) throw new IllegalArgumentException( "Argument 'a' must not be less than 0." );
if ( p == null ) throw new IllegalArgumentException( "Argument 'p' must not be null." );

A few hints:

There are of course libraries which do such checks, i. e. they can check if a String is not null and not empty, and if it contains only  white spaces and so on.
I would recommend to choose one of those libraries and use them intensively.
Otherwise some checks like in the example might be helpful.

There are also libraries which offer annotations for methods or method arguments to check if the method arguments are valid. Those libraries are great in my opinion, but often companies do not allow the use of some libraries for whatever reasons.

You can create your own Exception type or use an existing one. I have seen very often that developers use IllegalArgumentException, IllegalStateException, or NullPointerException. In the later case with a good error message...

These checks should not only be done in methods, but also in constructors, and whereever it makes sense for you.


For private methods I use assert statements. Remember assertion checking can be enabled and disabled by the command line options -ea and -da.

private void gee( Person p ) {
  assert p != null;
 
I usually do not add messages (too much work) to assertions. As we usually compile everything with the debug flag it is easy to find the line where the assertion error happened.

In the if statements from above or in such assert statements I always check only one thing.
That means that the following code is not OK for me:

assert p != null && p.getName() != null && !list.contains( p );

I prefer:

assert p != null;
assert p.getName();
assert !list.contains( p );


Before I return a value in a method, I check the value (post-condition) like in:

public String concat( String a, String b ) {
  ...
final String result = a + b;

assert result != null;
return result;


You can also add assert statements to various places within a method like:

public void addPerson( Person p ) {
  ...
  final int previousSize = list.size();
  list.add( p );
  assert list.size() == previousSize + 1;
  assert list.contains( p );

Remember that this code is not included in the class files, if you use the -da option, so there is no performance problem in production software, but those assertions can be great during development to find problems.
And they are a very good way to document assumptions. That is actually the most important point for me: I like executable documentation...


In addition I always check a reference before I call a method of if:

y = x.getName().toUpperCase();

will become:

if ( x != null and x.getName() != null ) {
  y = ...
 
Or one can also use assertions here, that depends on the context.

For me it is not so important which technology is used for all those checks, but that those checks are done at all.
I think it is a very important and actually very simple step toward increasing quality of software.

Subversion - We don't need no stinking trunk!


Most software developers seem to use a directory called 'trunk' in Subversion. I always wondered what trunk is good for.
In real life software development in a team of, let's say, about 20-30 developers some coordination is needed when making a release version.
Often this happens as follows (and I am quite simplifying):

1. All developers commit their stuff to the trunk.
2. The trunk is copied to a release branch, e. g. RB-2.
3. The new release (with 3) starts on the trunk.
4. Every developer has to check out the version he needs for further programming, either the trunk for the new release, or the release branch.

Now when a typical developer who is not interested too much in organisational things wants to add an incredibly important, last second change to the release version, he often asks the following question - and I have heard it so often that I decided to write this post:

"Where can I commit my stuff for the current release? On the trunk or...?"

Usually another developer answers slightly irritated: "On the relase branch, of course, we created it yesterday."

- "Ah, sorry, I missed that somehow."

There is a very small idea to improve such a situation (without kicking someone somewhere):

Don't use the word 'trunk' for the trunk, but give it the name of the release branch.

So we might have a few SVN directories like RB-1, RB-2, RB-3.

And everybody knows what stuff goes to which branch.

I admit, for a good developer this idea might sound strange or ridiculuous, but in real life, you know, not everybody is perfect or takes care of all those coordination issues.

Another good idea would be to jump to a more modern system like GIT:-)

But that's a different story.