Rubocop Linelength: Comment ignorer les lignes avec des commentaires?

109

En utilisant une application Rails 4, je voudrais que Rubocop ignore les lignes avec des commentaires (juste un commentaire ou du code avec un commentaire de fin de ligne) lors de la vérification si une ligne est trop longue. Y a-t-il un moyen de faire cela?

ruby rubocop

— Twiek
source

198

Il existe un moyen d'ignorer les flics par ligne.

Il existe également un moyen de le faire via le fichier de configuration.

Courir rubocop --auto-gen-config et il générera un fichier que vous pourrez utiliser pour désactiver les infractions.

La commande donne également un indice sur ce qu'il faut faire pour charger ces options.

Ligne par ligne, vous pouvez également activer et désactiver les flics.

# rubocop:disable RuleByName
This is a long line 
# rubocop:enable RuleByName

Vous pouvez également appliquer plusieurs règles à la fois dans votre code.

# rubocop:disable BlockComments, AsciiComments

En utilisant une directive en ligne, la directive devient valide uniquement pour cette ligne, et cela ressemblerait à ceci:

# Thanks to @jnt30 for the comment!
method(argument) # rubocop:disable SomeRule, SomeOtherRule

Vous pouvez en savoir plus sur RuboCop dans son manuel officiel .

Pour trouver tous les noms de règles, il vaut la peine de regarder dans les fichiers de configuration de rubocop

cyberwiz dit - "exécutez rubocop -Dquand j'ai besoin des noms de règle plutôt que de regarder dans la documentation." Mise à jour : il s'agit désormais du comportement par défaut sans l'indicateur.

— vgoff
source

1

Eh bien, les commentaires peuvent expliquer l'écart par rapport à un style qui a été accepté par l'équipe, donc ce n'est pas une mauvaise chose, non? Sinon, vous le placez dans le fichier rubocop.yml, puis ce n'est pas une exception de style acceptée et n'a pas besoin de commentaire. Le commentaire dit "Je voulais faire ça!". Pas mal du tout.

— vgoff

1

les commentaires ne sont pas du code, donc les vérifier est sémantiquement différent et IMO rubocop devrait le traiter de cette façon.

— phoet

2

Les commentaires font partie du code, et lorsque vous traitez du code dans un e-mail ou sur un terminal. Je pense que c'est de mauvais goût de ne pas faire adhérer vos commentaires aux mêmes longueurs de lignes que celles adoptées par "l'équipe" comme code. Ils ne devraient pas perturber le flux simplement parce qu'ils sont des commentaires. Je suis sûr que rubocop ne vérifie rien dans les commentaires, à part les directives, sémantiquement (de manière significative). Il vérifie la longueur des lignes et le style des commentaires. Donc non, il ne cherche pas de sens, il vérifie seulement le style. N'oubliez pas que "les commentaires ne sont pas du code" ne doit pas l'être.

— vgoff

En effet, même la #!/bin/env rubyligne de commentaire est un commentaire, mais un code, et est sémantiquement importante. Les commentaires ne sont pas toujours uniquement des «commentaires».

— vgoff

1

@Twiek y a-t-il quelque chose qui manque dans cette réponse que vous recherchez?

— vgoff

35

Il est possible de définir des modèles d'expression régulière pour ignorer automatiquement certaines lignes rubocop.yml, vous pouvez donc choisir d'ignorer toutes les lignes commençant par un #caractère:

Metrics/LineLength:
  Max: 80
  IgnoredPatterns: ['\A#']

Cela pourrait être amélioré de sorte que les lignes de commentaires "indentées" (c'est-à-dire les espaces suivis d'un #caractère) soient également ignorées, si c'est ce que vous voulez.

Notez que cela ne tient pas compte des lignes de code qui se terminent par un commentaire:

some_code(that_does_something) # This line would NOT be ignored by Rubocop.

— GoBusto
source

9

Vous pouvez développer cette expression rationnelle en incluant des lignes qui peuvent avoir des espaces:IgnorePatterns: ['(\A|\s)#']

— poustovitss

1

Merci @poustovitss. Il y a une faute de frappe: il devrait l'être à la IgnoredPatternsplace IgnorePatterns(il manque la lettre «d»).

— Horacio du

9

Vous pouvez utiliser le commentaire suivant avec rubocop pour ignorer une règle spécifique:

# rubocop:disable Metrics/LineLength
def this_could_be_a_very_long_line_that_extends_forever_into_infinity
end
# rubocop:enable Metrics/LineLength

Vous pouvez également ignorer des fichiers entiers en les ajoutant à .rubocop.yml:

AllCops:
  Exclude:
    - path/to/file.rb

6

Je pense que l'idée de base ici est que vous voulez appliquer la longueur de la ligne, peu importe ce qui se trouve après n caractères. la valeur par défaut à 80 caractères est un culte du fret pour les anciennes fenêtres de terminal qui ne pouvaient contenir que ce nombre de caractères. la seule option que j'ai vue dans le code est une option pour autoriser les URL qui pourraient dépasser la limite de caractères.

vous pouvez ignorer des fichiers entiers , je suppose que ce n'est pas ce que vous recherchez.

— phoet
source

8

De nos jours, l'idée derrière 80 caractères n'est pas tellement "culte du fret" pour le terminal, il y a toujours une raison logique à cela: n'importe qui peut diviser ses fenêtres d'éditeur ou d'IDE comme il le souhaite, et tant qu'elles sont juste plus larges plus de 80 caractères, ils n'auront pas besoin de modifier la largeur ou l'expérience de l'habillage.

— Jason Antman

2

IMO si vous ne disposez pas d'un IDE prenant en charge le soft wrapping, votre outillage n'est pas à jour.

— phoet

8

80 caractères sont également assez lisibles, alors que 40 ou 200 le sont moins, donc c'est aussi une question de convivialité

— Toni Leigh

# 1 "tant qu'ils sont juste plus larges que 80 caractères" 800x600 est plus large que 80 caractères, et vous avez le même problème de visualisation côte à côte 2 fichiers de 80 caractères. C'est absurde et ne s'applique qu'à 1366 res. Avec plus de 1920, le prochain argument sera "Je peux diviser 3, 4 fichiers"

— Andre Figueiredo

1

nous l'avons eu à 80, puis nous l'avons changé en 120. Regarder les relations publiques tout en effectuant la révision du code sur Github dans une vue en écran partagé sur des ordinateurs portables 13 "est devenu un problème. Nous sommes revenus à 80.

— AndreiMotinga