sloglint
v0.7.2
Un go linter qui garantit un style de code cohérent lors de l'utilisation log/slog .
L'API log/slog permet deux types d'arguments différents: paires et attributs de valeur clé. Bien que les gens puissent avoir des opinions différentes sur laquelle est la meilleure, la plupart semblent s'entendre sur une chose: cela devrait être cohérent. Avec sloglint , vous pouvez appliquer diverses règles de log/slog en fonction de votre style de code préféré.
sloglint est intégré à golangci-lint , et c'est le moyen recommandé de l'utiliser.
Pour activer le linter, ajoutez les lignes suivantes à .golangci.yml :
linters :
enable :
- sloglint Alternativement, vous pouvez télécharger un binaire prédéfini à partir de la page des versions pour utiliser sloglint autonome.
Exécutez golangci-lint avec sloglint activé. Voir la liste des options disponibles pour configurer le linter.
Lorsque vous utilisez sloglint autonome, passez les options sous forme de drapeaux du même nom.
L'option no-mixed-args amène sloglint à signaler des paires et des attributs de valeurs clés de mélange dans un seul appel de fonction:
slog . Info ( "a user has logged in" , "user_id" , 42 , slog . String ( "ip_address" , "192.0.2.0" )) // sloglint: key-value pairs and attributes should not be mixedIl est activé par défaut.
L'option kv-only fait que sloglint signale toute utilisation des attributs:
slog . Info ( "a user has logged in" , slog . Int ( "user_id" , 42 )) // sloglint: attributes should not be used En revanche, l'option attr-only fait que sloglint signale toute utilisation des paires de valeurs clés:
slog . Info ( "a user has logged in" , "user_id" , 42 ) // sloglint: key-value pairs should not be used Certains projets préfèrent transmettre les journalistes en tant que dépendances explicites. L'option no-global fait que sloglint rapporte l'utilisation des journalistes globaux.
slog . Info ( "a user has logged in" , "user_id" , 42 ) // sloglint: global logger should not be used Les valeurs possibles sont all (signaler tous les journalistes globaux) et default (signaler uniquement le journal slog par défaut).
Certaines implémentations slog.Handler utilisent le context.Context donné.Context (par exemple pour accéder aux valeurs de contexte). Pour qu'ils fonctionnent correctement, vous devez transmettre un contexte à tous les appels d'enregistrement. L'option context-only fait que sloglint rapporte l'utilisation des méthodes sans contexte:
slog . Info ( "a user has logged in" ) // sloglint: InfoContext should be used instead Les valeurs possibles sont all (signaler tous les appels sans contexte) et scope (signaler uniquement si un contexte existe dans la portée de la fonction la plus externe).
Pour tirer le meilleur parti de la journalisation structurée, vous voudrez peut-être exiger que les messages de journal soient statiques. L'option static-msg fait que sloglint signale les messages non statiques:
slog . Info ( fmt . Sprintf ( "a user with id %d has logged in" , 42 )) // sloglint: message should be a string literal or a constantLe rapport peut être corrigé en déplaçant les valeurs dynamiques aux arguments:
slog . Info ( "a user has logged in" , "user_id" , 42 ) Pour éviter les fautes de frappe, vous voudrez peut-être interdire l'utilisation des clés brutes. L'option no-raw-keys fait que sloglint rapporte l'utilisation des chaînes comme clés (y compris les appels slog.Attr , par exemple slog.Int("user_id", 42) ):
slog . Info ( "a user has logged in" , "user_id" , 42 ) // sloglint: raw keys should not be usedCe rapport peut être corrigé en utilisant l'une ou l'autre des constantes ...
const UserId = "user_id"
slog . Info ( "a user has logged in" , UserId , 42 ) ... ou constructeurs slog.Attr personnalisés:
func UserId ( value int ) slog. Attr { return slog . Int ( "user_id" , value ) }
slog . Info ( "a user has logged in" , UserId ( 42 ))Conseil
Ces aides peuvent être générés automatiquement pour vous par l'outil sloggen . Essayez aussi!
Pour garantir la cohérence des journaux, vous souhaiterez peut-être appliquer une seule convention de dénomination clé. L'option key-naming-case fait que sloglint rapporte des clés écrites dans un cas autre que celle donnée:
slog . Info ( "a user has logged in" , "user-id" , 42 ) // sloglint: keys should be written in snake_case Les valeurs possibles sont snake , kebab , camel ou pascal .
Pour éviter l'utilisation accidentelle des clés de journal réservées, vous voudrez peut-être interdire complètement des clés spécifiques. L'option forbidden-keys amène sloglint à signaler l'utilisation de clés interdites:
slog . Info ( "a user has logged in" , "reserved" , 42 ) // sloglint: "reserved" key is forbidden and should not be used Par exemple, lorsque vous utilisez la standard slog.JSONHandler et slog.TextHandler , vous voudrez peut-être interdire les clés de time , level , msg et source , car celles-ci sont utilisées par les gestionnaires.
Pour améliorer la lisibilité du code, vous voudrez peut-être mettre des arguments sur des lignes distinctes, en particulier lorsque vous utilisez des paires de valeurs clés. L'option args-on-sep-lines amène sloglint à signaler 2+ arguments sur la même ligne:
slog . Info ( "a user has logged in" , "user_id" , 42 , "ip_address" , "192.0.2.0" ) // sloglint: arguments should be put on separate linesCe rapport peut être corrigé en reformant le code:
slog . Info ( "a user has logged in" ,
"user_id" , 42 ,
"ip_address" , "192.0.2.0" ,
)
