
Ask HN: Is removing as many LOC as possible really that big of a priority? - ng-user
I&#x27;m a student, working at my first job in the industry. We don&#x27;t use a rubber duck here but I&#x27;ve been noticing companies using the &quot;Rubber Duck Challenge&quot; as incentive to remove as many LOC as possible. Is this practical?<p>Surely you&#x27;d want to remove only when necessary, I understand trying to refactor a legacy codebase to something more manageable, but usually (unless it&#x27;s terribly written) removing lines by condensing things down only leads to harder legibility.<p>Can anyone who&#x27;s used this method or has (more) experience in the industry throw their 2¢ in?
======
psyc
Removing LOC as a result of better conceptualization/design and better
factoring is completely different than reducing legibility by, say, mashing
lines together. In general, other things being equal, my late drafts are
usually less verbose than early drafts, and also reflect a deeper
understanding of the problem.

So, I think better design is the goal, and fewer LOC is a natural side effect.
I personally find _that_ essential for evolving a large project. Some managers
are ok with ever-increasing tech debt, which I associate with increasing job
dissatisfaction.

------
twobyfour
Most of the comments so far are on point. I just want to add that the
reasoning behind preferring less code over more is that every line of code you
don't have is a line of code you don't have to maintain. It's a heuristic you
can use to remind yourself to ask whether you really need that extra feature
or to handle every one of that set of corner cases individually. It's also a
reminder to yourself that retiring and stripping out older seldom-used
features is usually a good thing.

------
akulbe
Here's what I've always heard:

make it work

make it right

make it fast

Getting to the point where you can remove LOC takes mastery.

------
w4tson
Incentivizing anything can lead to unwanted consequences. Even virtuous things
such as reducing code.

This for me is a bad idea. I always have it in the back of my mind about
reducing a modules footprint but as someone else mentioned on here. There's an
art to it. Sometimes it's a bodge, followed by another fix in another part of
the code base a month later which then frees you to delete.

Quite often it's like that actually. Patience is key.

I'd also like to add +1 for duplicating code. I see lot of devs just unwilling
to dupe code at the cost of readability and speed of development.

Perhaps that code could be refactored down the line or more often the act of
making it "neat" gives up 1 or more niceties that made you write it like that
in the first place.

------
smt88
> _usually (unless it 's terribly written) removing lines by condensing things
> down only leads to harder legibility_

You're right, but that's not _always_ true. In any sufficiently large project,
there are thousands of LoC that can be removed by changing libraries, writing
DRYer code, etc.

However, turning it into a competition probably isn't going to stay within the
lines of "good" lowering of LoC.

And, in some cases, increasing LoC can make the code better. For example,
breaking up a huge method into several, well-named methods will slightly
increase LoC, but also increase readability.

------
hluska
I always tell developers I work with to primarily optimize for readability.
Assume that someone less intelligent and skilled than you will have to
maintain the code five years after you have left.

Sometimes, the most readable solution is quite long. Other times, it's short
and compact. But, if it's always readable, chances are high that it is not
only well designed, but it will be easy to maintain.

------
AnimalMuppet
As many as you can? No.

LZW compression tries to remove as many bytes as possible from text, but it
does _not_ help readability. I know, you wouldn't LZW compress the source and
then try to compile it. You can move in that direction, though, if you try to
shorten the source too much.

Remove needless duplication. Remove lines where it improves clarity or
structure. Absolute shortest source code is _not_ a worthwhile goal.

------
seanwilson
Yes, as long as it isn't sacrificing readability. Every line of code is
another you have to maintain going forward as you make changes and every line
can potentially contain bugs.

------
bjourne
Yes. Simplifying complicated code is THAT BIG of a priority.

------
eberkund
Well one instance I can think of is removing functionality in favor of
libraries or higher level languages. That can usually cut down on complexity
in the codebase significantly.

