On 24/08/13 06:58, H. S. Teoh wrote:
In none of the above examples did I try to deliberately game with the
metric. But the metric is still pretty inaccurate, and requires
subjective judgment calls.
It's a heuristic, rather than a metric, I'd say. But as a heuristic it may be
useful to compare things like
(i) what's the minimal number of lines needed (not artificially compressing
them!) to write the algorithm idiomatically?
(ii) how many more (or less) lines do you need to optimize the code for
performance?
(iii) how many more lines do you need to parallelize the code effectively and
safely?
By the way, for your example:
auto formatYear(int year, int monthsPerRow)
{
enum colSpacing = 1;
return
datesInYear(year)
.byMonth()
.chunks(monthsPerRow)
.map!(r =>
r.formatMonths()
.array()
.pasteBlocks(colSpacing)
.join("\n"))
.join("\n\n");
}
Although obviously there are only 3 _logical_ lines there (the function
declaration, the enum, and the return statement), here I'd be inclined to say
the number of _significant_ lines is 12 (I'm ignoring the braces). The fact
that you needed to spread the expression out across multiple lines in order to
be readable does carry useful information about the language, IMO.
That doesn't necessarily say the language is _bad_. It's difficult to see how a
language could reduce the space needed for that expression without also reducing
comprehensibility.
