Je viens de commencer à travailler avec Ruby et j'ai découvert des modificateurs de déclaration lorsque la rubymine suggère que je modifie ce code: à ceci: J'aime comment cela rend le code plus succinct. Cependant, je peux le voir potentiellement trompeur à un premier coup d'œil et imposer une question de lisibilité, car elle place l'effet avant la condition. Là encore, peut-être que c'est juste parce que je suis tellement habitué à des langages de style C. a-t-il eu des ennuis à la suite de modifications de la déclaration ou avez-vous l'impression d'avoir amélioré votre code? En outre, quelqu'un a-t-il des directives générales pour l'utilisation des modificateurs (c'est-à-dire qui fonctionne particulièrement bien pour certaines opérations, ou non pour d'autres)?
4 Réponses :
C'est une question de style purement subjectif. Utilisez ce que vous vous sentez à l'aise.
C'était un peu étrange pour moi au début, mais je ne pense pas que cela pose un problème de lisibilité. Lorsque vous travaillez beaucoup de rubis, cela est parfaitement logique. Ce n'est que lorsque je passe en arrière avec d'autres langues qu'il est perceptible. Cependant, lorsque vous vous plongez dans le code Ruby, vous le trouverez une manière propre et succincte d'écrire un conditionnel de ligne. Également, utilisez-vous pour utiliser sauf si . Votre ligne de code pourrait (peut-être devrait) être écrite:
Les modificateurs de déclaration font que Ruby se comporter plus comme l'anglais, qui est gentil:
Je vous conseillerais d'utiliser le formulaire qui semble le plus naturel et élégant pour vous. En cas de doute, lisez la déclaration à haute voix dans les deux formes. Personnellement, j'ai tendance à utiliser uniquement des modificateurs de la déclaration pour de courtes déclarations telles que retour: Nope si entrée.nil? - Pour des déclarations plus longues ou plus compliquées, il peut prendre le lecteur plus longtemps à saisir, car Les yeux ne couvrent qu'une certaine quantité d'espace et que quelqu'un ne lirait que le modificateur de deuxième regard.
Je trouve que je n'ai généralement aucune difficulté à lire ces conditionnels suivants (comme ils sont parfois appelés parfois), à condition que les autres directives de lisibilité du code soient suivies. Mettre une expression de 60 caractères et une condition de 40 caractères sur la même ligne, vous allez vous retrouver avec un gob de texte de 100 caractères, ce qui va sûrement être illisible, totalement indépendant de la question des conditionnels suivis.
Dans l'échantillon de code spécifique que vous affichez, il est presque évident qu'il doit être être un suivi conditionnel. Qui voudrait En outre, les conditionnels de fin sont similaires aux clauses de garde en mathématiques et en langues fonctionnelles, qui ont également tendance à être écrites après l'expression qu'ils protègent.
Dernier point mais non le moindre, mettre un couple de PS: J'utiliserais effectivement Remplacer un ArgumentError Sans même prendre un coup d'oeil aux arguments d'abord?
Soulevez la barre si FOO et renvoie nul si qux expressions au début des méthodes, en tant que gardes, est en fait considérée bon style pour simplifier le flux de contrôle de la méthode. Encore une fois: comme celles-ci arrivent au début de la méthode, il est un peu évident que a est une condition, sinon retourner à partir du début de la méthode t avoir un sens.
à moins que là, pour vous débarrasser de la négation. Avec des conditions plus compliquées, je trouve que sauf si peut parfois être difficile à analyser, mais dans ce cas, il est plus évident, au moins IMHO.