3 ms·

For anyone interested in this sort of thing, there's also Unified Code Count (UCC) [1]. It has a lot of interesting design goals like being open and explicit ab

For anyone interested in this sort of thing, there's also Unified Code Count (UCC) [1]. It has a lot of interesting design goals like being open and explicit about the counting rules, which is really useful if you want to predict things like cost and reliability. [1] https://csse.usc.edu/ucc_new/wordpress/ https://csse.usc.edu/ucc_new/wordpress/

boyter 7y ago
I actually lot ucc in the not so great categories. Counters like scc and Tokei are getting close to having the same accuracy as a compiler when it comes to code while being much faster. They are also support for more languages and are updated way more often. Very much second generation tools that learnt from the first.
- OnlyOneCannolo 7y ago
  Different tools for different use cases. Your use cases seem to prioritize language support, update frequency, and speed (what do you mean by the accuracy part?). For this, Scc and Tokei would of course be better than UCC. The (admittedly niche) use cases I described require understanding the counting rules very well, and keeping those rules stable. For this, scc and Tokei are as useless as anything else, while UCC does exactly what's needed.
  - boyter 7y ago
    Have a look at the tests in scc and tokei. They support nested multiline comments, string escapes and other odd language features. As such both get very close to counting lines the way a full tokeniser used by the compiler or interpreter do making them very accurate. I see your point. I’d argue however the rules for counting should be language rules not some higher level generic set.
    - OnlyOneCannolo 7y ago
      Ah, now I see what you mean by 'accuracy'. Each language does have its own counting rules. There's a separate PDF for each one describing the rules for that language, which is the cool part.

3 ms·

For anyone interested in this sort of thing, there's also Unified Code Count (UCC) [1]. It has a lot of interesting design goals like being open and explicit ab

by OnlyOneCannolo 7y ago

boyter 7y ago
I actually lot ucc in the not so great categories. Counters like scc and Tokei are getting close to having the same accuracy as a compiler when it comes to code while being much faster. They are also support for more languages and are updated way more often. Very much second generation tools that learnt from the first.
- OnlyOneCannolo 7y ago
  Different tools for different use cases. Your use cases seem to prioritize language support, update frequency, and speed (what do you mean by the accuracy part?). For this, Scc and Tokei would of course be better than UCC. The (admittedly niche) use cases I described require understanding the counting rules very well, and keeping those rules stable. For this, scc and Tokei are as useless as anything else, while UCC does exactly what's needed.
  - boyter 7y ago
    Have a look at the tests in scc and tokei. They support nested multiline comments, string escapes and other odd language features. As such both get very close to counting lines the way a full tokeniser used by the compiler or interpreter do making them very accurate. I see your point. I’d argue however the rules for counting should be language rules not some higher level generic set.
    - OnlyOneCannolo 7y ago
      Ah, now I see what you mean by 'accuracy'. Each language does have its own counting rules. There's a separate PDF for each one describing the rules for that language, which is the cool part.