Hacker News Reader

Comment by veganjay | Hacker News Reader

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

Still this is a fun read. I'm curious to see what other tricks are out there.

View on HN

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.

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.

A bug is still a bug even if it's low severity and marked wontfix due to implementation complexity.

I wouldn't call an accuracy-performance tradeoff a bug, rather a design decision

No one is running sloc a million times per second. The performance cost here is trivial.

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.

No, but you usually run it on a complete codebase which can be humongous.

Humongous what?

..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.

Reply on news.ycombinator.com