5 ms·
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 par
by 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 agoA bug is still a bug even if it's low severity and marked wontfix due to implementation complexity.
- proto-n 6y agoI wouldn't call an accuracy-performance tradeoff a bug, rather a design decision
- alisonkisk 6y agoNo one is running sloc a million times per second. The performance cost here is trivial.
- ashutoshgngwr 6y agoNo, but you usually run it on a complete codebase which can be humongous.
- mmmeff 6y agoHumongous 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 agoThe 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 agoIt 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.