4 ms·

> It's only 127 lines of code It's not, a lot of this are comments. It's around 99 LOC

eesmith 2y ago
"lines of code" is not that well defined. https://en.wikipedia.org/wiki/Source_lines_of_code https://en.wikipedia.org/wiki/Source_lines_of_code comments that one of the disadvantages of the term is: > there is no standard definition of what a line of code is. Do comments count? Are data declarations included? What happens if a statement extends over several lines? – These are the questions that often arise. Though organizations like SEI and IEEE have published some guidelines in an attempt to standardize counting, it is difficult to put these into practice especially in the face of newer and newer languages being introduced every year. The term SLOC specifically excludes comments ("the most common definition of physical SLOC is a count of lines in the text of the program's source code excluding comment lines", Wikipedia), so a less negative response might have been "and only around 99 SLOC".
- preommr 2y ago
  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.

"lines of code" is not that well defined. https://en.wikipedia.org/wiki/Source_lines_of_code https://en.wikipedia.org/wiki/Source_lines_of_code comments that one of the disadvantages of the term is: > there is no standard definition of what a line of code is. Do comments count? Are data declarations included? What happens if a statement extends over several lines? – These are the questions that often arise. Though organizations like SEI and IEEE have published some guidelines in an attempt to standardize counting, it is difficult to put these into practice especially in the face of newer and newer languages being introduced every year. The term SLOC specifically excludes comments ("the most common definition of physical SLOC is a count of lines in the text of the program's source code excluding comment lines", Wikipedia), so a less negative response might have been "and only around 99 SLOC".

preommr 2y ago
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.