Rust-clippy - A bunch of lints to catch common mistakes and improve your Rust code

Overview

Clippy

Clippy Test License: MIT OR Apache-2.0

A collection of lints to catch common mistakes and improve your Rust code.

There are over 450 lints included in this crate!

Lints are divided into categories, each with a default lint level. You can choose how much Clippy is supposed to annoy help you by changing the lint level by category.

Category Description Default level
clippy::all all lints that are on by default (correctness, suspicious, style, complexity, perf) warn/deny
clippy::correctness code that is outright wrong or useless deny
clippy::suspicious code that is most likely wrong or useless warn
clippy::style code that should be written in a more idiomatic way warn
clippy::complexity code that does something simple but in a complex way warn
clippy::perf code that can be written to run faster warn
clippy::pedantic lints which are rather strict or have occasional false positives allow
clippy::nursery new lints that are still under development allow
clippy::cargo lints for the cargo manifest allow

More to come, please file an issue if you have ideas!

The lint list also contains "restriction lints", which are for things which are usually not considered "bad", but may be useful to turn on in specific cases. These should be used very selectively, if at all.

Table of contents:

Usage

Below are instructions on how to use Clippy as a subcommand, compiled from source or in Travis CI.

As a cargo subcommand (cargo clippy)

One way to use Clippy is by installing Clippy through rustup as a cargo subcommand.

Step 1: Install Rustup

You can install Rustup on supported platforms. This will help us install Clippy and its dependencies.

If you already have Rustup installed, update to ensure you have the latest Rustup and compiler:

rustup update

Step 2: Install Clippy

Once you have rustup and the latest stable release (at least Rust 1.29) installed, run the following command:

rustup component add clippy

If it says that it can't find the clippy component, please run rustup self update.

Step 3: Run Clippy

Now you can run Clippy by invoking the following command:

cargo clippy

Automatically applying Clippy suggestions

Clippy can automatically apply some lint suggestions, just like the compiler.

cargo clippy --fix

Workspaces

All the usual workspace options should work with Clippy. For example the following command will run Clippy on the example crate:

cargo clippy -p example

As with cargo check, this includes dependencies that are members of the workspace, like path dependencies. If you want to run Clippy only on the given crate, use the --no-deps option like this:

cargo clippy -p example -- --no-deps

As a rustc replacement (clippy-driver)

Clippy can also be used in projects that do not use cargo. To do so, you will need to replace your rustc compilation commands with clippy-driver. For example, if your project runs:

rustc --edition 2018 -Cpanic=abort foo.rs

Then, to enable Clippy, you will need to call:

clippy-driver --edition 2018 -Cpanic=abort foo.rs

Note that rustc will still run, i.e. it will still emit the output files it normally does.

Travis CI

You can add Clippy to Travis CI in the same way you use it locally:

language: rust
rust:
  - stable
  - beta
before_script:
  - rustup component add clippy
script:
  - cargo clippy
  # if you want the build job to fail when encountering warnings, use
  - cargo clippy -- -D warnings
  # in order to also check tests and non-default crate features, use
  - cargo clippy --all-targets --all-features -- -D warnings
  - cargo test
  # etc.

Note that adding -D warnings will cause your build to fail if any warnings are found in your code. That includes warnings found by rustc (e.g. dead_code, etc.). If you want to avoid this and only cause an error for Clippy warnings, use #![deny(clippy::all)] in your code or -D clippy::all on the command line. (You can swap clippy::all with the specific lint category you are targeting.)

Configuration

Some lints can be configured in a TOML file named clippy.toml or .clippy.toml. It contains a basic variable = value mapping e.g.

avoid-breaking-exported-api = false
blacklisted-names = ["toto", "tata", "titi"]
cognitive-complexity-threshold = 30

See the list of lints for more information about which lints can be configured and the meaning of the variables.

Note that configuration changes will not apply for code that has already been compiled and cached under ./target/; for example, adding a new string to doc-valid-idents may still result in Clippy flagging that string. To be sure that any configuration changes are applied, you may want to run cargo clean and re-compile your crate from scratch.

To deactivate the “for further information visit lint-link” message you can define the CLIPPY_DISABLE_DOCS_LINKS environment variable.

Allowing/denying lints

You can add options to your code to allow/warn/deny Clippy lints:

  • the whole set of Warn lints using the clippy lint group (#![deny(clippy::all)]). Note that rustc has additional lint groups.

  • all lints using both the clippy and clippy::pedantic lint groups (#![deny(clippy::all)], #![deny(clippy::pedantic)]). Note that clippy::pedantic contains some very aggressive lints prone to false positives.

  • only some lints (#![deny(clippy::single_match, clippy::box_vec)], etc.)

  • allow/warn/deny can be limited to a single function or module using #[allow(...)], etc.

Note: allow means to suppress the lint for your code. With warn the lint will only emit a warning, while with deny the lint will emit an error, when triggering for your code. An error causes clippy to exit with an error code, so is useful in scripts like CI/CD.

If you do not want to include your lint levels in your code, you can globally enable/disable lints by passing extra flags to Clippy during the run:

To allow lint_name, run

cargo clippy -- -A clippy::lint_name

And to warn on lint_name, run

cargo clippy -- -W clippy::lint_name

This also works with lint groups. For example, you can run Clippy with warnings for all lints enabled:

cargo clippy -- -W clippy::pedantic

If you care only about a single lint, you can allow all others and then explicitly warn on the lint(s) you are interested in:

cargo clippy -- -A clippy::all -W clippy::useless_format -W clippy::...

Specifying the minimum supported Rust version

Projects that intend to support old versions of Rust can disable lints pertaining to newer features by specifying the minimum supported Rust version (MSRV) in the clippy configuration file.

msrv = "1.30.0"

The MSRV can also be specified as an inner attribute, like below.

#![feature(custom_inner_attributes)]
#![clippy::msrv = "1.30.0"]

fn main() {
  ...
}

You can also omit the patch version when specifying the MSRV, so msrv = 1.30 is equivalent to msrv = 1.30.0.

Note: custom_inner_attributes is an unstable feature, so it has to be enabled explicitly.

Lints that recognize this configuration option can be found here

Contributing

If you want to contribute to Clippy, you can find more information in CONTRIBUTING.md.

License

Copyright 2014-2021 The Rust Project Developers

Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or https://www.apache.org/licenses/LICENSE-2.0> or the MIT license <LICENSE-MIT or https://opensource.org/licenses/MIT>, at your option. Files in the project may not be copied, modified, or distributed except according to those terms.

Comments
  • [WIP][DNM] Switch to GitHub Actions

    [WIP][DNM] Switch to GitHub Actions

    cc #4577

    This is just an experiment. I don't think we have a consensus if we should move away from travis/appveyor.

    GHA would let us run up to 20 concurrent jobs. Since we have 15 integration tests and 4 (linux, linux 32-bit, macos, windows) basic tests, we would be able to run everything concurrently. ~~Also IIUC we only have to build Clippy once for every initegration test and then only check the repos.~~ Nope, dependent jobs exist, but they won't keep the artifacts (not even the checkout).

    TODO before merge:

    • [x] Add DEPLOY_KEY secret to github repo
    • [ ] test deployment on test branch gh-test
    • [ ] talk with @rust-lang/infra for bors
    • [ ] Add GHA badge to Cargo.toml (blocked on rust-lang/crates.io#1838)
    • [ ] Add back travis + appveyor files for transition period (?)

    changelog: none

    S-needs-discussion S-waiting-on-review 
    opened by flip1995 85
  • Switch to GitHub Actions - Part 2 - From within

    Switch to GitHub Actions - Part 2 - From within

    This is a continuation of #5071. This time from a branch inside the rust-lang/rust-clippy repo, not from my fork, since secrets are not available in PRs from forks.

    Copying the description of #5071 to here:

    Closes #4577

    ~~This is just an experiment. I don't think we have a consensus if we should move away from travis/appveyor.~~ We have consensus: https://github.com/rust-lang/rust-clippy/pull/5071#issuecomment-576647638

    ~~GHA would let us run up to 20 concurrent jobs. Since we have 15 integration tests and 4 (linux, linux 32-bit, macos, windows) basic tests, we would be able to run everything concurrently.~~ The org has a limit of 60 jobs across the org, so we limit the matrix of the integration tests to 6 concurrent jobs.

    ~~Also IIUC we only have to build Clippy once for every initegration test and then only check the repos.~~ Nope, dependent jobs exist, but they won't keep the artifacts (not even the checkout).

    TODO before merge:

    • [x] Add DEPLOY_KEY secret to github repo
    • [x] test deployment on test branch gh-test#
      • [x] Test normal deployment
      • [x] Test deployment no changes
      • [x] Test deployment of tag
    • [x] talk with @rust-lang/infra for bors, @rust-lang/infra is good with the move (crater also uses GHA+bors)
    • [x] ~~Get remark + clippy_dev check to work on pushes (https://github.community/t5/GitHub-Actions/~Builds-are-not-triggered-with-on-paths/m-p/44075; I contacted GH support about this) ~~That seems to start working again yesterday. Let's hope it keeps working.~~ Or not: df9be48. Now it works again: 723786a. I think we should wait, until this is reliable. It appears, that it doesn't work on force pushes (sometimes?): 5814142~~ We need to run the bors tests unconditionally anyway (47138d1) so it doesn't really matter.
    • [x] ~~impl homu checks for GHA https://github.com/rust-lang/rust-clippy/pull/5071#issuecomment-576642983 -- I prepared: https://github.com/flip1995/rust-central-station/commit/f40230dc3cebfe4120c9dce027f61c18dd8935cb. I'd suggest to first add GHA and keep the travis and appveyor checks for a few days and to remove them in a second pass. The bors dummy jobs are added in https://github.com/rust-lang/rust-clippy/pull/5088/commits/1a83b7ad7a45aa8db4db7da55a45931e725a1ca3 and work as expected: https://github.com/rust-lang/rust-clippy/pull/5088#issuecomment-582055695. I opened https://github.com/rust-lang/rust-central-station/pull/578~~ See https://github.com/rust-lang/rust-clippy/pull/5088#issuecomment-584581420
    • [x] ~Add GHA badge to Cargo.toml (blocked on rust-lang/crates.io # 1838)~ Added a FIXME in 2332b57
    • [x] ~Maybe we should also wait until GHA supports yaml anchors. https://github.community/t5/GitHub-Actions/Support-for-YAML-anchors/td-p/30336/~ WIll probably not be implemented in the near future.
    • [x] Add back travis + appveyor files for transition period (!)

    changelog: none

    S-waiting-on-review 
    opened by flip1995 65
  • Lint for pointing out needless continue statements, fixes #111

    Lint for pointing out needless continue statements, fixes #111

    This lint deals with two separate cases of needless continue statements.

    Case 1: continue is the first/only statement in the else block in a loop

    loop {
        // region A
        if cond {
            // region B
        } else {
            continue;
        }
        // region C
    }
    

    Here, C can be merged with B and the else block can be thrown away:

    loop {
        // region A
        if cond {
            // region B
            // region C
        }
    }
    

    Case 2: continue is the first/only statement in the if block in a loop

    loop {
        // region A
        if cond {
            continue;
            // potentially more code here.
        } else {
            // region B
        }
        // region C
    }
    

    Here, we can negate the if condition cond and then merge B and C in the if block:

    loop {
        // region A
        if !cond {
            // region B
            // region C
        }
    }
    

    This lint simplifies the negated condition expression by applying comparison operator inversions and de Morgan's laws for logical operations. Maybe this can be moved into a lint by itself.

    [EDIT] I have my own function for indentation trimming because the one in utils did not work for me, and I did not want to change it to break other lints that might be depending on it. Also have a function for aligning code snippets such that the last line of the first snippet aligns with the first line of the second. Maybe we can add this to utils.

    opened by yati-sagade 57
  • Update empty_loop documentation/message.

    Update empty_loop documentation/message.

    Originally part of #6161, but now this PR only deals with std crates

    This change:

    • Updates the std message .
    • Updates the docs to mention how the busy loops should be fixed
      • Gives examples of how to do this for no_std targets
    • Updates the tests/stderr files to test this change.

    changelog: Update empty_loop lint documentation

    S-waiting-on-author 
    opened by josephlr 55
  • trait bounds lint - repeated types

    trait bounds lint - repeated types

    This PR is to tackle https://github.com/rust-lang/rust-clippy/issues/3764 it's still a WIP and doesn't work but this is an initial stab. It builds though I haven't added any tests as I'm not sure where lint tests should go?

    Unfortunately, it seems id isn't tied to the type itself but I guess where it is in the AST? Looking at https://manishearth.github.io/rust-internals-docs/syntax/ast/struct.Ty.html I can't see any members that would let me tell if a type was repeated in multiple trait bounds.

    There may be other issues with how I've implemented this so any assistance is appreciated!

    changelog: Add new lint: type_repetition_in_bounds

    S-waiting-on-review 
    opened by xd009642 52
  • Added restriction lint: pattern-type-mismatch

    Added restriction lint: pattern-type-mismatch

    changelog: Added a new restriction lint pattern-type-mismatch. This lint is especially helpful for beginners learning about the magic behind pattern matching. (This explanation might be worth to include in the next changelog.)

    A-lint S-waiting-on-bors 
    opened by phaylon 51
  • New Lint: `branches_sharing_code`

    New Lint: `branches_sharing_code`

    This lint checks if all if-blocks contain some statements that are the same and can be moved out of the blocks to prevent code duplication. Here is an example:

    let _ = if ... {
        println!("Start"); // <-- Lint for code duplication
        let _a = 99;
        println!("End"); // <-- Lint for code duplication
        false
    } else {
        println!("Start");
        let _b = 17;
        println!("End"); 
        false
    };
    

    This could be written as:

    println!("Start");
    
    let _ = if ... {
        let _a = 99;
        false
    } else {
        let _b = 17;
        false
    };
    
    println!("End"); 
    

    This lint will get masked by the IF_SAME_THEN_ELSE lint. I think it makes more sense to only emit one lint per if block. This means that the folloing example:

    if ... {
        let _a = 17;
    } else {
        let _a = 17;
    }
    

    Will only trigger the IF_SAME_THEN_ELSE lint and not the SHARED_CODE_IN_IF_BLOCKS lint.


    closes: #5234

    changelog: Added a new lint: branches_sharing_code

    And hello to the one that is writing the changelog for this release :D

    S-waiting-on-author 
    opened by xFrednet 49
  • 📌 Pin Clippy to a nightly 📌

    📌 Pin Clippy to a nightly 📌

    changelog: Pin Clippy to a specific nightly version (No more master/custom toolchain required to compile Clippy)

    Addresses partially #5561. As proposed there in this comment, this kicks off the process, to help us get acquainted with how the syncs should work, before working on improving the tooling.

    Open questions:

    • When performing a rustup, we will need to exclude the commits that were merged that same day, or else wait until that nightly is released. I did not update the documentation about this part, mainly because I'm not sure about how to do that.
    • When should we perform the rustups now? My first idea is to do it at the same time we do the clippyups, to have a clear cadence and to avoid the two copies of the repo to diverge enough to make the process painful.
    • Who does the rustups now? If we follow my previous idea and do both rustup and clippyup at the same time, it would be more work for @flip1995 who currently does the clippyups. I would prefer to establish some kind of rotation to spead the work. Other ideas?
    • I'm not sure if this affects the release process in any way.
    • ???

    @rust-lang/clippy thoughts?

    r? @flip1995

    S-waiting-on-review 
    opened by ebroto 47
  • new uninlined_format_args lint to inline explicit arguments

    new uninlined_format_args lint to inline explicit arguments

    Implement https://github.com/rust-lang/rust-clippy/issues/8368 - a new lint to inline format arguments such as print!("{}", var) into print!("{var}").

    Supported cases

    code | suggestion | comment ---|---|--- print!("{}", var) | print!("{var}") | simple variables print!("{0}", var) | print!("{var}") | positional variables print!("{v}", v=var) | print!("{var}") | named variables print!("{0} {0}", var) | print!("{var} {var}") | aliased variables print!("{0:1$}", var, width) | print!("{var:width$}") | width support print!("{0:.1$}", var, prec) | print!("{var:.prec$}") | precision support print!("{:.*}", prec, var) | print!("{var:.prec$}") | asterisk support

    Known Problems

    • There may be a false positive if the format string is wrapped in a macro call:
    # let var = 42;
    macro_rules! no_param_str { () => { "{}" }; }
    macro_rules! pass_through { ($expr:expr) => { $expr }; }
    println!(no_param_str!(), var);
    println!(pass_through!("{}"), var);
    
    • Format string uses an indexed argument that cannot be inlined. Supporting this case requires re-indexing of the format string. Until implemented, print!("{0}={1}", var, 1+2) should be changed to print!("{var}={0}", 1+2) by hand.

    changelog: [uninlined_format_args]: A new lint to inline format arguments, i.e. print!("{}", var) into print!("{var}")

    S-waiting-on-review 
    opened by nyurik 46
  • Enhance `needless_borrow` to consider trait implementations

    Enhance `needless_borrow` to consider trait implementations

    The proposed enhancement causes needless_borrow to suggest removing & from &e when &e is an argument position requiring trait implementations, and e implements the required traits. Example:

    error: the borrowed expression implements the required traits
      --> $DIR/needless_borrow.rs:131:51
       |
    LL |     let _ = std::process::Command::new("ls").args(&["-a", "-l"]).status().unwrap();
       |                                                   ^^^^^^^^^^^^^ help: change this to: `["-a", "-l"]`
    

    r? @Jarcho

    changelog: Enhance needless_borrow to consider trait implementations

    S-waiting-on-review 
    opened by smoelius 45
  • Suggest `Option::map_or`(_else) for `if let Some { y } else { x }`

    Suggest `Option::map_or`(_else) for `if let Some { y } else { x }`

    Fixes #5203

    There are two issues with this code that I have noticed:

    • Use of Option::map_or causes it to always evaluate the code in the else block. If that block is computationally expensive or if it updates some state (such as getting the next value from an iterator), then this change would cause the code to behave differently. In either of those circumstances, it should suggest Option::map_or_else, which takes both cases as a closure and runs one. However, I don't know how to check if the expression would change some state, so I left the lint's applicability as MaybeIncorrect.

    • There are lints which can trigger on specific sub-cases of this lint (if_let_some_result, question_mark, and while_let_loop) and suggest different changes (usually better ones because they're more specific). Is this acceptable for clippy to give multiple suggestions, or should I have the code check if those other lints trigger and then not trigger this lint if they do?

    changelog: Add lint [option_if_let_else]

    S-waiting-on-author 
    opened by JarredAllen 42
  • don't lint field_reassign when field in closure

    don't lint field_reassign when field in closure

    fixes #10136

    This change makes the ContainsName struct visit all interior expressions, which means that ContainsName will return true even if name is used in a closure within expr.

    changelog: [field_reassign_with_default]: fix a false positive where values captured in a closure were not detected as being used.

    E-help-wanted S-waiting-on-review 
    opened by EricWu2003 2
  • [`drop_ref`]: don't lint idiomatic in match arm

    [`drop_ref`]: don't lint idiomatic in match arm

    fixes #10122

    As established in issue #9482, it is idiomatic to use a single drop() expression in a match arm to achieve a side-effect of a function while discarding its output. This should also apply to cases where the function returns a reference.

    The change to the lint's code was less than 1 line, because all the heavy lifting was done in PR #9491.

    changelog: [drop_ref]: Do not lint idiomatic expression in match arm

    S-waiting-on-review 
    opened by EricWu2003 3
  • `field_reassign_with_default` false positive with closure capturing variable that was initialized to default

    `field_reassign_with_default` false positive with closure capturing variable that was initialized to default

    Summary

    The field_reassign_with_default lint performs a check to make sure that the the reassignment does not involve the variable that was initialized with default(), but this check fails if the variable is captured by a closure.

    Lint Name

    field_reassign_with_default

    Reproducer

    I tried this code:

    struct Collection {
        items: Vec<i32>,
        len: usize,
    }
    
    impl Default for Collection {
        fn default() -> Self {
            Self {
                items: vec![1, 2, 3],
                len: 0,
            }
        }
    }
    
    fn main() {
        let mut c = Collection::default();
        c.len = (|| c.items.len())();
    }
    

    I saw this happen:

    warning: field assignment outside of initializer for an instance created with Default::default()
      --> src/main.rs:17:5
       |
    17 |     c.len = (|| c.items.len())();
       |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
       |
    note: consider initializing the variable with `Collection { len: (|| c.items.len())(), ..Default::default() }` and removing relevant reassignments
      --> src/main.rs:16:5
       |
    16 |     let mut c = Collection::default();
       |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
       = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#field_reassign_with_default
       = note: `#[warn(clippy::field_reassign_with_default)]` on by default
    
    

    I expected to see this happen:

    The lint should not trigger since the expression that c.len is being reassigned to involves c, making the suggestion invalid.

    Version

    rustc 1.66.0 (69f9c33d7 2022-12-12)
    binary: rustc
    commit-hash: 69f9c33d71c871fc16ac445211281c6e7a340943
    commit-date: 2022-12-12
    host: x86_64-unknown-linux-gnu
    release: 1.66.0
    LLVM version: 15.0.2
    

    Additional Labels

    @rustbot label +I-suggestion-causes-error

    C-bug I-suggestion-causes-error I-false-positive 
    opened by Johan-Mi 2
Owner
The Rust Programming Language
The Rust Programming Language
fail CI on rustc and clippy warnings without breakage

A crate + github actions template that fails CI on rustc and clippy warnings without breakage.

Lucas Kent 1 Jan 2, 2022
Unwrap Macros to help Clean up code and improve production.

unwrap_helpers Unwrap Macros to help Clean up code and improve production. This does include a pub use of https://github.com/Mrp1Dev/loop_unwrap to ga

Ascending Creations 2 Nov 1, 2021
convert images to ansi or irc, with a bunch of post-processing filters

img2irc (0.2.0) img2irc is a utility which converts images to halfblock irc/ansi art, with a lot of post-processing filters halfblock means that each

null 6 Apr 4, 2023
This CLI will help you improve your typing accuracy and speed

This CLI will help you improve your typing accuracy and speed! Improve your personal bests and look back on your previous records in a graph. All in the convenience of your own terminal!

Mitchel Wijt 8 May 25, 2023
Adapt the screen's color spectrum according to the hour of the day in order to improve your sleep

circadianlight What It Is Circadian Light is a program, currently only working on Linux with X, that controls the color spectrum of your screen accord

null 7 Dec 28, 2022
This repo contains crates that are used to create the micro services and keep shared code in a common place.

MyEmma Helper Crates This repo contains crates that can are reused over different services. These crate are used in projects at MyEmma. But these crat

MyEmma 1 Jan 14, 2022
A statically typed language that can deeply improve the Python ecosystem

The Erg Programming Language This is the main source code repository for Erg. This contains the compiler and documentation. 日本語 | 简体中文 | 繁體中文 Erg can

The Erg Programming Language 2.1k Jan 1, 2023
A common library and set of test cases for transforming OSM tags to lane specifications

osm2lanes See discussion for context. This repo is currently just for starting this experiment. No license chosen yet. Structure data tests.json—tests

A/B Street 29 Nov 16, 2022
Rust File Management CLI is a command-line tool written in Rust that provides essential file management functionalities. Whether you're working with files or directories, this tool simplifies common file operations with ease.

Rust FileOps Rust File Management CLI is a command-line tool written in Rust that provides essential file management functionalities. Whether you're w

Harikesh Ranjan Sinha 5 May 2, 2024
Work in progress NCBI's Common Tree alternative in the terminal

Lomanai Usage lomanai --species 'Mus musculus' --species 'Homo sapiens' #> Mammalia #> ++Rodentia #> | \-Mus musculus #> \+Primates #> \-Homo sapien

Jean Manguy 3 Dec 20, 2022
A library to provide abstractions to access common utilities when developing Dioxus applications.

?? Dioxus Standard Library ?? A platform agnostic library for supercharging your productivity with Dioxus. dioxus-std is a Dioxus standard library tha

Miles Murgaw 5 Nov 9, 2022
Universal Windows library for discovering common render engines functions. Supports DirectX9 (D3D9), DirectX10 (D3D10), DirectX11 (D3D11), DirectX12 (D3D12).

Shroud Universal library for discovering common render engines functions. Supports DirectX9 (D3D9), DirectX10 (D3D10), DirectX11 (D3D11), DirectX12 (D

Chase 6 Dec 10, 2022
A simple common-line interface for ChatGPT API.

heygpt A simple common-line interface for ChatGPT API. ?? Streaming output! ?? One-shot mode to get a quick answer ?? Interactive mode to have a conve

Eric Fu 88 Apr 17, 2023
languagetool-code-comments integrates the LanguageTool API to parse, spell check, and correct the grammar of your code comments!

languagetool-code-comments integrates the LanguageTool API to parse, spell check, and correct the grammar of your code comments! Overview Install MacO

Dustin Blackman 17 Dec 25, 2022
Manage your dotfiles and packages with ease. Define your $HOME as Code 💻 🚀 ✨

EnvHub is a simple tool to manage dotfiles and packages accross multiple machines. Written in Rust, internally it uses nix/homebrew/pkgx/devbox to man

Tsiry Sandratraina 8 Oct 27, 2023
Warp is a blazingly fast, Rust-based terminal that makes you and your team more productive at running, debugging, and deploying code and infrastructure.

Warp is a blazingly fast, Rust-based terminal that makes you and your team more productive at running, debugging, and deploying code and infrastructure.

Warp 10.4k Jan 4, 2023
A Yocto setup and management tool that helps you keep your environment up-to-date and in-sync with your team

yb (Yocto Buddy) yb is designed to make it easy to setup and (perhaps more importantly) keep Yocto environments up-to-date and in-sync with your team.

null 13 Oct 31, 2022
Get your loadshedding schedule in your calendar and never be left in the dark! Open-source, up-to-date, and developer friendly.

Loadshedding schedules in your digital calendar. No apps, no ads, up-to-date, and developer friendly. Get it • Key Features • Using the data • Project

Boyd Kane 117 Apr 26, 2023
Count your code by tokens, types of syntax tree nodes, and patterns in the syntax tree. A tokei/scc/cloc alternative.

tcount (pronounced "tee-count") Count your code by tokens, types of syntax tree nodes, and patterns in the syntax tree. Quick Start Simply run tcount

Adam P. Regasz-Rethy 48 Dec 7, 2022