Pourquoi pas les deux?
Tout d'abord, «descriptif» et «verbeux» ne sont pas les mêmes. Par exemple, si vous écrivez une boucle assez locale, iest un très bon nom de variable pour la variable de boucle; current_iteration_index, bien que sans doute plus descriptif et certainement plus verbeux, est bien pire et n'ajoute aucune information, car l'utilisation de icomme variable de boucle est à peu près universellement acceptée, et il n'y a pas d'autre sens à icela.
Les bons noms de variables sont descriptifs, en ce sens qu'un programmeur familiarisé avec l'idiome du langage et les conventions de la base de code peut facilement deviner quel est leur rôle, mais ils sont également suffisamment concis pour garder les choses compactes.
La limite de 80 caractères, bien qu'initialement une conséquence des limitations techniques des terminaux de texte des années 1970, est toujours appréciée par beaucoup aujourd'hui, et même s'il existe encore des raisons techniques (longueurs de ligne maximales dans certains protocoles réseau, notamment liés à la messagerie électronique), les raisons les plus impérieuses sont d'ordre psychologique et social. Il s'avère que les longueurs de ligne autour de la marque de 66 caractères rendent l'expérience de lecture la plus confortable pour la prose en langage naturel (la taille de la police ne fait pas de différence, et par conséquent, la taille de l'écran ou du papier non plus); Les limites de ligne de 80 caractères sont assez proches de cela, mais comme la majeure partie d'un morceau de code typique est généralement en retrait d'au moins un ou deux niveaux (ce qui signifie entre 4 et 16 caractères, selon les paramètres d'indentation),
Un autre effet de s'en tenir aux lignes de 80 caractères est que c'est un assez bon indicateur du moment où les choses sont trop compliquées. Les lignes aussi longues sont généralement causées par l'un des éléments suivants:
- Fonctions avec une longue liste d'arguments; ce n'est pas une bonne chose à avoir, car ils entravent la lisibilité et peuvent facilement provoquer des bogues subtils, par exemple lorsque les gens échangent l'ordre des arguments d'une manière que le compilateur n'attrape pas.
- Expressions complexes, souvent trouvées dans les conditions (par exemple
if ((user.isLoggedIn && user.hasPermission(page.getRequiredPermission()) && !user.isBanned) || page.getRequiredPermission() == null)); cela aussi est généralement assez difficile à déchiffrer et le code doit être réécrit en quelque chose de plus structuré. Très probablement, l'expression fait trop et devrait être prise en compte dans une méthode ou une fonction.
- Littéraux longs utilisés dans les appels de fonction ou les expressions, par exemple
print(translate(LANG_EN, LANG_ES, "This is the home page. Feel welcome to click around and see what we have."));. Déplacez le littéral dans une variable ou une constante; il peut toujours dépasser la longueur de la ligne, mais si vous le faites régulièrement, le lecteur peut au moins ignorer en toute sécurité la partie invisible de la ligne, en supposant que seul le reste du littéral suit. Ou mieux encore, déplacez les littéraux hors du code et dans un magasin de données externe (fichier, base de données, etc.).
- Instructions profondément imbriquées, par exemple six niveaux d'
ifinstructions dans une méthode de classe (c'est 32 colonnes d'indentation pour les paramètres typiques). Encore une fois, l'imbrication profonde rend le code complexe et difficile à lire, et devrait être évitée comme la peste - en termes simples, l'imbrication profonde déborde la pile du cerveau humain pendant la lecture.
Tous ces éléments sont en fin de compte des symptômes de choses que vous ne préféreriez pas avoir dans votre base de code à long terme, et l'application de limites de 80 caractères est un moyen agréable et simple qui aide à réduire la complexité et la lisibilité. (Cela ne veut pas dire que vous ne pouvez pas écrire du code parfaitement illisible dans 80 colonnes: les divers concours de code quelque chose d'obscurci sont un contre-exemple clair).