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.

Or you use scala:

case class Baz(foo: Int, bar: Float)

Gives you a free hashCode, equals and copy as well.

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.

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.

> 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.

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.