4 ms·

"this... to reduce LOC ? Doesn't feel like a valid reason in any language using braces..." It's not really a valid reason. Unfortunately, there are still a lot

"this... to reduce LOC ? Doesn't feel like a valid reason in any language using braces..." It's not really a valid reason. Unfortunately, there are still a lot of people who think LOC is a valid metric.

loup-vaillant 9y ago
Here's an extreme, yet very real example: mandatory Doxygen comments on accessors: /** * Get the foo * * @return the foo */ int getFoo(); /** * Get the bar * * @return the bar */ float getBar(); /** * Set the foo * * @param foo the foo */ void setFoo(int foo); /** * Set the bar * * @param bar the bar */ void setBar(float bar); Compare with what any sane project would do: int getFoo(); float getBar(); void setFoo(int foo); void setBar(float bar); Multiply that by a dozen such attributes, and what should fit on a single screen spans now hundreds of lines. What you could see at a glance, you have to search for. There's simply no way those utterly redundant comments increase readability. (Yes, the real comments in the real code were just as redundant.) LOC is more valid as a metric than most care to admit.
- macspoofing 9y ago
  Meh. It's noise but what's the harm? It was generated by an IDE so nobody had to physically type that. And usually no developer will be dwelling on this object or this area of the object. It just sits there doing no harm to anyone. >LOC is more valid as a metric than most care to admit. It's not.
  - taeric 9y ago
    I seem to recall that LOC correlated just as heavily with bugs and other problems as any other measure it was put up against. And, just like every other measure, gaming it leads to a degenerative case. (Can't remember where I saw this, or I would provide a citation.) I'll repeat my current gut feeling. Intrinsic measures of software quality are terrible as guides for how to write code. They are decent at predicting quality, but are not usable in a prescriptive way to write quality code.
  - loup-vaillant 9y ago
    > It was generated by an IDE Not all of it, actually. > nobody had to physically type that We totally had to read that. > And usually no developer will be dwelling on this object or this area of the object. Well… yes, usually. Sometimes however we did want to pay more attention than usual. At that point the original dev would have made a real comment. And that comment was lost in the noise, so you couldn't even distinguish between real comments and useless boilerplate.
- redwolf2 9y ago
  Also: Why use get and set accessors for private fields at all, when you can just use: int foo; float bar; That can later be changed, when the need arises.
- edejong 9y ago
  Or you use scala: case class Baz(foo: Int, bar: Float) Gives you a free hashCode, equals and copy as well.

loup-vaillant 9y ago

Here's an extreme, yet very real example: mandatory Doxygen comments on accessors: /** * Get the foo * * @return the foo */ int getFoo(); /** * Get the bar * * @return the bar */ float getBar(); /** * Set the foo * * @param foo the foo */ void setFoo(int foo); /** * Set the bar * * @param bar the bar */ void setBar(float bar); Compare with what any sane project would do: int getFoo(); float getBar(); void setFoo(int foo); void setBar(float bar); Multiply that by a dozen such attributes, and what should fit on a single screen spans now hundreds of lines. What you could see at a glance, you have to search for. There's simply no way those utterly redundant comments increase readability. (Yes, the real comments in the real code were just as redundant.) LOC is more valid as a metric than most care to admit.

macspoofing 9y ago
Meh. It's noise but what's the harm? It was generated by an IDE so nobody had to physically type that. And usually no developer will be dwelling on this object or this area of the object. It just sits there doing no harm to anyone. >LOC is more valid as a metric than most care to admit. It's not.
- taeric 9y ago
  I seem to recall that LOC correlated just as heavily with bugs and other problems as any other measure it was put up against. And, just like every other measure, gaming it leads to a degenerative case. (Can't remember where I saw this, or I would provide a citation.) I'll repeat my current gut feeling. Intrinsic measures of software quality are terrible as guides for how to write code. They are decent at predicting quality, but are not usable in a prescriptive way to write quality code.
- loup-vaillant 9y ago
  > It was generated by an IDE Not all of it, actually. > nobody had to physically type that We totally had to read that. > And usually no developer will be dwelling on this object or this area of the object. Well… yes, usually. Sometimes however we did want to pay more attention than usual. At that point the original dev would have made a real comment. And that comment was lost in the noise, so you couldn't even distinguish between real comments and useless boilerplate.
redwolf2 9y ago
Also: Why use get and set accessors for private fields at all, when you can just use: int foo; float bar; That can later be changed, when the need arises.
edejong 9y ago
Or you use scala: case class Baz(foo: Int, bar: Float) Gives you a free hashCode, equals and copy as well.