I counted the lines of code in my own repo with two different tools. They disa… · @ReignSwords · TwKit

@ReignSwords

I counted the lines of code in my own repo with two different tools. They disagreed by 14,975 lines. Same folder. cloc said 723 files and 156,862 lines. scc said 809 files and 171,837 lines. One of them was quietly lying — actually both were, in opposite directions. What I ran: 1. cloc v2.08 (the Perl classic everyone quotes) and scc v4.1.0 (the Go challenger) on my 488MB skill library, then hyperfine'd both — 8 runs each, warm cache. 2. cloc silently deletes byte-identical files before counting. I keep vendored copies of the same skill in two folders. cloc counted them once. 83 files never made the total. The fix is one flag: --skip-uniqueness. 3. cloc can't see files named exactly LICENSE with no extension. 8 of them in my repo, invisible to cloc. scc has a whole "License" category for them. 4. scc silently ignores package-lock.json by default. 4 of them, and cloc counted every single line. 5. Speed: scc 12.6ms vs cloc 139ms. 11x faster. The old king is slow AND lossy. Verdict: neither number is wrong — cloc answers "how much unique code do I have", scc answers "how much stuff is in this folder". The problem is neither tool tells you which question it's answering. Know the question before you quote the number. If you've ever pasted a cloc number into a report, a resume, or an argument about rewrite-vs-refactor — rerun it with --skip-uniqueness first. You own more code than you think. I run one of these hands-on tests every day. Follow along if you want the next one in your feed. Be honest: when's the last time you questioned a number a tool handed you — or did its confidence do the thinking for you? 🔵 Fellow Premium members, let's connect! I post about AI & tech — follow for more 👥

曝光 28 · 评论 7 · 点赞 0 · 书签 0