In and Out of the Pocket

Ashley FriezeAugust 26th, 2019Last Updated: August 21st, 2019

1 11 3 minutes read

I’d like to discussed one of my many bêtes noires. I love a good explanatory variable as much as the next guy, and they’re taught in books like Clean Code as a way to document your code better than comments… which is fine. Overall, I like it even more when the explanatory variable is replaced with an explanatory function to calculate the answer that you’d store in that variable, but that’s a second point.

But as much as a good explanatory variable is helpful in fostering understanding, and as much as it can be useful to accumulate several different results into variables at the top of a function to compose the answer at the end, here’s a shocking truth. Far too many variables are just redundant and add nothing.

Consider this code:

Report report = ReportBuilder.builder(TEXT)
    .format(CSV)
    .newlineFormat(CRLF)
    .build();
 
return report.generate(inputData);

What is report? it’s the report object. We build it and put it in our back pocket. Then, immediately, we pull it out of our back pocket and use it to generate the answer for the function.

That could just as easily be written:

return ReportBuilder.builder(TEXT)
    .format(CSV)
    .newlineFormat(CRLF)
    .build()
    .generate(inputData);

But where does it say that there’s a report? It says it in the ReportBuilder and in the build and in the generate. This fluent style of programming is intended to reduce the amount of staccato expression of what we’re doing with our objects.

Would you write the following?

boolean result = false;
if (input.contains("foo") && input.length < 10) {
    result = true;
}
return result;

If so, stop reading this blog and go and get a job in something you’re good at.

// without the silliness
return input.contains("foo") && input.length < 10;

The above is an extreme case of the put it in the pocket and then get it out again.

Clearly, there are some situations where you want to keep a few answers from calls around, or where it would a horrific mess to try to accumulate them all into a single call.

I’ve been guilty of tolerating too much of this:

ResponseObject object = httpClient.post(buildUrl(baseUrl, resourceEndPoint, PAGE, pageNumber, SORT, sortOrder),
    convertToJson(inputObject),
    getCredentialsHeaders(userName, password),
    shouldKeepAlive(keepAlive, numberOfActiveThreads),
    ResponseObject.class);

The above is on the borderline of helpful, isn’t it… there’s a lot to read, and maybe it hits overload. Perhaps, working backwards from the call, we’d prefer to say:

ResponseObject object = httpClient.post(url,
    body,
    credentials,
    keepAlive,
    ResponseObject.class);

Perhaps that would help explain what’s going on in this complex call (though interestingly, the more fluent the code, the more you can tolerate just evaluating things as you go). Clearly the above call needs some variables to be assigned for it to be possible. That’s cool. They’re part explanatory, they’re part separation of concerns.

Are you saying you need to evaluate things multiple times?

You could read the above, where I’m arguing for the 90% banishment of temporary variables in functions, replaced with inline function calls, and assume I would make multiple calls to the calculation if we need the data more than once in a function. To this I’d say two things.

No! – explanatory variables are single use, any other sort of variable has another purpose – either an accumulator, which gathers data through the function, or an effective constant which holds an answer for reuse (though I’m not a fan of overuse of final in Java…)
See if you can construct your functions so they are so small that they don’t really need to reuse data very often

To Summarise

Try to get rid of single-use variables with vapid names, especially when they’re defined immediately before a return or the last line of the function.

It’s only an explanatory variable if it gives context to the data, so if it’s just named after the type, it’s probably just reading effort, not assistance.

Published on Java Code Geeks with permission by Ashley Frieze, partner at our JCG program. See the original article here: In and Out of the Pocket

Opinions expressed by Java Code Geeks contributors are their own.