Reducing attack surface is a lesson for everyone. Newcomers are impressed by massive piles of code.
Seasoned developers are unimpressed, or even disgusted, by the same massive piles of code.
Reducing attack surface is a lesson for everyone. Newcomers are impressed by massive piles of code.
Seasoned developers are unimpressed, or even disgusted, by the same massive piles of code.
i don't think LoC is the metric. sometimes fewer lines of code results in a larger attack surface through type coercion / widening, poor abstractions, hiding or stuffing behavior (modules that do everything), etc. to me, making code easy to understand, test, fuzz, and verify is more important. sometimes that requires more lines of code.
More abstract code probably results in more high-abstraction-level bugs per LoC, but also less low-abstraction-level bugs so I'd guess it about cancels out to an even rate per LoC.
A single line in C++, Rust or Haskell can have a really subtle logic error. A single line in assembly can't, but it has that same likelihood of having a register allocation error instead, and when you add up all the many lines of assembly you probably still wrote the same number of logic errors as the C++ version.
LoC *IS* the metric. It is obviously not perfect tho but still the best one to compare software surface. Including to compare the same solution in different languages and platforms. The less code you need to manage, the less code you need to change and the less code you need to hold in your head to understand it (or in the LLM context nowadays).
https://www.folklore.org/Negative_2000_Lines_Of_Code.html