|
|
|
|
|
|
by hNewsLover99
3747 days ago
|
|
|
I'm no expert but it seems to me that the relative value of two programs (or functions or classes or whatevers) can be determined by only their LOC count only in the most trivial cases - e.g., a class that uses a single construtor/parameter signature and performs a single task under a single set of conditions. If the logic has to handle multiple, possibly overlapping parameters and branching conditions in order to "do the same thing", then the longer code may well "outperform" the shorter one by whatever metric is most relevant to the use case (e.g., perform faster, use less energy, use less memory, be more readable, maintainable, portable, secure, or any weighted or unweighted combination of such metrics). Does this make sense or am I missing something?? |
|
|
The lemma says: take two programs that does the same thing, one of the sources is shorter means you can attribute a produced-value (call that how you want) per line of code.
Then the theorem says: take any two programs (linux and gcc for example), the code that has, in average, the more value per line, is greater. (You have to trust that one of the two programs has, in average, more value per line of code because they have an average value says the lemma.)
Now you can say that a practice that tend to decrease the number of line of code is a good practice while the other that tends to increase the number of line of code is a bad practice assuming the resulting programs would do the same thing.
The thing is that in most situations the resulting programs are assumed to be doing the same thing. For example, when you choose between object-oriented versus functional programming, you are likely to be making a choice having a common resulting program in mind. If it's not the case, like for example, you worry that performances are not going to be good enough using this or that method, then it's indeed perfectly fine to choose the method that allows you to write the right program.