From a job offer recently received:
[...]Please note it is essential that applicants have worked in a structured development environment ideally utilising the Agile (SCRUM, XP) methodology or any other similar methods such as Waterfall, RAD or RUP[...]
Simply awesome.
Comments rss
TrackbackLast week I was working with a colleague on the implementation of a fairly simple validation of a character: the criteria for validation was that the character had to be lower case or a digit.
Looking at the Javadoc we spotted a couple of useful methods in the Character class: isLetterOrDigit -the method is pretty straightforward- and is LowerCase, that return false for upper case letter and whatever is not a letter.
The code we wrote looked like:
if (!isLowerCase(aCharacter) && !isDigit(aCharacter)) {
//...
//error !!
}
All the tests passed.
Fairly simple and coincise solution.
But…are we actually expressing the business requirements ?
No.
Not al all.
Our code is not communicating clearly what we’re trying to achieve: the API is not clearly expressing that punctuations are not allowed.
The expected behaviour is there, but the code is still not in an ideal shape: we need to be able to clearly express what we really need to validate.
The refactored code looked like:
if (!isALowerCaseCharacter(aCharacter) && !isDigit(aCharacter)) {
where isALowerCaseCharacter was:
private boolean isALowerCaseCharacter(char aCharacter) {
return isLetter(aCharacter) && isLowerCase(aCharacter);
}
This is better.
We’re increasing the actual complexity of the condition but our code now is expressive: if in 3 months time we pick up this code again we clearly know what business rule we’re applying without looking at any additional resource.
The code now is communicating our intention.
Comments rss Trackback
