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 enoug

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.