Ask HN: Is removing as many LOC as possible really that big of a priority?

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.

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

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.

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.

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.

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.

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.

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

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.

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.