Par exemple, aligné non verticalement:
Name: Hamt
Version: 0.1.0
Cabal-Version: >= 1.2
License: BSD3
Author: Jason Baker
Ou aligné verticalement:
Name: Hamt
Version: 0.1.0
Cabal-Version: >= 1.2
License: BSD3
Author: Jason Baker
Lequel tu préfères, et pourquoi?
Réponses:
Personnellement, je suis d'avis que la deuxième version du code est légèrement plus lisible, mais je ne pense pas que son maintien compense cette lisibilité. Par conséquent, je n'utiliserais la deuxième version de cet exemple que si j'étais assez certain que le code ne changerait pas.
Je préfère un hybride:
Name : Hamt
Version : 0.1.0
Cabal-Version : >= 1.2
License : BSD3
Author : Jason Baker
Ce qui est essentiellement le numéro 2 avec des exceptions pour les lignes occasionnelles qui sont plus longues que les lignes environnantes - pour éviter que la majorité des lignes ne soient trop espacées.
Voici une autre variation pour les mises en page de listes basées sur l'expérience ainsi que sur l'enseignement d'un cours universitaire que j'ai suivi sur l'interaction homme-ordinateur et plusieurs livres que j'ai lus sur la conception (G) UI et la conception graphique. Je l'utilise pour les dialogues, et quand j'ai l'énergie / le temps, pour CSS (pas habituellement pour le code cependant).
Name : Hamt
Version : 0.1.0
Cabal-Version : >= 1.2
License : BSD3
Author : Jason Baker
Comme tous les autres, il a ses avantages et ses inconvénients.
Avantages:
Les inconvénients:
HTH
Je préfère le premier, mais sans les onglets (ce que je suppose que les blancs sont); un seul espace vide à la place. Pour moi, c'est plus facile à lire lorsque les données ne sont pas "similaires", comme dans le cas donné. Il est également plus difficile (lors de la modification de ces données) de "mal lire une ligne", c'est-à-dire lorsque vous avez trois lignes avec, disons, des numéros de version. Et puis lors de l'édition d'un, vous en éditez accidentellement un autre à sa place.
Lorsque les données sont similaires, cependant, il est parfaitement logique de les mettre en colonnes comme dans votre deuxième exemple (seulement, elles ne sont pas similaires, mais vous obtenez le point).
Malheureusement, étant une question de style, c'est très subjectif et vous aurez probablement de nombreux résultats contradictoires. De plus, le style à utiliser dépend fortement de votre utilisation des tabulations ou des espaces.
Quant à mes deux cents, je préfère une variante de la deuxième version. Je préfère ça:
Name : Hamt
Version : 0.1.0
Cabal-Version : >= 1.2
License : BSD3
Author : Jason Baker
C'est la version la plus lisible et la plus facile à utiliser que j'ai essayée. Le seul véritable inconvénient est que je dois comprendre quel est le champ le plus large et parfois finir par les développer tous quand l'un est trop large (cela ne se produit généralement qu'avec CSS). Cependant, il y a quelques points à considérer.
Tout d'abord, je préfère généralement les TAB par opposition aux espaces, mais le paramètre TAB réel varie; par exemple, je suis habitué aux TAB à 4 espaces pour le code C (++) ou HTML et aux TAB à 2 espaces pour le code Pascal ou Assembleur, alors que pour certaines choses comme CSS, je n'ai aucune préférence pour la largeur des TAB. Cette variation complique assez les choses, mais l'éditeur que j'utilise jette ses propres complications. Certains éditeurs vous permettent de définir les paramètres TAB par langue, mais certains ne le font pas (même certains qui ont des profils différents).
Vous pouvez éviter cette complication en renonçant aux TAB au profit des espaces. Étant donné que le code est généralement dans une police à largeur fixe, l'utilisation d'espaces fonctionne très bien, tandis que si vous formatez des champs dans un formulaire, un curriculum vitae ou un autre texte non codé et utilisez une police proportionnelle, vous aurez besoin de TAB pour garder les choses alignées .
Je préfère les TAB en général car même avec du code à largeur fixe, je trouve frustrant d'avoir à parcourir plusieurs espaces pour chaque TAB. Je me souviens que les anciens IDE Borland avaient une option pour faire défiler les TAB (en particulier des longueurs entières d'espaces blancs) en tant qu'entité unique au lieu de deux, quatre, etc. espaces. Cela a rendu pratique l'insertion de TAB en tant qu'espaces tout en facilitant et accélérant la navigation avec le curseur. Malheureusement, je n'ai vu aucun éditeur Windows moderne capable de le faire.
Enfin, le fait que d'autres utilisent ou non votre code joue un rôle important dans le choix du style. Je suis généralement le seul à utiliser mon code, je peux donc tout formater à mon goût sans tenir compte des éditeurs ou des paramètres des autres. Si vous travaillez avec d'autres personnes, vous devrez en tenir compte car elles devront vous considérer.
En résumé, la lisibilité est bonne et très souhaitable, mais les paramètres et les éditeurs que vous et les autres utilisateurs devez utiliser le code seront importants lors de la prise de décision. Si vous êtes seul, vous pouvez tout aussi bien utiliser le format le plus lisible. Vous devrez peut-être vous habituer à l'utiliser, mais cela sera probablement payant à long terme, en particulier lorsque vous devez revenir au code que vous avez écrit il y a quelque temps: la lisibilité est aussi importante que les commentaires pour comprendre ce que fait le code. Si vous travaillez avec d'autres, vous voudrez peut-être travailler ensemble pour définir une sorte de guide de conception à l'usage de l'équipe.
:%s/\([^ ]\) \+/\1 /g