Nope. Less code is not always better. Collapsing a loop into a single line lambda with single char variables doing 5 times is not elegant or better. It’s orders of magnitude worse.
Less code is more readable. But absolute minimal amount of code can be unreadable.
"Less" doesn't mean "fewer bytes", it means "less complexity". If two ASTs do exactly the same thing, but one is easier to understand and has less structure, that one is probably better.
Less complex in lots of situations means being explicit, not being too template'y, not being too generic, abstract and writing code that is supposed to be a kind of meta that takes in a config and does several things for several inputs.
Writing less complex code in lots of situations just means writing lots of code. Which is diametrically opposite to the original statement of less code being better.
Being kind of meta, taking config, and doing several things for several inputs are good examples of ways to reduce the amount of code--when used appropriately. Being explicit reduces code too. Over abstracting and premature optimization can result in bloated spaghetti code.
By less code I mean less logic, not less characters. Less code generally means less work for the CPU (faster), less surface area for attacks, a smaller codebase that is easier to pick up and work on. When working with sets of numerical data, there are often two or more ways to come up with the desired result. A dumb imperative way, that may involve several loops and stages, or a simple and intelligent way that requires a deeper understanding of the math to implement properly. I've seen pages of slow code reduced to a few simple lines that are performant and easy to grok.
At a nonprofit I work with, there was a series of web forms that volunteers had to go through in order to enter a bunch of data.
Volunteers have never liked this form, but it was at one point necessary to collect all this data. A decade after those forms were built, it was decided to finally spend some of our (all volunteer) engineering capacity to help streamline the process associate with those forms. So, a junior volunteer comes in, hears the groans about this form, and found out a bunch of this data was already stored in other tables (in the interim smartphones became a thing and customer intake went from completely free form to a self-service signup process). The volunteer writes a bunch of selenium code to pull data out of a few tables and use it to population about 80% of the form fields, leaving volunteers with only 20% of the original work!
Some time later the whole thing gets reviewed by an (again, volunteer) old hat staff who were around when the original form sequences was developed. Turns out we no longer needed those 20% of fields, and ofc we already had the data in the other 80%... so all the original form code was deleted,
So the forms were retired completely, the selenium code was deleted, and the original problem was solved in a strictly superior way with 0 LOC by understanding the business need and historical context.
> So the forms were retired completely, the selenium code was deleted, and the original problem was solved in a strictly superior way with 0 LOC by understanding the business need and historical context.
Quite. Code is a liability. LOC is an utterly idiotic metric of programmer contribution, as it incentivizes increasing liability, over all sorts of other better contributions like good design, more automation, mentoring, customer obsession, etc.
(And for those arguing that “but the least amount of lines is not necessarily best”, yes, of course, that can obscure logic; the point isn’t to flip the value of LOC as a metric, the point is to not treat it as a good metric).
