3 ms·
The problem here is that most programmers confuse readability with familiarity and/or aesthetics. Readability has to be an objective measure, because it would b
by klibertp 12y ago
The problem here is that most programmers confuse readability with familiarity and/or aesthetics. Readability has to be an objective measure, because it would be totally irrelevant if it was just a subjective impression, yet we still have no idea what readability really means and how to measure it. Not to mention it seems to be very context sensitive.
One nice write-up on readability I saw is this: http://www.perlmonks.org/?node_id=592616 http://www.perlmonks.org/?node_id=592616 along with sources cited therein. It sums up the problems with defining readability nicely.
The bottom line is that we can't say for sure if this:
total_seconds = hours * 3600; // seconds per hour
is any better than this:
total_seconds = hours * SECONDS_PER_HOUR;
or this:
total_seconds = hours * 60 * 60;
or this:
total_time = hours * 60 * 60; // in seconds
or this:
total_time = TO_SECONDS( hours );
or this:
total_time = SECONDS_FROM_HOURS( hours );
or... you get the idea.
And we not only don't know which is better in general, but even which would be better in most specific conditions. We just don't know. Saying otherwise is just an expression of opinion or personal preference. I think acknowledging this would be a decent first step towards improving the readability level of code in general.
- raverbashing 12y agoTrue, amongst the examples given they all score more or less the same to me (and it's a short example) A lot on readability stands on the expectations of the reader (and the idioms of the language) as well. For a lisp programmer (* (hours 3600)) may be easier to read for example. Now I can take that example and turn into ttscds = x * (36 * 10 * 10); And we know this is less readable, the intentions are hidden and nobody unfamiliar with the code knows what's going on.