Verbose is a dirty word

I’m not saying verbose should be a dirty word, just that it does have a pejorative meaning. If you’ve used *nix command line tools often enough, you’ll know that -v is often used as a flag for “verbose”. This usually ends up in some useful information coming out of the log or stdout. -vvv usually means “very verbose” and too much information pours out to be of any use. And this is the risk:

If verbose is your end-goal, then the more verbose you are, the better.

Right? I mean that makes sense. If “quality” is your end-goal, then more and more quality is a thing to strive for. Same goes for “agile”, “fair”, “loyal”, “just”. All these words suggest that the more you pile it on, the better. This is not true of verbose. Keep getting verbose, and in fact, you just get more noise.

I’m probably nitpicking this to death, but I’m only doing so, now, because I think I have a better quality to strive for:

Expressiveness

Really in our code, we wan’t to be more expressive. We want every line we read to convey it’s meaning.

If you check out expressive at dictionary.com there’s also a nice set of synonyms:

Synonyms: These adjectives mean effectively conveying a feeling, idea, or mood: an expressive gesture; an eloquent speech; a meaningful look; a significant smile.

I think eloquent is a good word too, it usually conveys meaning in a terse manner. That’s right, less verbose, just enough meaning and no more.

Readable Code

This code is readable, but not expressive:

public class EmployeeModel {
    ....
    public function save():void {
        if ((editingEmployee.name.length > 0) && (employees.checkUnique(editingEmployee.ssid))) {
            employees.comit(editingEmployee);
        }
    }
    ...
}

Expressive Code

So now I refactor it.

public class EmployeeModel {
    ....
    protected function employeeIsValid(employee:EmployeeVO):Boolean {
        return ((employee.name.length > 0) && employees.checkUnique(employee.ssid))
    }

    public function save():void {
        if (!employeeIsValid(editingEmployee)
            return;

        employees.comit(editingEmployee);
    }
    ...
}

I use a guard clause for starters because they convey intent more clearly.

Then I extract the method (all praise ctrl-alt-m in IntelliJ IDEA) employeeIsValid(). This gives the guard more meaning, and also gives the extracted condition more meaning. It’s a win-win.

Verbose Code

Now, is this the following code more expressive or more verbose?

public class EmployeeModel {
    ....
    protected function employeeNameIsValid(employee:EmployeeVO):Boolean {
        return employee.name.length > 0;
    }

    protected function employeeIsValid(employee:EmployeeVO):Boolean {
        return (employeeNameIsValid(employee) && employees.checkUnique(employee.ssid))
    }

    public function save():void {
        if (!employeeIsValid(editingEmployee)
            return;

        employees.comit(editingEmployee);
    }
    ...
}

I extract the name comparison (pretend for a moment that it couldn’t be done in the VO) - employeeNameIsValid().

This is not too bad, I think. It expresses that an employeeName that’s greater than 0 chars long is valid.

However this is easily inferred from the previous example, because the test is inside ‘employeeIsValid’ - It would read just as well, and so I wouldn’t bother with this extra step. At least, not until it got more complex. Remember, most refactorings are bidirectional.