Yes, you ought to have the ability to determine what existing code does, and yes, you ought to not be a jerk about it.
Nevertheless the “readability is approximate” is 20% precise, 80% hazardous.
There are unbiased guidelines that you can use to enhance readability. For instance, if you encounter a variable called “range”, right away include the system to that variable name. It now states distanceInCentimeters and you have actually enhanced your readability. General rule: include your systems in names.
If that variable was called range and it in fact includes the outcome of increasing a length times a width, remedy the name. General rule: prevent lies.
If you have distance1 and distance2, possibly they ought to be distanceFromGoal and distanceFromStartingLine. General rule: prevent uncertainty.
I’m not going to keep going.
An expert designer needs to have the ability to determine any code, no matter how bad. However an excellent tool for comprehending bad code is to begin using the above guidelines, making little devotes that make no practical modifications, simply name modifications, as you go. You’ll ultimately get to a point where you have actually relabelled whatever and you see what utilized to be speed = range/ time was in fact speedInFeetPerSecond = trackAreaInFeet/ timeInHours and it will be right away apparent to both you and all the other readers who disagree on what readability implies that the code never ever in fact worked.
That stated, as the post states, prevent stating things bad even if they aren’t what you would have composed. Strong suggestions.