4 ms·

The title of the stackexchange discussion is a little misleading. It really is: '"Hello, World" in what sloc thinks is zero lines of source code' Most of the

The title of the stackexchange discussion is a little misleading. It really is: '"Hello, World" in what sloc thinks is zero lines of source code' Most of the top solutions seem to take advantage of bugs in the way sloc tries to parse commented lines. e.g. many are: /**/<do_something>/**/ And I'm surprised I don't see a related bug issue in the git repo: https://github.com/flosse/sloc/issues https://github.com/flosse/sloc/issues Still this is a fun read. I'm curious to see what other tricks are out there.

alexfrydl 6y ago
I think it's a bit much to name this a bug. This should have very little to no effect on real-world code, and the only way to fix it for real is to actually parse the languages.
- zamadatix 6y ago
  A bug is still a bug even if it's low severity and marked wontfix due to implementation complexity.
  - proto-n 6y ago
    I wouldn't call an accuracy-performance tradeoff a bug, rather a design decision
    - alisonkisk 6y ago
      No one is running sloc a million times per second. The performance cost here is trivial.
      - ashutoshgngwr 6y ago
        No, but you usually run it on a complete codebase which can be humongous.
        mmmeff 6y ago
        Humongous what?
        ashutoshgngwr 6y ago
        ..in source size. What I meant was while for a single source file, performance implications aren't noticeable. But usually when we run a tool like this, we happen to do it on an entire project, e.g. imagine running it on Kubernetes repo. If it were to parse entire syntax trees, the performance implications would be significant.
      - proto-n 6y ago
        The accuracy cost is trivial as well, it's a trade-off. I'm pretty sure the implementers were fully aware that regex can't properly handle every case and decided not to care.
- lilyball 6y ago
  It should in fact have an effect on real-world code. It looks like sloc in general doesn't handle nested block comments, so any source file that uses nested block comments will be counted incorrectly by sloc.

alexfrydl 6y ago

I think it's a bit much to name this a bug. This should have very little to no effect on real-world code, and the only way to fix it for real is to actually parse the languages.

zamadatix 6y ago
A bug is still a bug even if it's low severity and marked wontfix due to implementation complexity.
- proto-n 6y ago
  I wouldn't call an accuracy-performance tradeoff a bug, rather a design decision
  - alisonkisk 6y ago
    No one is running sloc a million times per second. The performance cost here is trivial.
    - ashutoshgngwr 6y ago
      No, but you usually run it on a complete codebase which can be humongous.
      - mmmeff 6y ago
        Humongous what?
        ashutoshgngwr 6y ago
        ..in source size. What I meant was while for a single source file, performance implications aren't noticeable. But usually when we run a tool like this, we happen to do it on an entire project, e.g. imagine running it on Kubernetes repo. If it were to parse entire syntax trees, the performance implications would be significant.
    - proto-n 6y ago
      The accuracy cost is trivial as well, it's a trade-off. I'm pretty sure the implementers were fully aware that regex can't properly handle every case and decided not to care.
lilyball 6y ago
It should in fact have an effect on real-world code. It looks like sloc in general doesn't handle nested block comments, so any source file that uses nested block comments will be counted incorrectly by sloc.