Pourquoi la verbosité est-elle mauvaise pour un langage de programmation? [fermé]


98

J'ai vu beaucoup de gens se plaindre de la verbosité dans les langages de programmation. Je trouve que, dans certaines limites, plus un langage de programmation est bavard, mieux il le comprend. Je pense que cette verbosité renforce également l’écriture APIpour une langue plus claire .

Le seul inconvénient auquel je puisse penser est que cela vous oblige à taper plus, mais je veux dire, la plupart des gens utilisent des IDE qui font tout le travail à votre place.

Alors, quels sont les inconvénients possibles d'un langage de programmation prolixe?


20
Avez-vous codé dans APL récemment?
SK-logic

5
Découvrez Langages, Verbosity et Java par Dhanji R. Prasanna
Jeremy Heiler

67
"Un développeur ne possède qu'un certain nombre de frappes au clavier avant de mourir"
CamelBlues

10
Peut-être devriez-vous demander aux "nombreuses personnes qui se plaignent" quelles sont leurs raisons.
Eric Lippert

29
@ EricLippert, je pense que P.SE est le lieu idéal pour interroger un grand nombre de développeurs "en plainte".
Kevin McCormick

Réponses:


168

Le but est une compréhension rapide

"Verbose" signifie "utilise trop de mots". La question est de savoir ce qu'est "trop".

Un bon code doit être facile à comprendre d'un coup d'œil. Cela est plus facile si la plupart des caractères servent directement l’objet du code .

Signal vs bruit

Si une langue est commentée, votre code est principalement constitué de bruit. Comparez le "Hello World" de Java :

class HelloWorldApp {
    public static void main(String[] args) {
        System.out.println("Hello World!");
    }
}

... avec Ruby:

print "Hello World!"

Le bruit gaspille l'énergie mentale.

Cryptic vs Clear

D'un autre côté, la rareté excessive d'une langue coûte aussi de l'énergie mentale. Comparez ces deux exemples de Common Lisp :

(car '(1 2 3))   # 3 characters whose meaning must be memorized
# vs
(first '(1 2 3)) # 5 characters whose meaning is obvious

20
Je dirais que ce dernier point concerne la lisibilité au niveau micro (où nous préférons généralement une notation plus verbeuse), tandis que le premier concerne la lisibilité au niveau macro (où nous préférons généralement une plus grande concision)
jk.

67
Pour tout programme faisant réellement quelque chose, Java devient souvent beaucoup plus lisible, en particulier avec une bonne utilisation de la bibliothèque.

9
en fait, un meilleur exemple de verbosité à l'échelle macro pourrait être constitué par les modèles qui contournent une fonctionnalité linguistique manquante
jk.

21
Je dirais que cet exemple avec Java n’est pas non plus le meilleur. Des éléments tels que la nécessité de définir une classe et une méthode importent en code golf, mais difficilement en applications réelles. Ce n'est pas comme si Java nécessite beaucoup de code pour produire quelques mots, ces quelques lignes sont nécessaires pour créer un programme, et c'est différent.
Malcolm

27
+1 pour la distinction entre Signal vs. Noise et Cryptic vs. Clear
Spoike

118

Cela affecte la quantité de code que vous pouvez voir et analyser en un seul coup d'œil

x++ plutôt que set(x,Integeradd(get(x),1))

ps. Ce n'est pas juste une question de lecture de code. A l'époque des écrans 40x25, les langages de type APL, ou Perl, étaient utiles sur Cobol ou Fortran pour la quantité de code que vous pouviez lire / page. Mais maintenant, il s’agit plus de votre propre cache interne: si une requête a un seul opérateur, il est plus facile pour mon cerveau vieillissant d’analyser celle-ci que celle contenant 3 symboles et 4 appels de fonction.


19
Je crois que c'est la raison ultime. Lisibilité sur un espace restreint tel qu'un morceau de papier ou un moniteur.

1
+1, et je suis tout à fait d’accord, et je code sur un ordinateur portable 13 ", mais là encore, ce site a 3 écrans comme logo ... doit être quelque peu lié :)
ZJR

1
@ZJR - voir edit.
Martin Beckett

3
Alors, que fait la setméthode ici? Définit-il réellement quelque chose (c'est-à-dire le premier xparamètre) ou renvoie-t-il quelque chose (c'est-à-dire l'attribution à xaprès l'appel)? Je dirais qu'il y a un certain dédoublement étrange dans l'exemple verbeux.
Jesse C. Slicer

8
Une chose qui manque ici, c'est l'utilité des idéogrammes - les symboles peuvent avoir plus de sens que les mots. Eg +est plus significatif que plus. =est meilleur que equals. Bien sûr, cela peut être pris trop loin (et cela a été fait en plusieurs langues) mais utilisé avec modération, il est très puissant.
mcmcc

29

Si le langage utilisé nuit à la lisibilité du code, il est mauvais.

Certaines langues ont une telle syntaxe verbeuse que saisir le sens du code prend plus de temps (je pense à VB.NET versus C #):

If something Then
End If

if(something)
{}

Cela revient vraiment à ce qu'un codeur est familier et à l'aise.


6
Je travaille surtout en C #, mais quand je lis VB, je le lis comme si c # était. J'ignore tout If .. Then .. End Ifet ne lis que ce qui est important.
Andy Hunt

7
comme Andy. Je trouve les deux également lisible. J'aurais même tendance à dire que je préfère une variante de VB (malgré que je sois plus habitué à c #).
dagnelies

9
VB.NET n'est pas commenté comparé à d'autres délinquants pires!

3
@AndyBursh - Exactement mon point. En lisant VB.NET, vous faites une traduction mentale au-delà de la compréhension du code.
Oded

6
Oded, End-If est une construction beaucoup plus facile à comprendre pour la fin d'une instruction if que les crochets lorsque les crochets sont nichés à l'intérieur d'une autre instruction if, dans une boucle, dans une autre boucle, dans une fonction qui est à l'intérieur une classe. Tous les blocs susmentionnés utilisent les mêmes crochets, ce qui signifie qu’il est moins intuitif d’essayer de déterminer lequel correspond à un crochet particulier.
Andrew Neely

27

Allez jeter un coup d'œil à AppleScript , l'un des langages les plus prolixes que je puisse penser qui puisse être considéré comme courant , essayez d' écrire quelque chose de trivaliste et revenez en arrière et essayez de faire valoir que la verbosité est un bon trait dans une langue.

Essayer de se rappeler toute la sémantique de la destination et de la nature des mots-clés n’est pas trivial si vous ne le faites pas tous les jours.

Il suffit de regarder tout le bruit des mots - clés dans cet exemple trivial:

tell application "Finder"
    if folder "Applications" of startup disk exists then
        return count files in folder "Applications" of startup disk
    else
        return 0
    end if
end tell

Accorder la même chose bashaux outils Unix traditionnels serait concis, mais crypté pour la plupart des utilisateurs d’OSX, il faut donc trouver un équilibre.


15
Vous ne voulez pas return the 0quand vous avez tapé ça? AppleScript est le seul langage que je connaisse qui permette de motiver des adversaires avec des mots-clés ... Je parle de collègues.
ccoakley

l'EDI d'Applescript, Script Editor, dans les années 90, était utilisé pour aider à gérer la verbosité avec l' enregistrement des actions, il n'était pas terriblement intelligent, mais plutôt pratique lors de l'écriture de scripts dans Finder ... autour de 1998, l'enregistrement a été interrompu et n'a jamais été réparé . (dunno si la transition OSX corrigeait cela, IIRC, non)
ZJR

3
La réponse d'OSX à la lourdeur d'AppleScript est Automator. Remplaçons le texte facile à saisir par une bibliothèque géante de blocs de fonctionnalités déplaçables, décrits de manière verbeuse et mal expliquée!
moelleux

La pire chose à propos de AppleScript est que chaque application que vous souhaitez utiliser peut utiliser une terminologie différente. Apple définit certaines suites de commandes que tous les programmes devraient prendre en charge, mais en général, savoir comment écrire un script dans une application n’a que peu d’aide pour en écrire un autre.
kindall

1
Applescript est fastidieux à écrire, mais facile à comprendre par l'homme ... dans les limites des programmeurs, insérant ses crochets avec une syntaxe intelligible dans l'application pilotée.
aramis

23

Je pense que vous devez inverser la question et demander: pourquoi certaines personnes pensent-elles que le code laconique est bon?

Ma réponse serait qu'il y a deux raisons fondamentales:

Raisons pour lesquelles laconique peut être mieux

Ceux-ci incluent être plus lisibles, de la même manière qu'une phrase courte peut être plus compréhensible qu'une phrase fleurie et verbeuse. Souvent, les langages de programmation qui imitent la grammaire anglaise finissent par être terriblement longs, nécessitant d’énormes volumes de code pour effectuer les actions les plus simples. Vous constaterez souvent que plus une langue imite une langue écrite, plus il est difficile de la persuader de réaliser des opérations logiquement complexes.

Les raisons pour lesquelles Terse peut être pire

Certaines langues (et je pense à Perl) utilisent un tableau de symboles étranges, qui semblent avoir été sélectionnés de manière presque arbitraire, dans le cadre de leur syntaxe. Pour ceux qui ne sont pas familiers avec ces hiéroglyphes, le langage devient impénétrable. Il devient également facile de faire des erreurs de frappe qui ne sont pas faciles à voir. Les expressions régulières incarnent peut-être ce genre de concision.

En outre, certaines personnes aiment se montrer en écrivant un code laconique parce que, franchement, elles pensent que cela les rend malignes. Vous le voyez parfois sur StackOverflow, où les gens soumettent souvent des réponses extrêmement compactes aux dépens de la lisibilité. C'est une sorte de "impressionner vos pairs" avec à quel point vous connaissez la philosophie, mais les bons programmeurs se rendent compte que le " code golf " n'est pas le moyen de créer un logiciel maintenable.


Je n’envisagerais pas de résumer l’opposé de verbose. Verbose a une connotation négative, il serait donc probablement plus approprié pour un antonyme à connotation positive.
Joshua Drake

6
terseest l'antonyme de verbose, tersepeut porter la même connotation négative (voir Perl)

1
@JarrodRoberson: Je déteste être pédant un vendredi soir, mais j'ai jeté un coup d'œil à quelques thésaurus en ligne et aucun d'entre eux n'a tersepour antonyme verbose(ou vice versa). / canards
Scott Mitchell


15

@frowing, je suggérerais que l’un des moyens d’examiner la question de la verbosité consiste à réaliser que la programmation consiste toujours en un mélange de deux styles plutôt différents de recherche et d’expression d’une solution.

Le premier style, plus détaillé, est la programmation (linguistique) orientée vers la langue. Ce style combine des mots ressemblant à des noms et des mots ressemblant à des verbes dans des structures ressemblant à des phrases. Il est conçu pour être lu et compris de la même manière qu’un paragraphe bien écrit. La programmation linguistique est le style de programmation le plus universel puisque le langage lui-même est universel. Pour cette même raison, le support de programme à long terme nécessite toujours une composante linguistique puissante, car la première chose qu'un nouveau programmeur recherchera est une compréhension conceptuelle de ce qui se fait. En règle générale, plus vous vous éloignez du contexte dans lequel vous avez créé un programme, plus un style de programmation linguistique sera important pour garantir que vos hypothèses et vos concepts ne seront pas mal compris par la prochaine personne qui tentera de comprendre votre code. .

Le deuxième style, plus concis, est la programmation orientée vers les mathématiques. Ce style de raisonnement repose également sur le langage, puisque, par exemple, les variables sont analogues aux noms et les opérateurs aux verbes. Cependant, le raisonnement mathématique exploite la capacité étonnante et hautement parallèle de notre cerveau à effectuer des transformations spatiales complexes sur des objets situés dans notre champ de vision. En représentant les noms et les verbes sous forme de symboles compacts et distinctifs pouvant être organisés en objets imaginaires bien structurés (équations), nous pouvons ensuite utiliser nos capacités visuelles hautement parallèles pour effectuer des rotations, remplacements, mouvements, inversions et autres transformations de ces images imaginaires. objets. Le résultat est une énorme amplification du nombre de cas que nous pouvons traiter en même temps, chaque symbole pouvant représenter des classes entières d'objets étroitement liés.

Notez que pour appliquer efficacement le traitement visuel, vous devez garder votre objet imaginaire aussi semblable que possible en taille et en fonctionnalités à un objet réel. Si le champ de vision requis devient trop large ou si les symboles ne peuvent pas être utilisés comme des marques mobiles sur un objet, ou si vous devez «lire des lettres» et les convertir en mots, la capacité à effectuer des transformations complexes de manière fiable tombera. rapidement même pour un très bon mathématicien.

C'est pourquoi les gens plongés profondément dans le style de programmation mathématique peuvent devenir sérieusement malheureux si une équation est étalée et exprimée dans ce qu'ils appellent un style linguistique «verbeux». Ce n'est pas parce que l'équation a été modifiée de manière significative, mais parce que la diffuser de cette façon peut rendre presque impossible l'application d'un style visuel de compréhension. Cependant, dans le même temps, un nouveau programmeur qui n'est pas du tout familiarisé avec les symboles courts préférera probablement une version plus détaillée qui fournira plus d'informations linguistiques pour comprendre initialement le fonctionnement du code.

Alors, que recommanderais-je?

Utilisez les deux styles, mais faites bien attention à la raison pour laquelle vous utilisez chaque style.

Par exemple, tout ce qui a une chance d'interagir avec le monde extérieur devrait être intensément détaillé à un certain niveau, ne serait-ce que sous la forme de commentaires en ligne mélangés avec le code, et devrait également inclure des contrôles automatisés pour un usage correct. Les notations cryptiques et en particulier incomplètement définies n'ont aucune activité dans de telles interfaces, car il est presque certain qu'elles seront mal comprises à un moment donné. La perte de l’Obiter climatique Mars en 1999, due à une impossibilité de déterminer si les unités d’interface logicielles étaient exprimées en livres ou en newtons, est un exemple particulièrement frappant du danger de s’appuyer trop simplement sur des nombres bruts aux interfaces logicielles ou matérielles.

Inversement, toute forme de programmation profondément algorithmique et mathématique est un bon candidat, une programmation succincte qui prend en charge le style de raisonnement mathématique. Si une personne nouvelle doit conserver un tel code, il serait généralement préférable qu'elle apprenne les notations mathématiques au lieu d'essayer de transformer le code en des formes plus verbeuses. Il devrait bien sûr y avoir à tout moment une documentation facilement disponible pour expliquer les parties mathématiques du code disponible pour ces développeurs, mais il s’agit d’une question distincte.

Entre ces extrêmes, il existe de nombreux cas où le programmeur dispose d'une discrétion considérable. Je suggérerais de regarder comment le code sera maintenu à long terme et d'essayer de répondre aux besoins des personnes les plus susceptibles de maintenir le code à long terme.


8

Un certain nombre de personnes ont fait allusion à quelque chose qui, à mon avis, devrait probablement être déclaré explicitement.

La verbosité a tendance à favoriser la compréhension au niveau microscopique - elle conduit généralement à une déclaration individuelle facile à lire et à comprendre. La verbosité tend également à réduire le degré de familiarité avec le langage nécessaire pour la comprendre (au moins dans une certaine mesure). Les langages les plus verbeux (par exemple, COBOL) peuvent être au moins quelque peu lisibles, même par des non-programmeurs complets.

La concision tend au contraire: elle aide à la compréhension au niveau macroscopique, en particulier pour les programmeurs ayant une connaissance intime de cette langue. Dans le même temps, le manque de familiarité avec ce langage spécifique peut empêcher une compréhension même rudimentaire, même de la part de programmeurs ayant une expérience assez considérable.

En tant que telle, la lisibilité varie considérablement en fonction du public cible. D'une part, considérons qu'un projet volumineux et complexe est écrit et entretenu par des personnes travaillant presque exclusivement sur ce projet, dont la plupart ont une expérience et une formation considérables en matière de programmation (par exemple, de nombreux doctorats). Cela aura tendance à favoriser un langage plus concis.

À plus ou moins l'extrême opposé, considérons un projet considérablement plus simple (bien que probablement encore assez volumineux) et maintenu principalement par des personnes vraiment spécialisées dans les activités associées au logiciel, plutôt que dans le logiciel lui-même. Cela favorisera presque certainement un langage beaucoup plus bavard.


6

Plutôt que d’aller dans un livre technique, je reviens aux éléments de style * de Strunk et White. Le concept sous-jacent est "Soyez précis" et "Ne dites pas plus que nécessaire." Tout le reste est un commentaire.

Appliqué à la programmation, il s’agit d’être très précis mais de ne pas avoir de peluches inutiles. Le fluff supplémentaire peut être de la syntaxe, mais il peut également s'agir de plus de mots que nécessaire pour transmettre le sens. (Bien sûr, pas trop peu pour permettre l'ambiguïté non plus)

  • Je cite la version originale car c'est la plus concise. :-)

5

En fin de compte, tout ce qui est "différent" fera hurler les gens. Je suis à l'aise avec la syntaxe de style C et donc d'accord avec d'autres langages qui partagent une syntaxe similaire (C ++, Java, C #). J'ai donc tendance à privilégier ce style particulier.

Les langues ont tendance à trouver un équilibre entre suffisamment descriptif et non verbeux.

Perl est un exemple où vous pouvez écrire du code très concis. Pour les non-initiés, le code écrit par un ninja Perl n’est rien de moins que de la magie.

COBOL est un exemple de trop prolixe.


5
Comment cela répond-il à la question?
ChrisF

la verbosité est différente pour tout le monde. C'était l'intention de mon commentaire. Si vous êtes dans le camp C / C ++, la verbosité acceptée est différente de celle utilisée si vous êtes dans le camp perl.
Nasir

Le code écrit par un ninja Perl n’est rien de moins que de la magie? Sérieusement, je pense que c'est un cauchemar.
Kevin

J'évite perl :)
Nasir

Pour les programmeurs, COBOL peut être trop bavard par rapport à d’autres langues. Cependant, bien écrit en COBOL peut être facile à lire pour les clients d’affaires. Cela leur permet de vérifier que le code répond à leurs besoins en le lisant.
BillThor

4

J'ai lu quelque part quelque part qu'une grande partie du débat prolixe venait des nouveaux programmeurs par rapport aux anciens. L'analogie utilisée est que lorsque nous apprenons quelque chose de nouveau, nous nous racontons une "histoire" pour la traverser (pensez à quand vous avez appris l'algèbre en HS). Au fur et à mesure que nous acquérons de l'expérience, nous allons au-delà du besoin d'une histoire expliquant les composants individuels et nous en comprenons davantage. Notre code devient plus dense et plus concis, avec des commentaires expliquant uniquement les éléments nécessaires, au lieu de répéter ce que le code dit.

J'ai trouvé que c'était vrai entre moi et un collègue. Elle écrit du code avec beaucoup de commentaires expliquant ce que sont les lignes de code et beaucoup d'espace. Si je le lis, je constate que je ne peux insérer que quelques lignes de code sur un écran à cause de cela. Cela facilite beaucoup la compréhension de chaque ligne, mais il est beaucoup plus difficile d’exécuter toute la fonction.

J'ai tendance à écrire du code sans espaces ni commentaires supplémentaires. Cela facilite la visualisation de l'ensemble, mais vous devez pouvoir simplement "obtenir" les "mots" de code individuels. Si vous essayez de lire cette réponse avec chaque mot sur sa propre ligne, avec beaucoup d'espaces / commentaires / extra verbiage, il sera beaucoup plus facile de comprendre chaque mot, mais beaucoup plus difficile de comprendre le tout.


Personne contre les commentaires. Le problème concerne des langages tels que Java, AppleScript ou Visual Basic, qui comportent de nombreux éléments redondants mais obligatoires.
Marcin

2
@Marcin, je ne suis pas contre les commentaires non plus, mais quand ils sont comme ça: i++; //this is adding one to var ic'est redondant.
Spencer Rathbun

La question concerne cependant les langages de programmation.
Rétablir Monica

2
@BrendanLong Hmm, peut-être que je n'étais pas clair. J'assimilais des commentaires inutiles avec des langages de programmation détaillés. Beaucoup de mots pour dire la même chose, seul un langage de programmation détaillé en a besoin à tout moment.
Spencer Rathbun

On pourrait faire valoir qu'une fonction ne devrait de toute façon pas comporter plus de quelques lignes. S'il est difficile de comprendre le fonctionnement de la fonction, ce n'est probablement pas à cause d'un trop grand nombre de commentaires. Mais je conviens que les commentaires qui ne disent que ce qui est immédiatement clair devraient de toute façon être évités.
gauche du

4

Einstein a eu raison: "Rendez les choses aussi simples que possible, mais pas plus simples."

Ceci s’applique également au code. Si vous pouvez simplifier le code en supprimant les éléments répétitifs et inutilement verbeux, c'est une bonne chose.

De plus, certaines études de cas suggèrent que la productivité du programmeur mesurée en lignes de code est plus ou moins une constante. Il en va de même du nombre de bugs par LOC. Ainsi, le passage à un langage qui vous permet d’en faire plus par ligne de code peut être considéré comme une amélioration de la productivité, si toutes choses égales par ailleurs.

Cela étant dit, cette industrie a tendance à trop concevoir et à compliquer des choses qui devraient être simples. Des choses simples, telles que le remplissage des informations de contact dans une base de données relationnelle. J'ai vu des solutions ridiculement compliquées et peu judicieuses ( MDA contre la toux ) pour résoudre ce problème particulier. Des langages tels que Scala et Ruby sont de bons exemples d'outils puissants qui, entre les mains de certaines personnes, génèrent un code inintelligible, trop compliqué et peu gérable. Ce n’est pas parce que vous pouvez utiliser plusieurs niveaux d’indirection en quelques touches seulement que vous devez casser tous les clous en vue avec ce marteau.

Lorsqu'il est utilisé correctement, vous obtenez un code propre, court, facile à comprendre. Lorsqu'il est mal utilisé, il est préférable de limiter l'individu en question à l'utilisation de Visual Basic ou d'un langage similaire limité pour éviter des dommages supplémentaires.

La vraie compétence consiste à faire des choses complexes de manière simple, pas à faire des choses simples de manière compliquée.


3

Quelque chose n'a été touché par la quantité de code que vous pouvez insérer dans un seul écran. Cela aide pour plusieurs raisons:

  • Moins de défilement dans les deux sens lorsque vous travaillez (ou lisez) plusieurs fonctions dans un seul fichier.
  • Moins de défilement horizontal (arrêter la lecture, cliquer et faire glisser la barre de défilement, arrêter la lecture, cliquer et faire glisser la barre de défilement ...).
  • Analyse plus rapide, car la syntaxe est moins inutile pour vous permettre de trouver ce que vous voulez.

vraiment combien de défilement est fait sur un écran 1920 x 1080 avec une taille de police raisonnablement lisible? Il y a aussi ces choses appelées raccourcis clavier pour la navigation dans les deux sens.

@JarrodRoberson - Mon écran affiche environ 30 lignes. Si la fenêtre de code est affichée en plein écran et que la taille de la police est à peine lisible, je reçois 60 lignes. J'ai eu à travailler sur plusieurs milliers de lignes (pas par choix, je vous assure). J'utilise le "navigateur" dans mon IDE, mais c'est toujours aussi pratique que de regarder deux sections de code qui sont toutes les deux à l'écran.
Rétablir Monica

Votre IDE ne supporte-t-il pas les vues divisées?
gauche du

2
Vous ne comprenez pas le problème - que mon IDE puisse rendre le défilement moins difficile , cela ne sera jamais aussi efficace que de ne pas avoir à faire défiler (ou à utiliser des touches de raccourci ou un écran partagé) . C'est comme dire "Les claviers à l'écran sont très bien, n'avez-vous jamais entendu parler de cliquer sur des choses?"; Bien sûr que si, mais avoir un vrai clavier n’est pas plus avantageux.
Rétablir Monica

Je me souviens vaguement qu'il existe en fait des études démontrant que cela est vrai (en particulier la partie défilement). Avoir à faire défiler pour voir toute une unité logique rend plus difficile à comprendre. Cela semble plausible, à tout le moins.
Konrad Rudolph

1

Parce que plus de code signifie plus de temps de développement et plus de bugs.

Si vous écrivez 100 lignes de codes plutôt que 300 lignes de codes. Cela signifie que vous aurez besoin d’un tiers de temps de développement et d’un tiers de bugs potentiels que vous pourriez rencontrer.

Dans la plupart des cas, vous devez concilier efficacité et concision, car écrire moins de codes signifie que la machine doit faire plus de choses et que l'efficacité en sera diminuée.


2
Je m'attendrais à beaucoup plus de bogues cachés dans 100 lignes typiques de Perl que dans 300 lignes d'Ada. - Quant à "comme écrire moins de codes signifie que la machine doit faire plus de choses et cela réduira l'efficacité", il peut exister une telle corrélation, mais ce n'est pas une causalité. C'est juste que les langages laconiques dynamiques et / ou interprétés comme Ruby, Perl et Python ont tendance à être plus lents que les langages compilés statiques plus verbeux comme C ou Fortran. Mais les programmes compilés en Haskell, Python avec PyPy ou C ++ peuvent être beaucoup plus rapides que les codes verbeux, par exemple interprétés en code Basic, Groovy, Smalltalk ou même C #.
leftaroundabout

1

Habituellement, les gens préfèrent les langues lisibles / verbeuses aux langues cryptiques / laconiques. Cependant, je pense que la plupart des gens ont assimilé "verbosité" avec "fouillis", qui ne sont pas la même chose.

Par exemple: while(<>){print if($.==2 || $& && !$x++); $.=0 if (/^--+$/)}

est une déclaration très laconique. Il contient tout ce que vous voulez savoir. Cependant, en raison de sa rareté, il est difficile à comprendre. Par ailleurs, une version légèrement plus détaillée du même programme serait assez simple à comprendre car plus lisible. Ce n'est bien sûr pas une propriété de la langue en soi, mais certaines langues ont tendance à être plus verbeuses tandis que d'autres ont tendance à être plus concises dans leur manière de programmer.

A l'autre extrême de verbosité, est http://en.wikipedia.org/wiki/Literate_programming , que je considère comme un concept assez intéressant.

Un autre aspect est la "verbosité indésirable", également appelée "fouillis". Ce que vous devez ajouter pour des raisons techniques, le manque de sucre syntaxique, des API gonflées, etc.

Je pense qu'une syntaxe claire et intuitive est très importante. Il doit également être suffisamment détaillé pour faciliter la lecture. Des déclarations trop courtes contenant trop de logique peuvent souvent laisser plus de temps pour le déchiffrement que leurs homologues légèrement plus longues. D’un autre côté, un code gonflé inutile rempli de lignes standard pour faire quelque chose de tout simple est également une nuisance.


4
Vous voudrez peut-être revérifier la [signification de concise] ( en.wiktionary.org/wiki/concise ), car il s'agit presque d'un antonyme de cryptique. Avez-vous peut-être du code en Java?
Joshua Drake

2
Je préfère le code prolixe écrit dans des langages concis.
Rétablir Monica

@ Josué: oui, j'ai remarqué que cela pouvait être interprété de différentes façons, alors j'ai modifié ma réponse. ... et qu'est-ce que Java a à faire avec ça?
dagnelies

1
Un commentaire expliquant pourquoi il a été voté vers le bas peut être plus intéressant que le vote à la baisse lui-même.
dagnelies

@ arnaud mon mal pour l'utilisation de Wikionary. La recherche google définit: débuts concis: "Donner beaucoup d’informations clairement" que votre exemple de code enfreint. Bien que je doive reconnaître l’implication originale de la lacune, de la clarté et de la concision, je me déplace à présent.
Joshua Drake

1

La verbosité étant une tendance à utiliser de grandes quantités de texte, et la concision à utiliser très peu de texte ...

La verbosité est mauvaise parce que:

  1. il introduit plus de possibilité d'erreur typographique
  2. cela rend plus difficile la lecture du code à l'écran ou sur papier, et / ou la saisie sur une carte perforée
    1. cela augmente les temps de débogage
    2. cela complique la compréhension du code pour la mise à niveau / la maintenance
    3. cela peut conduire à une duplication involontaire de code
  3. cela augmente quelque peu la probabilité d'erreur de syntaxe
  4. cela diminue la flexibilité de codage, en ce sens que la plupart des langages verbeux sont très structurés et n'ont pas plusieurs façons de dire la même chose.
  5. il augmente les temps de codage et de compilation
  6. cela peut prendre plus d'espace de stockage.

Un certain niveau de verbosité est essentiel pour la clarté, cependant ...

un niveau minimal de verbosité est bon pour les raisons suivantes:

  1. il est plus facile pour l'homme de lire et d'attacher une valeur sémantique à un code purement symbolique
  2. En nommant les variables et les fonctions, cela facilite le débogage, le portage et la maintenance du code
  3. dans les opérations de langage de niveau de base et les mots-clés de langages complexes, il en résulte moins d'attributions d'opérations / mots-clés incorrects.

Parmi les merveilleux exemples de commandes trop laconiques pour de nombreuses personnes, on peut citer les anciennes bases BASIC de val(x$), str$(x)et chr$(x)... renvoyer un nombre à partir de sa représentation sous forme de chaîne, renvoyer une chaîne pour un nombre et renvoyer un seul caractère ayant la valeur ascii x en tant que chaîne.

Ou le pointeur C / C ++ et par les opérateurs de référence &et *par rapport au byrefmot clé BASIC . En C / C ++, je peux avoir une variable X et passer un pointeur sur cette variable, mais je dois me rappeler quel est le pointeur et quel est le "pointeur d'utilisation comme variable à laquelle il pointe"; en basic, je passe simplement la référence avec un mot clé byref dans l'appel de fonction, ce qui est plus clair, mais moins flexible:

def fn Foo(x byref as float) foo= (x += x+1)
...
Foo(x)

Dans ce code, le contenu de x est modifié en raison de l'indicateur byref. Certaines saveurs autorisent les appels externes à l'appel, d'autres dans leur définition, d'autres dans l'un ou l'autre.

La verbosité est importante pour que les programmeurs occasionnels puissent utiliser le symbolisme plus facilement. BASIC ou python sont plus lisibles par l'homme et plus verbeux que le C / C ++, et sont donc beaucoup plus utiles pour les programmeurs occasionnels; la rareté de C / C ++ le rend bien meilleur pour les programmeurs plus expérimentés, qui ont besoin de voir plus de code et de code plus complexe en même temps, mais qui ont dû apprendre les différentes conventions de structure symbolique. À l'autre extrémité se trouve APL, qui est presque illisible pour l'homme.

La clarté est un problème intimement lié: le code abrégé manque souvent de clarté et le code trop détaillé (comme dans AppleScript) peut l'être également. La familiarité avec un langage donné augmente la clarté du code laconique au sein de ce langage - un débutant, confronté au code C ++, ne sera probablement capable d’analyser que les formules, et même une grande partie du code fonctionnel BASIC ou Python est trop concise pour la compréhension, mais l’apple être perplexe, généralement, sans avoir recours aux dictionnaires de langue. Le moins clair que j'ai rencontré sans obscurcissement intentionnel est Inform 7 ...

Dans les temps anciens

Une autre considération importante dans le passé, mais qui n’est plus aussi importante pour le codeur amateur, est l’utilisation et l’espace de stockage. (Il est toujours essentiel au haut de gamme.) Gardant à l’esprit que de nombreuses langues ont été interprétées, en particulier les versions BASIC, et beaucoup d’autres compilées au moment de l’exécution, l’espace codé était important, en particulier lorsque les disques ne contenaient que 128 Ko, et les cartes perforées individuelles, 80B.

Plusieurs solutions existaient - la tokenization était extrêmement courante dans BASIC; les mots-clés de chaque langue ont été réduits à un mot de 1 ou 2 octets dans les 128 caractères supérieurs ou dans l'espace des caractères de contrôle. La tokénisation conduit également à la compilation de codes temporels (comme dans Inform et Z-Machine).

La compilation et la liaison de plusieurs objets ont également été utilisées pour contourner les limitations d’espace. Une section de code Pascal de 100 Ko pourrait être compilée avec seulement 5 Ko; en liant plusieurs fichiers compilés, il est possible de créer des applications volumineuses sans avoir accès à des disques de grand format (en se rappelant que 10 Mo est incroyablement volumineux et acheter une nouvelle voiture chère).

Cependant, des langages plus complexes ont introduit plus de code dans un bloc donné de disque et de bélier, et ont ainsi compilé de plus gros morceaux à la fois. Il ne faut pas oublier que les "mini-ordinateurs" du début des années 1970 n’avaient que 64 Ko de mémoire vive (le Honeywell 800 disposait d’une installation de base de 4 banques de 2048 mots de 8B chacune). APL et les langages symboliques similaires ont approché 1B par instruction plus ses opérandes, par rapport au beaucoup plus grand 3B-10B par instruction plus des opérandes. (C'était un cauchemar de taper sur des cartes perforées, d'autant plus que les symboles étaient essentiellement une police de caractères sur une boule de frappe, et que beaucoup de cardpunches n'avaient pas les symboles sur les touches ...)

De plus, n'oubliez pas que les cartes ne peuvent pas être effacées ... et de nombreux programmes ont été entrés sur des cartes. Bien que cela ne coûte pas cher individuellement, plus votre code peut être compressé sur la carte, moins vous en avez besoin, plus les programmes sont volumineux ou moins coûteux. Cela explique en partie le fait que BASIC concatène plusieurs instructions par ligne dans la plupart des versions - il a été introduit pour économiser sur les cartes perforées. (Ou bien, dit mon texte de programmation Vax Basic.) Bien que je n’ai pas programmé de lecteur de carte, j’ai perforé une carte pour un Honeywell 800 en FORTRAN, BASIC, APL et quelques autres langages hautement symboliques.


Dans de nombreux cas, la verbosité augmente la probabilité que des erreurs typographiques soient détectées au moment de la compilation plutôt que de générer un comportement erroné.
Supercat

-1

Comme pour tant d'autres choses, la réponse dépend de la définition concrète de "verbosité". Si la définition est telle que la verbosité implique la redondance, alors je dirais que c'est toujours mauvais. Notez qu'avec une telle définition, le programme Java hello world, souvent cité, ne serait pas qualifié de "verbeux", car il ne contient aucun élément redondant.


1
Les crochets et les points-virgules équilibrés sont redondants, tout comme les déclarations de type.
Marcin

1
@Marcin: Oui, mais ils facilitent l'écriture d'un analyseur / analyseur pour le langage. Je suis assez convaincu qu'une telle syntaxe existe pour le développeur du langage, et non pour le programmeur qui l'utilise.
ccoakley

1
@Marcin - dépend entièrement de la langue, que les déclarations de type soient ou non nécessaires. Certains systèmes de types ne sont tout simplement pas décidables, donc ... en ce qui concerne les crochets et les points-virgules, eh bien, vous préférez un langage avec une grammaire sans ambiguïté et un bref aperçu - sinon la compilation, même de petits programmes, peut prendre des heures et à la fin Je dois choisir quelle interprétation de votre programme vous préférez.
Ingo

1
@ingo Je ne connais aucune langue dans laquelle toutes les variables ou fonctions doivent avoir une déclaration de type en raison de la complexité du système de types. En fait, je dirais que les langages dotés de systèmes de types plus puissants sont plus susceptibles d'autoriser l'omission de telles déclarations.
Marcin

1
@Marcin, aucune raison de se fâcher. Vous avez dit que je dirais que les langages avec des systèmes de types plus puissants permettent plus facilement de telles déclarations. Je vous ai donné un exemple, dans lequel un système de types plus puissant nécessite davantage d'annotations. Si vous sentez que cela ne contredit pas votre présentation, eh bien, ainsi soit-il.
Ingo

-1

Les programmeurs ont tendance à aimer les langues avec un pouvoir expressif, car cela leur permet de coder des choses simples, qui doivent souvent être faites fréquemment, dans de petits morceaux de code. Les langages verbeux tendent à signifier que beaucoup, beaucoup de lignes de code doivent être utilisées pour faire la même chose encore et encore. Cependant, il peut y avoir quelque chose d'un prix à payer avec des langages expressifs car ils peuvent ne pas être aussi rapides à exécuter que des langages de haut niveau plus simples. Si je peux donner un exemple dans le contraste entre C et C ++. C ++ donne plus de pouvoir expressif aux auteurs de code - ils peuvent encapsuler l'idée d'objets réels dans des classes. Les programmeurs C peuvent réaliser les mêmes choses, mais ils ont le pouvoir expressif de la construction de classe pour les aider - ils doivent donc écrire du code plus long et plus compliqué (pour comprendre). Mais ce code pourrait bien être exécuté plus rapidement (bien que cela dépende fortement de la qualité du compilateur, etc.) car il n'utilise pas la "liaison tardive" de C ++ (c'est-à-dire le refactoring à l'exécution) pour exécuter le code. C n’exécute que le code compilé et lié, C ++ doit prendre une décision (dans certaines circonstances) sur les éléments de code à exécuter au moment de l’exécution.


Avec cette "liaison tardive", vous voulez probablement dire des appels de fonctions virtuelles. Mais ce n'est qu'un moyen parmi tant d'autres de parvenir à la réutilisation du code. Le typage dynamique en est un autre, et donnerait probablement un meilleur exemple à votre argument, car il a tendance à générer beaucoup plus de temps système que les appels virtuels C ++. Cependant, il existe également des mécanismes qui n'ont aucune incidence sur les performances d'exécution, car ils peuvent être entièrement résolus au moment de la compilation: dans les langages orientés objet modernes, vous avez des modèles / génériques, dans le polymorphisme paramétrique des langages fonctionnels statiques.
gauche du

La liaison tardive est ce qui est utilisé pour que les appels de fonction virtuels fonctionnent, alors non, je ne voulais pas "appeler des appels virtuels", je voulais dire une liaison tardive. Les appels virtuels font partie de la définition du langage, la liaison tardive est ce qui fait que cette partie fonctionne. Et, bien sûr, il y a bien d'autres exemples dans d'autres langues. J'offrais un exemple du potentiel de compromis entre pouvoir expressif et rapidité, ne recommandant pas une langue plutôt qu'une autre.
adrianmcmenamin

-1

Je pense qu’il existe une réponse à la question qui s’appuie sur une question plus fondamentale et théorique que la lisibilité et elle est liée à la théorie de l’information algorithmique fondée par Gregory Chaitin: http://en.wikipedia.org/wiki/Algorithmic_information_theory . En quelques mots, "le contenu informationnel d’une chaîne de caractères équivaut à la longueur de la représentation autonome la plus courte possible de cette chaîne", ce qui implique que le programme le plus court (notamment en termes de longueur lexicographique) résolve un problème de près correspond à la complexité intrinsèque du problème auquel il donne une solution et dépend donc plus de la nature du problème que de sa représentation.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.