Téléchargement nakedret - Téléchargement du code source nakedret

nakedret

Autres catégories

v2.0.3

Télécharger

nuageux

Nakedret est un outil d'analyse GO statique pour trouver des rendements nus dans des fonctions supérieures à une longueur de fonction spécifiée.

Installation

Installer Nakedred via Go Installer:

go install github.com/alexkohler/nakedret/v2/cmd/nakedret @ latest

Si vous n'avez pas déjà ajouté votre répertoire GOPATH/bin à votre variable d'environnement PATH , vous devrez le faire.

Windows (CMD):

 set PATH = %PATH% ;C:yourGOPATHbin

Bash (vous pouvez vérifier qu'un chemin a été défini):

 # Check if nakedret is on PATH
which nakedret
export PATH= $PATH :/your/GOPATH/bin # to set path if it does not exist

Usage

Semblable à d'autres outils GO static anaylsis (tels que golint , go vet ), Nakedret peut être invoqué avec un ou plusieurs noms de fichiers, répertoires ou packages nommés par son chemin d'importation. Nakedret soutient également le ... Wildcard.

 nakedret [flags] files/directories/packages

Actuellement, le seul indicateur pris en charge est -l, qui est un indicateur numérique facultatif pour spécifier la longueur maximale qu'une fonction peut être (en termes de longueur de ligne). S'il n'est pas spécifié, il est par défaut à 5.

Il peut également être exécuté à l'aide de go vet :

go vet -vettool= $( which nakedret ) ./...

But

Comme indiqué dans la révision du code de GO, commentaires:

Les rendements nus sont corrects si la fonction est une poignée de lignes. Une fois qu'il s'agit d'une fonction de taille moyenne, soyez explicite avec vos valeurs de retour. Corollaire: Cela ne vaut pas la peine de nommer les paramètres de résultat simplement parce qu'il vous permet d'utiliser des rendements nus. La clarté des documents est toujours plus importante que de sauver une ligne ou deux dans votre fonction.

Cet outil vise à assister à des rendements nus sur des fonctions non triviales.

Exemple

Prenons le package types dans la source Go à titre d'exemple:

$ nakedret -l 25 types/
types/check.go:245 checkFiles naked returns on 26 line function 
types/typexpr.go:443 collectParams naked returns on 53 line function 
types/stmt.go:275 caseTypes naked returns on 27 line function 
types/lookup.go:275 MissingMethod naked returns on 39 line function

Vous trouverez ci-dessous l'une des utilisations pas si intuitives des rendements nus dans types/lookup.go

 func MissingMethod ( V Type , T * Interface , static bool ) ( method * Func , wrongType bool ) {
	// fast path for common case
	if T . Empty () {
		return
	}

	// TODO(gri) Consider using method sets here. Might be more efficient.

	if ityp , _ := V . Underlying ().( * Interface ); ityp != nil {
		// TODO(gri) allMethods is sorted - can do this more efficiently
		for _ , m := range T . allMethods {
			_ , obj := lookupMethod ( ityp . allMethods , m . pkg , m . name )
			switch {
			case obj == nil :
				if static {
					return m , false
				}
			case ! Identical ( obj . Type (), m . typ ):
				return m , true
			}
		}
		return
	}

	// A concrete type implements T if it implements all methods of T.
	for _ , m := range T . allMethods {
		obj , _ , _ := lookupFieldOrMethod ( V , false , m . pkg , m . name )

		f , _ := obj .( * Func )
		if f == nil {
			return m , false
		}

		if ! Identical ( f . typ , m . typ ) {
			return m , true
		}
	}

	return
}

FAIRE

Tests unitaires (peut nécessiter un refactorisation pour faire correctement)
La prise en charge de build.Context.UseAllFiles peut être utile pour certains.
Configuration sur l'opportunité d'exécuter ou non sur les fichiers de test
Format vim QuickFix?