3 ms·

> cost us Y lines of code I don't like these rules of thumb that when taking literally screws us. Some manager is going to want to minimize locs now. Code suc

> cost us Y lines of code I don't like these rules of thumb that when taking literally screws us. Some manager is going to want to minimize locs now. Code suckiness per feature is a qualitative measurement. I don't think there should be any allusion of absolute numerical scores for that property.

karmakaze 3y ago
This is where the distinction between essential/intrinsic and incidental/accidental complexity comes in. Any code in the solution but not required in the solution is excess. Usually though we don't measure this in lines, but rather in cognitive load (which can come in any number of inappropriate choices).
- rightbyte 3y ago
  Ye sure. I know good code when I see it. The scale is very fuzzy, and others might disagree with my taste and we both are right. "Cognitive load" has to be normalized by "stuff done". I mean the unit is something like: (stuff done by app) / (code stuff) where 'code stuff' is really really fuzzy. I mean dependencies count into that measure, even though they are zero loc written by you. Etc.
  - karmakaze 3y ago
    I agree that it's a fuzzy scale. What I usually pick out isn't the amounts of stuff but how much of it either goes against the grain or piles on abstractions without a simplifying payoff (reduced cognitive load). Basically it comes down to picking the right set of abstractions (choosing your chunks/seams) and good naming since the factors which are being separated aren't vague. Few things are 50/50--those cases rather tend to be "no one really knows yet". My phrasing is "you'll know good code when it's shown to you" where "you" is myself for my own work.
_v7gu 3y ago
That’s the kind of opportunity I’m looking for to introduce array languages to the codebase :^)
- rightbyte 3y ago
  Imagine the horrors being fresh out of college and inherit some APL code with Perl as glue, that was made to meet some loc metric.
  - _v7gu 3y ago
    Honestly, the array languages are special in a way that the shortest solutions are usually also the most generalized solutions. I’d be more afraid of javascript or Python codebases that were built to minimize loc.
tesdinger 3y ago
Often using a solution with many lines of code can be better, if it solves all the problems just by installing a finished product, even if it contains unnecessary parts, rather than a "keep it simple stupid" solution where you write only the needed parts yourself but have a lot more work to turn it into a tested and complete product. I don't use most of the protocols of my enterprise router but I won't write the routing protocols I need myself nor build a router myself, I just buy a router and ignore most of its features.
- tesdinger 3y ago
  If the features of a product are properly decoupled from each other, you can get comparable results to the situation where they haven't been added at all.

karmakaze 3y ago

This is where the distinction between essential/intrinsic and incidental/accidental complexity comes in. Any code in the solution but not required in the solution is excess. Usually though we don't measure this in lines, but rather in cognitive load (which can come in any number of inappropriate choices).

rightbyte 3y ago
Ye sure. I know good code when I see it. The scale is very fuzzy, and others might disagree with my taste and we both are right. "Cognitive load" has to be normalized by "stuff done". I mean the unit is something like: (stuff done by app) / (code stuff) where 'code stuff' is really really fuzzy. I mean dependencies count into that measure, even though they are zero loc written by you. Etc.
- karmakaze 3y ago
  I agree that it's a fuzzy scale. What I usually pick out isn't the amounts of stuff but how much of it either goes against the grain or piles on abstractions without a simplifying payoff (reduced cognitive load). Basically it comes down to picking the right set of abstractions (choosing your chunks/seams) and good naming since the factors which are being separated aren't vague. Few things are 50/50--those cases rather tend to be "no one really knows yet". My phrasing is "you'll know good code when it's shown to you" where "you" is myself for my own work.

_v7gu 3y ago

That’s the kind of opportunity I’m looking for to introduce array languages to the codebase :^)

rightbyte 3y ago
Imagine the horrors being fresh out of college and inherit some APL code with Perl as glue, that was made to meet some loc metric.
- _v7gu 3y ago
  Honestly, the array languages are special in a way that the shortest solutions are usually also the most generalized solutions. I’d be more afraid of javascript or Python codebases that were built to minimize loc.

tesdinger 3y ago

Often using a solution with many lines of code can be better, if it solves all the problems just by installing a finished product, even if it contains unnecessary parts, rather than a "keep it simple stupid" solution where you write only the needed parts yourself but have a lot more work to turn it into a tested and complete product. I don't use most of the protocols of my enterprise router but I won't write the routing protocols I need myself nor build a router myself, I just buy a router and ignore most of its features.

tesdinger 3y ago
If the features of a product are properly decoupled from each other, you can get comparable results to the situation where they haven't been added at all.