3 ms·

So, smaller programs do less, so there are less potential bugs. They are also easier to comprehend by developers.

• readthenotes1 4y ago
  That's not what i recall the 2001 paper saying. Iirc, it said if you pick a software complexity measure that it does not do a much better job than just simple lines of code. Back in those days, metrics were real and were used to try to help create and maintain software code quality. For instance there were some groups that would not allow code that had a McCabe cyclomatic complexity greater than x to survive. Course the easy way to skirt that is to break the module into however many modules you need to get them each under X. My take away from that paper was that the best life hack I can do would be to reduce whatever metric was being used to measure quality each time I checked in. It is shockingly easy to edit existing code to reduce the bulk while making it clearer. Oftentimes, that is simply just removing dead code. Sometimes it's modifying ridiculously convoluted code. Most the time, reducing the lines of code also reduces other complexity measures if you do it with care. Of course, my measure was never a target so I was never led to perverse incentives and dysfunctional behavior.