4 ms·

Except that the linked article makes no distinction between LOC and SLOC (quote: "Source lines of code (SLOC), also known as lines of code (LOC)"). So saying "a

Except that the linked article makes no distinction between LOC and SLOC (quote: "Source lines of code (SLOC), also known as lines of code (LOC)"). So saying "and only around 99 SLOC" is just as wrong since SLOC could mean either physical or logical, but physical is often abbreviated as loc (quote: "There are two major types of SLOC measures: physical SLOC (LOC) and logical SLOC (LLOC)") so in that sense, the parent comment might even be more right. This is all very pedantic and very meaningless - but I think that the parent comment was more right in spirit, even though "technically" wrong since LOC doesn't seem to have a very clear definition and assuming that LOC stands for physical SLOC doesn't seem to be dominant enough to be the de facto assumption. But if I want to know about the maintenance surface area for a lib, I'd want to know the physical sloc, so I think it's a fair assumption here. And I want to end with I hate myself for even bothing to waste my time with this nonsense, but the parent comment was downvoted, and I hate seeing people that are right be downvoted. But if I participate, I usually like to explain my reasoning for my involvement.

eesmith 2y ago
I pointed it out because I thought the spirit of "It's not" was harsher than called for. The difference doesn't affect the point, and the term is not well enough defined to be that firmly negative. My suggestion was to tone it down, and explain my reasoning. For what it's worth, while Microsoft GitHub reports "99 sloc", that number is still not "physical SLOC" because, quoting Wikipedia, "the most common definition of physical SLOC is a count of lines in the text of the program's source code excluding comment lines", while that 99 appears to be computed by removing all blank lines - including those in docstrings - but keeping the three comment lines. Even more fun, this specific program contains a docstring containing a Python code example containing a Python comment, with a blank line that improves readability and cannot be cleaned up by a code formatter. Hence my use of "around 99". This is an inherently fuzzy metric, not deserving of such precise interpretations. As long as your code base is consistent in comment style, docstring detail, formatting, etc., all of these loc measures should be equally predictive of your maintenance overhead. And if they aren't, that Wikipedia entry gives an example of how a single logical SLOC could be 1 or 4 physical SLOC, making physical SLOC at best a rough estimate.

eesmith 2y ago

I pointed it out because I thought the spirit of "It's not" was harsher than called for. The difference doesn't affect the point, and the term is not well enough defined to be that firmly negative. My suggestion was to tone it down, and explain my reasoning. For what it's worth, while Microsoft GitHub reports "99 sloc", that number is still not "physical SLOC" because, quoting Wikipedia, "the most common definition of physical SLOC is a count of lines in the text of the program's source code excluding comment lines", while that 99 appears to be computed by removing all blank lines - including those in docstrings - but keeping the three comment lines. Even more fun, this specific program contains a docstring containing a Python code example containing a Python comment, with a blank line that improves readability and cannot be cleaned up by a code formatter. Hence my use of "around 99". This is an inherently fuzzy metric, not deserving of such precise interpretations. As long as your code base is consistent in comment style, docstring detail, formatting, etc., all of these loc measures should be equally predictive of your maintenance overhead. And if they aren't, that Wikipedia entry gives an example of how a single logical SLOC could be 1 or 4 physical SLOC, making physical SLOC at best a rough estimate.