Hi all,
Super glad to be here! This is my first real Rust project, I've written small web backends and CLI tools in it before but this is the first tool I have that has actually gotten large and made me learn a lot more about the language. It's called Codestats. It's a lightning fast and super small code analysis tool, able to provide you analysis of over 400 programming languages on the latest master branch, 384 as of the latest release. With all of my filesystem caches cleared, it analyzes my Linux home directory, containing about 3.76 GB of code, in 8.1 seconds. It allows you to follow symlinks, analyze hidden files, and even follow your gitignores. It has multiple different output formats, including CSV, JSON, and a clean, human-readable report that's nice and readable for screen readers, unlike tools like SCC or Tokei. In the latest master version, I've also added customizable number formatting, percentage precision setting, etc.
Binaries for x64 Windows and Linux are provided on the releases page, but I also upload binaries to crates.io, which is the recommended way to install the tool. A simple:
cargo install codestats
should get you there.
Enjoy, and please feel free to give me any feedback, pull requests, issues, etc.
I've just put out Codestats 0.4.0, renaming the binary to the much easier to type cs, now sporting 410 supported programming languages, HTML and Markdown output formats, the ability to customize the presentation of numbers, how many decimal places percentages get rounded by, and even letting you sort the results by things such as the total number of lines, the file size, or even the number of comments! It's now on crates.io, so cargo install codestats should give it to you, and I also have GitHub releases here.
Nice, downloaded and tried it out. Some suggestions:
It's unclear from the help/error message that cs analyze needs a path argument. Also, it should just default to . if none is given
analyze is rather long; unless you plan on adding several more equally important subcommands, cs should probably default to cs analyze
Getting separate stats for doc comments and code comments could be a nice feature
Getting separate stats for test and normal code could be a nice feature (just a heuristic approximation would be enough, eg. counting lines within #[cfg(test)]\nmod and the next same-indentation } would probably be 99% accurate)
It's unclear from the help/error message that cs analyze needs a path argument. Also, it should just default to . if none is given
Thanks for the feedback, I hadn't thought of making it default to . but that's a good idea. Also agreed on the help.
analyze is rather long; unless you plan on adding several more equally important subcommands, cs should probably default to cs analyze
I was actually thinking about this exact thing before I went to sleep last night. What I think I'll do for the next version is remove the subcommand system entirely, making the langs command just be a flag, like -l or --languages.
Getting separate stats for doc comments and code comments could be a nice feature
Ooh, good idea! I also want to add the ability for it to tell you how much of your code is inside of strings, but things like Python with its docstrings make this slightly more difficult.
Getting separate stats for test and normal code could be a nice feature (just a heuristic approximation would be enough, eg. counting lines within #[cfg(test)]\nmod and the next same-indentation } would probably be 99% accurate)
Ooooh, now that's a good idea. Wonder if I could detect JUnit test files, Go tests, etc as well?
The latest master version now did what you suggested, analyze is no longer a subcommand, and simply running cs will cause it to analyze your cwd and print the results in human-readable format.
Also possibly worth noting is that I'm fully blind, so I welcome any stylistic tweaks to the output, the readme, etc., as long as they don't break accessibility.
In other words, Codestats is lightning fast!
Would love to get some more eyes on it, code counting utilities are really cool and fun in my opinion, and the Rust community seems super nice and welcoming. I'm still not super good at rust, so completely welcome any feedback you may have on my code.
