Tronquer les appels à la méthode

Question

C'est une question subjective car je veux savoir si cela vaut la peine de gémir chez mes collègues pour avoir fait quelque chose que je trouve détestable.

Le problème est qu'un groupe de mes collègues va tronquer les appels de méthode pour s'adapter à une largeur. Nous utilisons tous des ordinateurs portables grand écran capables de gérer de grandes résolutions (le mien est de 1920x1200) et quand il s'agit de déboguer et de lire du code, je trouve beaucoup plus facile de lire des appels de méthode qu'une ligne.

Voici un exemple d'une méthode (comment je le voudrais):

IReallyLongInterfaceName instanceOfInterfaceName = OurContainer.retrieveClass(IReallyLongInterfaceName.class, param1, param2, param3); 

(je déteste l'interface vraiment long/noms de classe ainsi :)

Il semble que cela ne rend bien sur StackOverflow, mais je pense que la plupart d'entre vous savent ce que je veux dire. Quoi qu'il en soit, certains des autres devs font ce qui suit.

IReallyLongInterfaceName instanceOfInterfaceName = OurContainer.retrieveClass(IReallyLongInterfaceName.class, 
                       param1, 
                       param2, 
                       param3); 

Ce qui est le plus facile à lire à la fin de la journée pour vous et je serais déraisonnable de leur demander d'utiliser la première des deux (comme il fait partie de notre standard)?

Answer 1

Peut-être que vous devriez avoir dans le cadre de votre processus de construction standard une sorte de plugin checkstyle qui vérifie exactement ce genre de chose? Si vous avez accepté la norme avec vos collègues, il semble raisonnable de leur demander de s'y tenir.

Personnellement, je trouve le deuxième des deux options plus lisibles, mais c'est juste parce que je n'ai pas un moniteur grand écran;)

Answer 2

Si son exlicitly déclaré dans les sociétés de codage standard d'une méthode est la bonne méthode alors par tous les moyens se plaindre à eux, après tout, ils ne sont pas conformes aux normes de l'entreprise. Si ce n'est pas explicitement déclaré alors je suppose que ce serait un bon moment pour le mettre dans la norme. Une chose à savoir cependant, si vous utilisez un IDE avec autoformatage est qu'il peut prendre sur lui de reformater les méthodes au style 2 lors de son exécution. Donc, même si tout le monde écrit au style 1, il se peut qu'il ne finisse pas par ressembler à ça quand il aura fini.

et comme Phil, je trouve la méthode 2 beaucoup plus lisible, puisque vous pouvez voir tout ce que vous devez voir sans avoir à faire défiler vos yeux sur le côté :)

Answer 3

Je trouve le premier exemple plus lisible en général, mais si il est plus long que certaines limites prédéfinies (120 caractères, pour moi), je casserais les lignes:

IReallyLongInterfaceName instanceOfInterfaceName = 
     OurContainer.retrieveClass(IReallyLongInterfaceName.class, 
            param1, param2, param3); 

Answer 4

Je préfère le deuxième exemple. Même si vous avez des ordinateurs portables à écran large, il se peut que vous n'ayez pas toujours des fenêtres en plein écran ou dans votre IDE vous pouvez avoir beaucoup d'autres panneaux autour de la zone de codage principale qui réduisent la largeur disponible pour l'affichage du code.

Si la ligne ne peut pas s'adapter sans défilement, le défilement vertical est préférable au défilement horizontal. Puisque nous lisons de gauche à droite, le défilement horizontal signifierait aller et venir tout le temps.

Je préfère un paramètre par ligne à la suggestion d'Avi, ce qui est arbitraire pour moi. Si vous répartissez les paramètres sur plusieurs lignes mais en avez plusieurs sur chaque ligne, il est plus difficile de trouver des paramètres particuliers lors de la lecture du code.

Answer 5

Je préfère aussi l'option # 2.Le problème n'est pas seulement à quoi il ressemble à l'écran (et si j'avais 1920 pixels horizontaux, j'aurais beaucoup plus de fenêtres ancrées), c'est comme si j'avais besoin de l'imprimer et de le lire. Les lignes longues s'imprimeront terriblement à partir de la plupart des EDI, tandis que les lignes rompues par un auteur dans le but d'améliorer la lisibilité s'imprimeront bien.

Un autre point est la lisibilité générale. Il y a une raison pour laquelle les magazines et les journaux sont imprimés en colonnes - généralement, la lisibilité du texte (en particulier le texte à l'écran) est améliorée par des lignes plus courtes et une meilleure mise en page/formatage.

Je pense que 80 pourrait être trop arbitraire, mais j'utilise 10pt Consolas, et il me semble être en mesure d'obtenir environ 100 caractères par ligne sur un 8.5" standard page imprimée.

maintenant à la fin de le jour, c'est une guerre sainte, peut-être pas aussi mauvaise que l'endroit où mettre vos accolades, mais c'est là-haut, je vous ai donné ma préférence, mais la vraie question vous revient: quel est le standard de votre entreprise? pour moi comme ils ont standardisé sur l'option # 2, ce qui signifie pour le bien de l'équipe, vous devriez probablement vous y adapter

Answer 6

Je préfère l'option 2, mais optionnellement avec des commentaires pour les paramètres où le nom de la variable n'est pas évident Quand vous avez une fonction sur appel qui demande un tas de paramètres, il peut être assez difficile pour les réviseurs de dire ce que fait le code.

Donc, je le code général comme celui-ci s'il y a plus de 3 paramètres à une fonction donnée:

applyEncryptionParameters(key, 
          certificate, 
          0, // strength - set to 0 to accept default for platform 
          algorithm);