Sometimes, I have a hard time deciding between two good code traits: debuggability and readability. The snippets below are an oversimplification, but they illustrate my pain.
Example 1:
if(isSomethingThere(somethingParam)
|| isTheOtherThingThere(otherParam)
|| isWhatever(whatever))
{
// some logic
}
Example 2:
bool isSomethingThere = isSomethingThere(somethingParam);
bool isTheOtherThingThere = isTheOtherThingThere(otherParam);
bool isWhatever = isWhatever(whatever);
if(isSomethingThere || isTheOtherThingThere || isWhatever)
{
// some logic
}
To me, Example 1
is an easy-to-read code, but a pain in the rear to debug. This code is a nightmare to debug because the debugger won't tell me what the return value of each method is. Moreover, the execution won't reach, for example, the isWhatever()
method if any of the previous functions returns false (short circuit), and it is another extra information I need to keep in my mind when debugging (which is by default a heavy cognitive task).
To get the return values I need to either:
- Add some extra code. See Example 2. On the plus side, I can stop the execution at the
if
and see clearly what the situation is. On the minus side, it forces me to redeploy the code (testability testability of the service is another story rant, but luckily I can deploy code with 2-5 minutes of work) - Step into every method and see what is happening there
All of this makes me wonder if
- Is there a good balance between readable code and debuggable code, or do we sacrifice some part of one of them (debuggability) for the other (readability)?
- What can be considered good (clean?) code in this case?
- Am I using the debugger effectively? I mean extending further my knowledge basically solves the problem I described here.