4 ms·

Because, although it’s only one of many factors to consider, brevity matters.

whatshisface 8y ago
If you're writing Java, brevity is already out of the window, just on the grounds of how namespaces work and the library/framework naming conventions.
romwell 8y ago
I'm firmly in the clarity over brevity camp[1] If you think brevity means clarity, try reading some old Fortran code with comments stripped out and single-letter variable names like i, j, k, b, g, h, m, p, q, etc. (I say Fortran because in that era, such variable names were much more in vogue to save a couple of bytes here and there - but really, this can be done in any language). Even simple algorithms (like finding the center of the circle through three given points) become puzzles. But sure, they are brief. [1]https://signalvnoise.com/posts/3250-clarity-over-brevity-in-variable-and-method-names https://signalvnoise.com/posts/3250-clarity-over-brevity-in-...
- 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 ago
    True, 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 ago
    Unlike `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.

If you're writing Java, brevity is already out of the window, just on the grounds of how namespaces work and the library/framework naming conventions.

romwell 8y ago

I'm firmly in the clarity over brevity camp[1] If you think brevity means clarity, try reading some old Fortran code with comments stripped out and single-letter variable names like i, j, k, b, g, h, m, p, q, etc. (I say Fortran because in that era, such variable names were much more in vogue to save a couple of bytes here and there - but really, this can be done in any language). Even simple algorithms (like finding the center of the circle through three given points) become puzzles. But sure, they are brief. [1]https://signalvnoise.com/posts/3250-clarity-over-brevity-in-variable-and-method-names https://signalvnoise.com/posts/3250-clarity-over-brevity-in-...

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 ago
  True, 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 ago
  Unlike `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.