2 stable releases
|1.1.6||Jul 30, 2020|
|1.1.5||Jul 27, 2020|
#7 in #make
32 downloads per month
version: 1.1.6 date: 2020-07-30 authors: Luciano Bestia
Lines of code for Rust projects
Lines of code are not a "perfect" measurement of anything.
Anybody can write a very big number of lines of useless code and comments.
But for 95% of the cases they are good enough.
Most of the developers use some "standard" coding practices and that is quantifiable and comparable.
src_code_lines is the most important count.
That is actual code written for that project without doc comments, comments, unit tests, integration tests and examples.
Sometimes is great to see a big number here. It means there was a lot of work invested. But other times we want to see a small number. It means the developer understands the problem very well and don't try to solve anything outside that scope.
src_doc_comment_lines counts doc comments. They will eventually become docs. The count of lines shows how many documentation is written.
src_comment_lines counts code comments. Code comments are important to understand the code. The count of lines shows how understandable is the code.
tests_lines counts lines in tests and shows how good is the code tested. Here are the unit tests and integration test combined.
examples_lines counts lines in examples and shows how good is explained how to use the code.
The folder structure of a single Rust project is simple.
The project starts in the folder that contains cargo.toml.
The /src/ folder contains all the rust *.rs files.
The /tests/ folder contains integration tests.
The /examples/ folder contains examples.
Inside a rs file the doc comment line start with /// or //!.
The normal comments start with // or /!.
I will ignore the block comments. They are usually NOT used for comments, but to temporarily disable a piece of code. So I count this as code and not comments.
The src/*.rs file can contain unit tests that start with #[cfg(test)]. I assume that these are always at the end of the file. There should not be any normal code after #[cfg(test)], only tests.
All other files: md, toml, html, js, ... are not counted.
Workspaces have member projects, that are written in cargo.toml.
The program counts lines of every project and sums them together.
The output is markdown text for a table and markdown text for shield badges.
If the CLI is called with one argument:
This will be used for the link of all 4 shield badges.
Else the app will try
git remote -v
to get the remote url.
You can copy/paste it into README.md.
If the README.md file contains these markers:
[comment]: # (lmake_lines_of_code start)
[comment]: # (lmake_lines_of_code end)
the CLI will include the shield badges code between them.
It will erase the previous content.
Use git diff to see the change.
cargo install lmake_lines_of_code
Run in the Rust project folder, where cargo.toml is.
If you use git:
If you don't use git add the link of repository as CLI argument:
List of prepared make tasks for development: build, run, doc, publish,...
clear; cargo make
I use this make util: https://crates.io/crates/cargo-make
I splitted the project into a lib and bin, so it could be used also as a lib.
Try to using MockAll for testing.
Testing is difficult, because I use this own project to get the lines of code for the tests.
These will change as the code is modified. Moreover, the result from $git remote -v is different on different computers. To align with this changes, the testing has 2 const that must be manually updated to contain the actual data.
Testing will also modify the README.md file. Always after testing run cargo make doc to correct the README.md. Or just revert it using git.
Please, spread this info.
Open source code needs a community effort to express trustworthiness.
Start with reading the reviews of the crates you use. Example:
Than install the CLI cargo-crev.
Read the Getting Started guide.
On your Rust project, verify the trustworthiness of all dependencies, including transient dependencies with
cargo crev verify
Write a new review for the crates you trust. Or for the crate versions you think are dangerous.
Help other developers, inform them and share your opinion.
Use this webpage to help you: