A static code analyzer for annotated TODO comments

todocheck logo

todocheck

todocheck is a static code analyzer for annotated TODO comments.

It let's you create actionable TODOs by annotating them with issues from any of the supported issue trackers.
No longer will you discover arcane, undocumented TODO comments, scattered across your code base.

See How it works for more info.

Table of Contents

How it works

Here's an example of an annotated TODO:

// TODO J123: Fix this typo
func fuu() {
    ...
}

In case the linked issue J123 is open, todocheck will not report any error. In case it is closed or doesn't exist, todocheck will show an error:

ERROR: Issue is closed.
myproject/main.go:12: // TODO J123: Fix this typo

ERROR: Issue doesn't exist.
myproject/main.go:14: // TODO J321: A non-existent issue

If there is an unannotated TODO in your code base, todocheck will also report it as a malformed TODO:

ERROR: Malformed todo.
myproject/main.go:16: // TODO - This is not a valid annotated todo

todocheck demo gif

Only TODOs with valid, open issues are allowed to exist in the codebase.

By integrating todocheck in your development workflow & CI pipeline, you can ensure that there will be no half-baked issue closed with pending TODOs in the codebase.

Installation

Download the binary for your OS from the latest release.

Optionally verify the sha256 checksum:

  • For macos, run shasum -a 256 & verify it's the same as .sha256
  • For linux, run sha256sum
  • For windows, use a SHA256 checksum utility

Afterwards, verify the shasum is the same as .sha256.

Place the binary in a folder, shined upon by your $PATH.

  • For macos & linux, that's typically /usr/local/bin/

Quickstart

First, you need to configure todocheck's integration with your issue tracker. This is done by creating a .todocheck.yaml file in the root of your project.

For public github or gitlab repositories, you don't need to specify a config file, as long as you are using git, as todocheck will interpret your issue tracker from the git configuration.

Alternatively, the explicit configuration for a public github repository would look like this:

origin: github.com/user/repository
issue_tracker: GITHUB

See Supported Issue Trackers for more issue tracker options.

After the config file is in place, simply run todocheck from the root of your project.

In case you are running todocheck from a different directory, you can specify your project's path using the --basepath flag and the project configuration with --config:

$ todocheck --basepath path/to/project --config path/to/config/.todocheck.yaml

If the --config option is not specified, the configuration in the basepath will be used.
In the example above, it would look for it in path/to/project/.todocheck.yaml.

Supported Issue Trackers

Currently, todocheck supports the following issue trackers:

Issue Tracker Description
Github Both public & private repositories are supported
Gitlab Both public & private repositories are supported
Jira Supported via offline tokens
Pivotal Tracker Supported via an API token
Redmine Supports public access with no auth & private access via an API token

Github

To integrate with a public github repository, there's no need to provide a .todocheck.yaml explicitly as it can automatically detect the issue tracker based on the git remote address. And if you want to be explicit, please specify the origin of your repo and the GITHUB issue tracker in your .todocheck.yaml configuration:

origin: github.com/user/repository
issue_tracker: GITHUB

To integrate with a private github repository, you'll also need to specify the auth section with the apitoken type:

origin: github.com/user/repository
issue_tracker: GITHUB
auth:
  type: apitoken

The first time you run the application, it will ask for your personal access token: todocheck Github PAT Prompt

After you've specified it, it will store it in the auth tokens cache for subsequent executions. See the Authentication section for more info.

Gitlab

To integrate with a public gitlab repository, there's no need to provide a .todocheck.yaml explicitly as it can automatically detect the issue tracker based on the git remote address. And if you want to be explicit, please specify the origin of your repo and the GITLAB issue tracker in your .todocheck.yaml configuration:

origin: gitlab.com/user/repository
issue_tracker: GITLAB

To integrate with a private gitlab repository, you'll also need to specify the auth section with the apitoken type:

origin: github.com/user/repository
issue_tracker: GITLAB
auth:
  type: apitoken

The first time you run the application, it will ask for your personal access token:

After you've specified it, it will store it in the auth tokens cache for subsequent executions. See the Authentication section for more info.

Jira

To integrate with your organization's Jira, you'll need to specify JIRA as your issue tracker, the origin of your jira server instance, along with an offline token:

origin: https://myjira.awesomeorg.com
issue_tracker: JIRA
auth:
  type: offline
  offline_url: https://myjira.awesomeorg.com/offline

After you run todocheck for the first time, it will request your offline token: Offline token prompt example

Example offline token page: Offline token page example

After you've given the offline token to todocheck's prompt, it will store it in the auth tokens cache for subsequent executions.

See the Authentication section for more info.

Pivotal Tracker

To integrate with a pivotal tracker project, specify the origin of your project and the PIVOTAL_TRACKER issue tracker in your .todocheck.yaml configuration.
You should also specify the apitoken as an auth type:

origin: pivotaltracker.com/projects/PROJECT_ID
issue_tracker: PIVOTAL_TRACKER
auth:
  type: apitoken

The first time you run the application, it will ask for your API Token.

After you've specified it, it will store it in the auth tokens cache for subsequent executions. See the Authentication section for more info.

Redmine

To integrate with a redmine issue tracker project, specify the origin of your installation (without project path) and the REDMINE issue tracker in your .todocheck.yaml configuration.

You should also specify the apitoken as an auth type if you have authentication enabled on your server:

origin: https://redmine.mycorp.com
issue_tracker: REDMINE
auth:
  type: apitoken

Alternatively, if no authentication is required, don't include the auth section.

The first time you run the application, it will ask for your API Token.

After you've specified it, it will store it in the auth tokens cache for subsequent executions. See the Authentication section for more info.

In order to integrate todocheck with your redmine server, you'll need to enable the server's rest API and, optionally, enable authentication - See Docs.

Supported Programming Languages

Currently, todocheck has parsers for three different types of comments:

  • Standard comments like // and /* */
  • Scripts using single-line comments #
  • Python with its # single-line and """ multi-line comments

Based on this, here are the supported languages:

Supported Languages Description
Bash/Zsh *.sh/*.bash/*.zsh extension. Supports # single-line comments
C *.c extension. Supports single-line // comments and multi-line /* */ comments
C++ *.cpp extension. Supports single-line // comments and multi-line /* */ comments
CSharp *.cs extension. Supports single-line // comments and multi-line /* */ comments
Golang *.go extension. Supports single-line // comments and multi-line /* */ comments
Groovy *.groovy, *.gvy, *.gy, *.gsh extensions. Supports single-line // comments and multi-line /* */ comments
Java *.java extension. Supports single-line // comments and multi-line /* */ comments
JavaScript/Typescript *.js/*.ts extension. Supports single-line // comments and multi-line /* */ comments
PHP *.php extension. Supports single-line # and // comments and multi-line /* */ comments
Python *.py extension. Supports single-line # comments and multi-line """ comments
R *.R extension. Supports single-line // comments and multi-line /* */ comments
Rust *.rs extension. Supports single-line // comments and multi-line /* */ comments
Scala *.scala, *.sc extensions. Supports single-line // comments and multi-line /* */ comments
Swift *.swift extension. Supports single-line // comments and multi-line /* */ comments

If you don't see your favorite language in this table, but it does use one of the supported comment formats, submit an issue here

Ignored Files & Directories

If you want certain project files not to be included for todocheck processing, you can specify that in an ignored section in the .todocheck.yaml configuration:

origin: some.origin.com
issue_tracker: JIRA
ignored:
  - vendor-folder/
  - scripts/*.sh

Ignored files/folders can be specified via standard pattern-matching. Hidden files (dotfiles, i.e. .git, .gitignore, etc) are ignored by default.

Custom Todos

By default, todocheck looks for todos in the format // TODO 231: ... Most projects stick to this format.

However, if you have some special todo format, which is different from the default one, you can specify a list of custom todo formats in your .todocheck.yaml

origin: some.origin.com
issue_tracker: JIRA
custom_todos:
  - "@fix"
  - ToDo

Note that this list adds additional formats the tool should match, but doesn't substitute the default one - TODO.

With the above configuration, todocheck will start matching todo comments in the following formats:

// @fix 234: a leftover task...
// ToDo 15: A funky-looking todo comment

Supported Output Formats

Currently, todocheck supports two kinds of output - standard & json.

The standard format is meant to be user-friendly & used in the normal day-to-day workflow.

ERROR: Malformed todo
tmp/main.groovy:2: // TODO: Invalid todo
        > TODO should match pattern - TODO {task_id}:

ERROR: Malformed todo
tmp/main.groovy:12: // TODO: Invalid todo
        > TODO should match pattern - TODO {task_id}:

ERROR: Issue doesn't exist
tmp/main.groovy:15: // TODO 3: A non-existent issue

The json output is meant to be used for integrating todocheck in third-party systems, such as an IDE plugin.
To use json output, use the --format json flag.

[
   {
      "type":"Malformed todo",
      "filename":"tmp/main.groovy",
      "line":2,
      "message":"TODO should match pattern - TODO {task_id}:"
   },
   {
      "type":"Malformed todo",
      "filename":"tmp/main.groovy",
      "line":12,
      "message":"TODO should match pattern - TODO {task_id}:"
   },
   {
      "type":"Issue doesn't exist",
      "filename":"tmp/main.groovy",
      "line":15,
      "message":""
   }
]

Authentication

None

For public repositories, todocheck requires no authentication as the issues in the issue tracker are publicly available. In this case, you need not specify any auth section in your configuration or explicitly set it as none:

origin: github.com/user/repository
issue_tracker: GITHUB
auth: 
  type: none

API Token/Offline Token

For private repositories, todocheck requires an authentication token which the user specifies via a secure prompt.

For github & gitlab, there is a personal access token one can get in his user settings & todocheck can use that to read your repository's issues. Github docs Gitlab docs

To use this authentication type, configure the auth type as apitoken:

origin: github.com/user/repository
issue_tracker: GITHUB
auth: 
  type: apitoken

For Jira, you'll need to specify an offline token:

origin: https://myjira.awesomeorg.com
issue_tracker: JIRA
auth:
  type: offline
  offline_url: https://myjira.awesomeorg.com/offline

An offline token is one which your user can get by accessing a specific page, where your server generates an access token.

Example offline token page: Offline token page example

After you've received either an api token (github/gitlab) or an offline token, you can paste it in todocheck's secure prompt when asked.
Example with github PAT prompt: todocheck Github PAT Prompt

Afterwards, todocheck will not ask for your token again as it will store it in its tokens cache.

Authentication Tokens Cache

Whenever a user grants todocheck an auth token, the token will be stored in a file ~/.todocheck/authtokens.yaml.

If that file doesn't already exist, it will be created with read/write permissions for current user only (permission 0700).

This file stores a key-value mapping of project origin to auth token.
Whenever todocheck runs, it first checks this file for an existing authentication token before contacting the issue tracker's server.

If you want to specify a different tokens cache, you can set the tokens_cache section in your .todocheck.yaml configuration:

# remainder omitted
auth:
  # remainder omitted
  tokens_cache: path/to/tokens_cache

Auth Token via Environment Variable

If you need to pass an authentication token via an environment variable, use the TODOCHECK_AUTH_TOKEN environment variable.

Example usage:

TODOCHECK_AUTH_TOKEN= todocheck --basepath path/to/project

This can be useful when you want to integrate todocheck in your CI pipeline.

Configuration

In your .todocheck.yaml configuration, you have the following configuration options:

  • origin - the origin of your remote repository/issue tracker (example: github.com/golang/go)
  • issue_tracker - the issue tracker type you're using. Possible options - GITHUB, GITLAB, JIRA
  • ignored - a list of directories/files todocheck should ignore. Supports pattern-macthing, e.g. *.sh.
  • custom_todos - a list of custom todos variables. TODO will always be added. (example: "@fix")
  • auth - the authentication configuration for your issue tracker. If not present, it defaults to auth type: none
    • type - the type of authentication. Possible options - none (default), offline, apitokenA
    • offline_url - the url for fetching offline tokens. Only used when type is offline
    • tokens_cache - the location of your auth tokens cache. Defaults to ~/.todocheck/authtokens.yaml

In your tokens cache (default: ~/.todocheck/authtokens.yaml), authentication tokens are stored in the following format:

tokens:
  github.com/user1/repo1: SECRET_TOKEN_1
  gitlab.com/user2/repo2: SECRET_TOKEN_2
  https://jira.awesomeorg.com/offline: SECRET_TOKEN_3

If you'd like to explicitly specify an access token in this file, feel free to do so. This will let the user not have to manually input the token on the first todocheck execution.

This can be used e.g. in a CI environment, in an initial laptop setup script, etc.
Alternatively, use an Auth Token via Environment Variable

Contributing

If you want to report an issue, make improvement suggestions or open a pull request, refer to the Contributing guide

Special thanks to all the project's contributors!

Owner
Preslav Mihaylov
Java/Go Software Engineer at Uber. Long-time technical trainer, speaker & consultant. 🇧🇬
Preslav Mihaylov
Comments
  • Link to Jira documentation where explain how to create offline token

    Link to Jira documentation where explain how to create offline token

    Hi. I am trying to connect offline authorization in Jira. For this I use https://developer.atlassian.com/cloud/jira/service-desk/oauth-2-authorization-code-grants-3lo-for-apps But the resulting token does not work. Can you tell me how to generate the required token correctly? Or give me a link to the documentation that was used. Thank you!

  • Check access to GitHub repo on issuetracker initialization

    Check access to GitHub repo on issuetracker initialization

    This PR closes #62 by making a quick request to the Github repo to ensure the user has access. If a 404 is returned, we log the output and exit early!

  • Self-Hosted Gitlab with API-Token: 401 Unauthorized

    Self-Hosted Gitlab with API-Token: 401 Unauthorized

    When I try to run todocheck on our private gitlab instance (13.2.3), I get the following failed result:

    $ export TODOCHECK_AUTH_TOKEN=[MY-PERSONAL-ACCESS-TOKEN]
    $ ~/Schreibtisch/todocheck-0.2.0-linux-x86_64 --config .todocheck.yaml --basepath src/
    2020/08/14 17:08:05 couldn't traverse basepath: failed traversing file src/Some/Example/File.php: couldn't check todo line: couldn't fetch task status: bad status code upon fetching task: 401 - {"message":"401 Unauthorized"}
    $ 
    

    When I try to manually fetch the issue-details from the gitlab-API using curl, I get this successful result:

    $ curl --header "PRIVATE-TOKEN: [MY-PERSONAL-ACCESS-TOKEN]" "https://our-gitlab-instance.com/api/v4/projects/3/issues/1"
    {"id":16,"iid":1,"project_id":3,"title":"Some Title","description":"Lorem ipsum dolor sit amet.","state":"opened","created_at":"2020-08-14T14:47:36.336Z","updated_at":"2020-08-14T14:47:36.336Z","closed_at":null,"closed_by":null,"labels":[],"milestone":null,"assignees":[],"author":{"id":6,"name":"Gerrit Addiks","username":"gerrit","state":"active","avatar_url":"https://our-gitlab-instance.com/uploads/-/system/user/avatar/6/avatar.png","web_url":"https://our-gitlab-instance.com/gerrit"},"assignee":null,"user_notes_count":0,"merge_requests_count":0,"upvotes":0,"downvotes":0,"due_date":null,"confidential":false,"discussion_locked":null,"web_url":"https://our-gitlab-instance.com/foo/bar/-/issues/1","time_stats":{"time_estimate":0,"total_time_spent":0,"human_time_estimate":null,"human_total_time_spent":null},"task_completion_status":{"count":0,"completed_count":0},"has_tasks":false,"_links":{"self":"https://our-gitlab-instance.com/api/v4/projects/3/issues/1","notes":"https://our-gitlab-instance.com/api/v4/projects/3/issues/1/notes","award_emoji":"https://our-gitlab-instance.com/api/v4/projects/3/issues/1/award_emoji","project":"https://our-gitlab-instance.com/api/v4/projects/3"},"references":{"short":"#1","relative":"#1","full":"foo/bar#1"},"subscribed":true,"moved_to_id":null}
    $
    

    My .todocheck.yaml file:

    origin: https://our-gitlab-instance.com/foo/bar
    issue_tracker: GITLAB
    auth:
      type: apitoken
    

    Why is todocheck unable to fetch the issue while curl can, using the same access-token? Is there maybe some way to enable debugging and/or to see what exact HTTP(S) requests are being sent?

  • Authentication to selfhosted jira v8.20.11 fails

    Authentication to selfhosted jira v8.20.11 fails

    Used config:

    origin: <jira_url>
    issue_tracker: JIRA
    auth:
      type: apitoken
      options:
        username: <username>
    

    Auth token is parsed via environment variable:

    TODOCHECK_AUTH_TOKEN=MY_TOKEN todocheck -verbose
    

    Todo comment:

        # TODO RDPHOEN-1359: Unfreeze meta-openembedded after patch apply on cryptsetup has been fixed.
    

    Error:

    couldn't check todo line: couldn't fetch task status: bad status code upon fetching task: 403
    

    User is definitely allowed access to the said issue. Am I doing something wrong or is Jira integration currently broken? Can someone confirm?

  • Added flag verbose and passed its value deeper by #95

    Added flag verbose and passed its value deeper by #95

    Added flag --verbose with default false value. Its value passed to Traverser constructor and deeper to comments Traverser.

    Maybe it is necessary to extend the displayed lines when the verbose is enabled? For example, all processed files or all files where TODO strings are found?

    Closed #95

  • Show an error if auth type is incorrect

    Show an error if auth type is incorrect

    Here's the error I get when the provided auth type in .todocheck.yaml is incorrect: image

    This happens because there is a check for it in one of the components using the config. It would be more appropriate to validate against this in the config.Validate function instead and show an error message to the user in a normal fashion, rather than relying on a panic, which happens afterwards.

  • Return an error if github repository is not found or private

    Return an error if github repository is not found or private

    Currently, if someone specifies a valid private github repository without an apitoken, todocheck won't report any error but will instead report all linked issues in TODOs as not found.

    The reason is that Github returns status code 404 Not Found instead of 403 Unauthorized when querying private repositories for privacy/security reasons.

    In this situation, it takes quite a while to find out what the issue is until you realize you haven't specified the apitoken in your configuration.

    It would be helpful for todocheck to do the following request upon initializing the configuration:

    curl https://api.github.com/repos/{user}/{repo}
    

    If this request returns 200, the repository exists. If it returns 404, it might not exist OR is private.

    Create a on-initialize hook for issuetrackers, which can do arbitrary checks. For github, this is the check to do. If it doesn't pass AND there is no auth token specified, print the error message & exit:

    Github repository %s not found. Are you accessing a private repository without a token?
    
  • Support for non-uppercase todo's

    Support for non-uppercase todo's

    Currently the todochecker can only detect a todo if it is written all uppercase (like # TODO: Lorem ipsum ...). In some cases the todo may not br written in all uppercase but a different casing like all lowercase (which is sometimes common for annotations: /** @todo: Lorem ipsum ... */ or camelcase: # ToDo: Lorem ipsum .... These other casings are currently not detected by todocheck. This means that there are still quite a few todo's in our codebase that have gone unnoticed, and developers can still add todo's without writing an issue just by changing the casing.

    Would it be possible to change the detection logic so that the casing (uppercase / lowercase) are no longer relevant?

  • [WIP] Fix JSON output for closed-issue type comments not including TODO message

    [WIP] Fix JSON output for closed-issue type comments not including TODO message

    Reopened the PR due to duplicate commits in the old PR.

    The output for single line comments currently looks good:

    {
      "type": "Issue doesn't exist",
      "filename": "testing/scenarios/custom_todos/groovy/main.groovy",
      "line": 21,
      "message": "// TODO 3: The issue is non-existent",
      "metadata": {
        "issueID": "3"
      }
    },
    

    but the output for multiline looks a little odd.

    {
      "type": "Issue doesn't exist",
      "filename": "testing/scenarios/custom_todos/groovy/main.groovy",
      "line": 56,
      "message": "/**\u0000* TODO 2: Invalid todo as issue is closed\u0000*/",
      "metadata": {
        "issueID": "2"
      }
    },
    
  • Need add support for VueJS files

    Need add support for VueJS files

    VueJS have one-file components with file extension .vue. One-file components contains html, javascript and css.

    JS have standard comments and .js is supported by todomatcher:

    // oneline comment
    /*
    multiline comment
    */
    

    With preprocessors html and css can have different syntaxes 😞 https://vue-loader.vuejs.org/guide/pre-processors.html But it can be parsed as defualt html and css comments:

    <!-- HTML oneline and multiline comments -->
    
    /* CSS oneline and multiline comments */
    
  • Added unit tests for fetcher, checker and matchers packages

    Added unit tests for fetcher, checker and matchers packages

    As issue #173 is pretty broad I decided to first work on part of it.

    Did slight refactoring in fetcher.go for easier testing and added tests for all possible errors in Fetch()

    Checker now accepts interface of type Fetcher for easier mocking. Added tests for all possible errors in Check()

    Added tests for all 3 functions in matchers.go. Tests use supportedMatchers for test cases so updating supportedMatchers should update tests.

    go test -cover now shows 100% for these 3 files

  • Remove support for offline tokens

    Remove support for offline tokens

    This feature was added for a very specific case of a JIRA deployment at my previous job, which is obsolete now & it serves no purpose anymore, neither is it understandable in the README.

  • Question: Add option for declaring language within file

    Question: Add option for declaring language within file

    :wave:

    I am considering adding support for bitbake, however some of the file extensions used by bitbake are quite ambiguous, such as *.class, *.inc, which might collide with other languages added in the future. As such I propose adding support for declaring the language within a comment within the scanned file, e.g.: # todockeck-lang=bitbake for such cases.

    Is this something you would feel comfortable with @preslavmihaylov?

  • Add support for SuperCollider code TODO scanning

    Add support for SuperCollider code TODO scanning

    The SuperCollider programming language uses C-style // single line comments and /* */ block comments, with the only possible wrinkle being that it allows block comment nesting, meaning the expression:

    /* Outer block
      /* Inner block */
     */ 
    

    Is valid SuperCollider code. SuperCollider uses the .sc and .scd file extensions.

  • Increase unit test coverage

    Increase unit test coverage

    In order to submit this project for some of the curated go projects, we'll need to ensure a decent code coverage report. Currently, we don't have one since our integration tests are setup in a way that they test the application as a blackbox, which prevents us from having code coverage.

    I'll welcome any PR which adds a new unit test & increases the code coverage.

  • [Hacktoberfest] Add support for new programming languages

    [Hacktoberfest] Add support for new programming languages

    Find opportunities for extending support for programming languages which todocheck doesn't support. If need be, implement support for new comment matchers. Otherwise, reuse some of the existing ones.

Analyzer: zapvet is static analysis tool for zap

zapvet zapvet is static analysis tool for zap. fieldtype: fieldtype finds confliction type of field Install You can get zapvet by go install command (

Sep 18, 2022
Go-perfguard - A static analyzer with emphasis on performance

perfguard This tool is a work in progress. It's not production-ready yet. perfgu

Dec 28, 2022
A Golang tool that does static analysis, unit testing, code review and generate code quality report.
A Golang tool that does static analysis, unit testing, code review and generate code quality report.

goreporter A Golang tool that does static analysis, unit testing, code review and generate code quality report. This is a tool that concurrently runs

Jan 8, 2023
misspelled word linter for Go comments, string literals and embedded files

gospel The gospel program lints Go source files for misspellings in comments, strings and embedded files. It uses hunspell to identify misspellings an

Aug 6, 2022
Analyzer: debugcode finds debug codes

debugcode debugcode finds debug codes. builtinprint: finds calling builtin print or println. commentout: finds a commented out debug code without reas

Aug 16, 2021
gostatement is an analyzer checking for occurrence of `go` statements

gostatement gostatement is an analyzer checking for occurrence of go statements. You may want to use a custom func wrapping the statement utilizing re

Nov 4, 2021
octocov is a tool for collecting code metrics (code coverage, code to test ratio and test execution time).

octocov is a tool for collecting code metrics (code coverage, code to test ratio and test execution time).

Jan 9, 2023
This static analysis tool works to ensure your program's data flow does not spill beyond its banks.

Go Flow Levee This static analysis tool works to ensure your program's data flow does not spill beyond its banks. An input program's data flow is expl

Dec 1, 2022
GoKart - Go Security Static Analysis
 GoKart - Go Security Static Analysis

GoKart is a static analysis tool for Go that finds vulnerabilities using the SSA (single static assignment) form of Go source code.

Jan 1, 2023
Retnilnil is a static analysis tool to detect `return nil, nil`

retnilnil retnilnil is a static analysis tool for Golang that detects return nil, nil in functions with (*T, error) as the return type. func f() (*T,

Jun 9, 2022
The most opinionated Go source code linter for code audit.
The most opinionated Go source code linter for code audit.

go-critic Highly extensible Go source code linter providing checks currently missing from other linters. There is never too much static code analysis.

Jan 6, 2023
🐶 Automated code review tool integrated with any code analysis tools regardless of programming language
🐶 Automated code review tool integrated with any code analysis tools regardless of programming language

reviewdog - A code review dog who keeps your codebase healthy. reviewdog provides a way to post review comments to code hosting service, such as GitHu

Jan 2, 2023
Sloc, Cloc and Code: scc is a very fast accurate code counter with complexity calculations and COCOMO estimates written in pure Go
Sloc, Cloc and Code: scc is a very fast accurate code counter with complexity calculations and COCOMO estimates written in pure Go

Sloc Cloc and Code (scc) A tool similar to cloc, sloccount and tokei. For counting physical the lines of code, blank lines, comment lines, and physica

Jan 4, 2023
🐶 Automated code review tool integrated with any code analysis tools regardless of programming language
🐶 Automated code review tool integrated with any code analysis tools regardless of programming language

reviewdog - A code review dog who keeps your codebase healthy. reviewdog provides a way to post review comments to code hosting service, such as GitHu

Jan 7, 2023
a tool for code clone detection

dupl dupl is a tool written in Go for finding code clones. So far it can find clones only in the Go source files. The method uses suffix tree for seri

Dec 12, 2022
[mirror] This is a linter for Go source code.

Golint is a linter for Go source code. Installation Golint requires a supported release of Go. go get -u golang.org/x/lint/golint To find out where g

Dec 23, 2022
Run linters from Go code -

Lint - run linters from Go Lint makes it easy to run linters from Go code. This allows lint checks to be part of a regular go build + go test workflow

Sep 27, 2022
depth is tool to retrieve and visualize Go source code dependency trees.

depth is tool to retrieve and visualize Go source code dependency trees. Install Download the appropriate binary for your platform from the Rele

Dec 30, 2022
A reference for the Go community that covers the fundamentals of writing clean code and discusses concrete refactoring examples specific to Go.

A reference for the Go community that covers the fundamentals of writing clean code and discusses concrete refactoring examples specific to Go.

Jan 1, 2023