3 ms·
Thanks for your feedback. > Sometimes, spelling things out in a slightly more verbose way is better than using some slick one-liner. I think you may have miss
by highCs 11y ago
Thanks for your feedback.
> Sometimes, spelling things out in a slightly more verbose way is better than using some slick one-liner.
I think you may have missed some details here. First, the code must be non-obfuscated. Here is the trick: you decide actually when the code is obfuscated. When it is, you probably want a more verbose code indeed.
You understand that, at some point in time, it may be hard for a programmer, you, to judge if your code is obfuscated or if it is actually weak code. If other programmers feel fine with the slick one-liner, the theorem would suggest that it might be useful for you to learn to read easily that kind of code because you may be actually writing weak code.
Finally on this: local exceptions are ok. It's all about averages.
> "all else being equal, fewer lines of code is better than more lines of code," but I'd argue that all else is rarely equal
I believe you make a little mistake here. It not all else being equal. It's for a program that does x. For a program that does x, fewer lines of code is better. Please note that, "does x" includes the complete behaviour of the program, performances, for example, included. A program that answer a request in 3 second does not do the same thing as a program that answer the exact same request in 3 minutes.
- pmiller2 11y agoI think I have to disagree, then. Suppose we have two examples of programs that do X (whatever X may be). Suppose the first program is slightly longer, but takes less time to produce. I would argue that typically the first program produces more value than the second just by virtue of having existed longer. Or, suppose we have two programs that do X. The first program is slightly longer, but easily extended to do Y as well as X. The second program does X equally as well as the first, but is not as extensible to also do Y. If Y is a thing that is worth doing (i.e. doing Y produces value), then the first program is better than the first. One more example: suppose the same program to do X can be written in two different languages, but programmers who know language 1 are easier to find and cost less to employ than those who know language 2. Even if the program is longer in language 1, it's probably better to write the program in language 1 rather than language 2. My point is that there are so many externalities beyond "a non-obfuscated program that does X" that affect how much value a piece of software is going to create, that length of the program is often not a primary concern.
- highCs 11y ago> Suppose the first program is slightly longer, but takes less time to produce. Then you may want to produce a lesser code. That's fine. You understand that it's not because it takes less time to produce a code that it is any better. Young wines are lesser than old ones, yet you may decide to drink young wines instead. > The first program is slightly longer, but easily extended to do Y as well as X. Thanks for this. So here the trick is that you can count X and Y as things that the program does. It's exactly like in accountability. Note that this trick is more powerful that it sounds at first because it gives actually a guidance to when you're over engineering and when you are not. Over engineering is then when you write a longer code than it should for the reason that X is something the program does when it's not. Like in accountability, you can sometimes extrapolate a little bit the results but not stretch them to far. > suppose the same program to do X can be written in two different languages, but programmers who know language 1 are easier to find and cost less to employ than those who know language 2 Then, again, you may want to produce lesser code - which is none of anyone business. It is up to you to judge what is more profitable: produce a lesser code or buy more expensive programmers - in practice, this is misjudged tremendously by many.