Occasional Thoughts

And I really mean it. The number one source of frustration with software applications is a bad error message at the wrong time. In fact it's always the wrong time for error messages. Given this the error message should not just say 'hey! somethings wrong'. It should also say "do this or this to be able to continue". Even better - it should allow you to solve the problem immediately.

When a error message popped up you already lost time. And when the message is of no help to accomplish the task you were just intended to do it is very frustrating - it sucks!

Recently I had to battle with such an error message using Firefox. Previously I associated MS Office files with OpenOffice. When downloading a file for the first time, Firefox asks you what to do and you are able to select a program. In addition there is a checkbox that prevents this question in the future and always performs the preferred action.

Suddenly this stopped working and I got this error message:

"<<filename>> could not be opened, because the associated helper application does not exist. Change the association in your preferences."

I just had to open a document quickly and wasn't able to do it. After clicking on OK nothing happened anymore. The only hint it gave me was to check my preferences, but in the preferences UI I did not found any helper application registered.

At that time I had no time to google for it, so I just downloaded the file using the context menu action from the link that pointed to the document and opened it manually. But in the long term this got frustrating. More and more time was wasted. Finally I took the time to search the web for it and until I found the solution on MozillaZine lost more and more time.

So what's the problem here?

I do not want to comment on the others but on his suggestion to add different prefixes to variables:

• f for fields
• a for arguments
• no prefix for local variables

His example that should prove in his opinion that this is better readable is:

public boolean equals (Object aOther)
{
  if (! (aOther instanceof Range)) return false;
  Range other = (Range) aOther;
  return fStart.equals(other.fStart) && fEnd.equals(other.fEnd);
}

Well I couldn't disagree more with him: