https://github.com/Quasilyte/go-namecheck

Source code analyzer that helps you to maintain variable/field naming conventions inside your project.
https://github.com/Quasilyte/go-namecheck

consistency consistency-checking conventions go golang linter manifest source-code-analysis

Last synced: about 1 month ago
JSON representation

Source code analyzer that helps you to maintain variable/field naming conventions inside your project.

• Host: GitHub
• URL: https://github.com/Quasilyte/go-namecheck
• Owner: quasilyte
• License: mit
• Created: 2018-10-27T09:44:25.000Z (over 5 years ago)
• Default Branch: master
• Last Pushed: 2019-05-30T08:32:00.000Z (about 5 years ago)
• Last Synced: 2024-04-30T07:19:34.654Z (about 2 months ago)
• Topics: consistency, consistency-checking, conventions, go, golang, linter, manifest, source-code-analysis
• Language: Go
• Homepage:
• Size: 15.6 KB
• Stars: 37
• Watchers: 6
• Forks: 0
• Open Issues: 4
• Metadata Files:
  • Readme: README.md
  • License: LICENSE

Lists

• awesome-go-linters - go-namecheck - source code analyzer that helps you to maintain variable/field naming conventions inside your project. (Linters / Style and Patterns Checking)

README

        
# go-namecheck

Source code analyzer that helps you to maintain variable/field naming conventions inside your project.

## Quick start / Installation

To install `go-namecheck` binary under your `$(go env GOPATH)/bin`:

```bash

go get -v github.com/quasilyte/go-namecheck

```

If `$GOPATH/bin` is under your system `$PATH`, `go-namecheck` command should be available after that.


This should print the help message:

```bash

go-namecheck --help

```

In big teams, same things end up being called differently eventually.

Sometimes you bring inconsistencies on your own.

Suppose it's considered idiomatic to call `string` parameter `s` if

you can't figure a more descriptive name, but sometimes you see `str`

names used by other programmers from your team.

This is where `go-namecheck` can help.

For a better illustration, suppose we also want to catch regexp

variables that use `re` prefix and propose `RE` suffix instead,

so `var reFoo *regexp.Regexp` becomes `var fooRE *regexp.Regexp`.

```json

{

  "string": {"param": {"str": "s"}},

  "regexp\\.Regexp": {

    "local+global": {"^re[A-Z]\\w*$": "use RE suffix instead of re prefix"}

  }

}

```

Rules above implement checks we described.

First key describes regular expression that matches a type.

For that key there is an object for scopes.

Scope can be one of:

* `param` - function input params

* `receiver` - method receiver

* `global` - any global constant or variable

* `local` - any local constant or variable

* `field` - struct field

You can combine several scopes like `param+receiver+local`, etc.

Inside a scope there is an JSON object that maps "from" => "to" pair.

In the simplest form, it's a simple literal matching that suggests

to replace one name with another, like in `str`=>`s` rule.

Key can also be a regular expression, in this case, the "to" part

does not describe exact substitution, but rather describes

how to make name idiomatic (what to change).

You start by creating your rules file (or borrowing someone else set).

Then you can run `go-namecheck` like this:

```bash

go-namecheck foo.go bar.go mypkg

```

You can also use `std`, `./...` and other conventional targets that are normally

understood by Go tools.