4 ms·
I don’t necessarily disagree. But I do think that all other things being equal, less code is better than more code - fewer bugs, easier to understand. The catch
by projectileboy 8y ago
I don’t necessarily disagree. But I do think that all other things being equal, less code is better than more code - fewer bugs, easier to understand. The catch is what falls into “all other things being equal”. Where I’ve been frustrated with others is when they reject brevity in situations where it’s idiomatic for the language (e.g., ‘it’ as an implicit variable in Groovy list comprehensions that aren’t especially complicated). Forgive me if I sound crazy; maybe it’s just a reaction to having spent so many years in the Java community, where no name is long enough, and no amount of code is too much.
- romwell 8y agoTrue, the world could do with less code that looks like Fizz Buzz Enterprise Edition :) In this case, though, the OP makes a strong point that constructs like data[index++] = value; aren't idiomatic to Java - even the spec advises against this. And in any case, side effects in assignments can be a tricky thing to understand. Sometimes they are necessary, as in status = perform_computation_on_data(some_mutable_data); But in the example discussed is not in this vein. I'd say it's not pretty for the same reason as cramming two statements on one line: data[i]=value; i++; is not pretty: it's trying to do two things with one line, which kind of defeats the point of breaking up code into lines. So I don't disagree with you - but there's a happy medium between Fizz Buzz Enterprise and Code Golf - style code :)
- vorg 8y agoUnlike `i`, `g`, or `p`, the variable `it` is an actual word in English, similar to other pronouns used as keywords, e.g. `this`, and other English word classes, e.g. `if`, `class`, and `try`, so your example from Apache Groovy doesn't really fit the argument.