Existe-t-il des études scientifiquement rigoureuses sur les principes de style de codage? [fermé]

Un principe de style de codage - par exemple le principe de sortie unique - est-il vraiment une bonne chose? Toujours ou juste parfois? Quelle différence cela fait-il vraiment?

Quelles que soient vos opinions, ce sont évidemment des questions subjectives. Ou sont-ils?

Quelqu'un a-t-il tenté de faire une étude objective et scientifiquement rigoureuse des principes de style de codage?

Je ne peux pas imaginer comment quelqu'un ferait une étude en double aveugle de la lisibilité, mais peut-être que le double ignorant pourrait être possible - utilisez des étudiants qui ne connaissent pas le principe étudié en tant que sujets et des non-programmeurs pour administrer l'étude.

Je fais écho au commentaire de deadalnix: lire Code Complete 2 . L'auteur (Steve McConnell) discute du style de codage en profondeur et fréquemment des références d'articles et de données.

Je doute fortement de la possibilité même d'une étude sur le sujet donnant des résultats objectifs et je resterai sceptique jusqu'à ce qu'on me montre des recherches convaincantes.

Les programmeurs qui ont passé des années à lire et à écrire du code qui a suivi un certain style de codage le trouveront évidemment plus lisible qu'un style de codage parfait qu'ils verraient pour la première fois de leur vie.

C'est exactement la même chose avec la disposition de frappe QWERTY la plus courante - il est facile de prouver qu'elle est assez sous-optimale en termes d'ergonomie (pensez-vous que tous les caractères du mot TYPEWRITER ont été placés dans la rangée du haut avec notre commodité quotidienne à l'esprit?) .

Mais des alternatives améliorées telles que Dvorak ou Colemak n'ont jamais fait leur chemin et sont peu susceptibles de le faire. Et donc les gens ne sont pas plus productifs avec eux - fait. Même s'ils sont supérieurs dans un sens abstrait.

En outre, il serait difficile de trouver des sujets sans exposition préalable à la programmation (car cela contaminerait le résultat de notre étude), MAIS une aptitude à la programmation ET la volonté de participer à une étude pendant une période suffisamment longue pour montrer à la fois les courts -les avantages à long terme et les avantages à long terme afin qu'ils puissent être comparés les uns aux autres ... (Je ne sais pas s'ils s'excluent mutuellement, mais les chercheurs ne pouvaient pas simplement supposer qu'ils ne le sont jamais).

La réponse est un NON définitif! Est-ce que «casser» et «continuer» sont de mauvaises pratiques de programmation? est un sous-ensemble de cette question, donc je vais commencer par une réponse à peine modifiée à cela ...

Vous pouvez [ré] écrire des programmes sans instructions break (ou retours depuis le milieu des boucles, qui font la même chose). Mais ce faisant, vous devrez peut-être introduire des variables supplémentaires et / ou une duplication de code, ce qui rend généralement le programme plus difficile à comprendre. Pascal (le langage de programmation de la fin des années 1960) était très mauvais en particulier pour les programmeurs débutants pour cette raison.

Il y a un résultat informatique appelé la hiérarchie des structures de contrôle de Kosaraju, qui remonte à 1973 et qui est mentionné dans le (plus) célèbre article Structured Programming de Knuth avec des déclarations de 1974. Ce que S. Rao Kosaraju a prouvé en 1973, c'est que ce n'est pas possible de réécrire tous les programmes qui ont des sauts de profondeur n à plusieurs niveaux dans des programmes avec une profondeur de coupure inférieure à n sans introduire de variables supplémentaires. Mais disons que ce n'est qu'un résultat purement théorique. (Ajoutez simplement quelques variables supplémentaires?! Vous pouvez sûrement le faire pour vous sentir en contact avec les utilisateurs 3K + sur stackexchange ...)

Ce qui est beaucoup plus important du point de vue de l'ingénierie logicielle est un article plus récent de 1995 d'Eric S. Roberts intitulé Loop Exits and Structured Programming: Reopening the Debate (doi: 10.1145 / 199688.199815). Roberts résume plusieurs études empiriques menées par d'autres avant lui. Par exemple, lorsqu'un groupe d'étudiants de type CS101 a été invité à écrire du code pour une fonction implémentant une recherche séquentielle dans un tableau, l'auteur de l'étude a déclaré ce qui suit au sujet des étudiants qui ont utilisé une pause / retour pour quitter le séquentiel. boucle de recherche dès que l'élément a été trouvé:

Je n'ai pas encore trouvé une seule personne qui a tenté un programme en utilisant [ce style] qui a produit une solution incorrecte.

Roberts dit également que:

Les étudiants qui ont tenté de résoudre le problème sans utiliser un retour explicite de la boucle for s'en sont beaucoup moins bien sortis: seuls sept des 42 étudiants qui ont essayé cette stratégie ont réussi à générer des solutions correctes. Ce chiffre représente un taux de réussite inférieur à 20%.

Oui, vous pouvez être plus expérimenté que les étudiants CS101, mais sans utiliser l'instruction break (ou renvoyer / aller de façon équivalente au milieu des boucles), vous finirez par écrire du code qui, bien qu'étant nominalement bien structuré, est assez velu en termes de logique supplémentaire les variables et la duplication de code que quelqu'un, probablement vous-même, y mettra des bogues logiques tout en essayant de suivre une idée de passe de style de codage "correct".

Et il y a un problème plus important ici en plus des instructions return / break-type, donc cette question est un peu plus large que celle concernant les ruptures. Les mécanismes de gestion des exceptions violent également le paradigme du point de sortie unique selon certains

• http://msmvps.com/blogs/peterritchie/archive/2008/03/07/single-entry-single-exit-should-it-still-be-applicable-in-object-oriented-languages.aspx
• http://pragprog.com/magazines/2012-04/the-pragmatic-defense

Donc, fondamentalement, tous ceux qui ont soutenu ci-dessus que le principe de sortie unique est toujours utile aujourd'hui argumentent également contre le paradigme de gestion des exceptions, à moins qu'il ne soit utilisé de la manière extrêmement restrictive décrite dans ce dernier lien; ces directives contraignent fondamentalement toutes les exceptions d'une fonction à throw (), c'est-à-dire qu'aucune propagation d'exceptions inter-fonctions n'est autorisée du tout. Profitez de votre nouveau Pascal avec une syntaxe de type C ++.

Je vois d' où vient la notion de "un seul retour"?que l'opinion répandue sur ce site est contraire à ce que j'ai posté ici, donc je comprends parfaitement pourquoi j'ai déjà été rejeté, même si je suis la première réponse ici à fournir quelque chose que la question demandait: quelques informations sur les tests d'utilisabilité réels axés sur le problème de sortie unique. Je suppose que je ne devrais pas laisser la connaissance entraver les idées préconçues, en particulier sur un site de gamification. Je vais m'en tenir à l'édition de Wikipedia à partir de maintenant. Au moins, les informations provenant de bonnes sources sont appréciées et les affirmations vagues ou incorrectes prétendant être soutenues par des sources finissent par être interdites. Sur ce site, c'est tout le contraire qui se produit: les opinions non étayées par les faits dominent. Je m'attends à ce qu'un mod supprime cette dernière partie, mais au moins ce mec saura pourquoi vous m'avez perdu pour toujours en tant que contributeur ici.

http://dl.acm.org/citation.cfm?id=1241526

http://www.springerlink.com/content/n82qpt83n8735l7t/

http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=661092

[Vos questions semblent répondre par un seul mot, "oui". On m'a dit, cependant, que fournir des réponses courtes est «dédaigneux» de la question. Si vous pensez que j'ai été dédaigneux, veuillez signaler la réponse afin qu'un modérateur puisse la supprimer.]

Est un principe de style de codage - par exemple le principe de sortie unique

Les gens qui se demandent encore s'il s'agit d'une sortie unique ou de sorties multiples sont toujours bloqués à la fin des années 1960. À l'époque, une telle discussion était importante car nous étions dans les balbutiements du programmeur structuré, et il y avait un camp assez nombreux proclamant que les découvertes derrière le théorème du programme structuré de Bohm-Jacopini n'étaient pas universellement applicables à toutes les constructions de programmation.

C'est quelque chose qui aurait dû être réglé depuis longtemps. Eh bien, c'est réglé (près de 4 décennies pour être précis, à la fois dans le monde universitaire et dans l'industrie), mais les gens (ceux qui sont absolument pro ou contre) n'ont pas fait attention.

Quant au reste de mes réponses, tout est relatif (qu'est-ce qui n'est pas dans le logiciel?):

• vraiment une bonne chose?

Oui. La plupart du temps pour le cas général, avec des mises en garde spécifiques aux cas marginaux et des constructions de programmation spécifiques au langage.

Toujours ou juste parfois?

Le plus souvent.

Quelle différence cela fait-il vraiment?

Dépend.

Code lisible vs code illisible. Complexité accrue (que nous devrions connaître maintenant augmente la probabilité d'introduction d'erreurs) vs complexité plus simple (et ergo, probabilité d'erreurs plus faible). Langages dont les compilateurs n'ajoutent pas de retour implicite (par exemple, Pascal, Java ou C #) et ceux qui par défaut à int (C et C ++).

En fin de compte, c'est une compétence affinée avec des heures / homme derrière un clavier. Parfois, c'est correct d'avoir plusieurs instructions de retour, comme ici (dans certains pseudocodes Pascal'esque):

function foo() : someType
  begin
  if( test1 == true )
  then
    return x;
  end
  doSomethignElseThatShouldnHappenIfTest1IsTrue();
  return somethingElse();
end;

L'intention est claire, et l'algorithme est suffisamment petit et assez simple pour qu'il ne justifie pas la création d'une variable «drapeau» qui contient la valeur de retour éventuelle utilisée dans un seul point de retour. L'algorithme peut être erroné, mais sa structure est suffisamment simple pour que l'effort de détection d'une erreur soit (très probablement) négligeable.

Parfois, ce n'est pas le cas (en utilisant ici un pseudocode de type C):

switch(someVal)
{
case v1 : return x1;
case v2 : return x2:
case v3 : doSomething(); // fall-through
case v4: // fall-through
case v5: // fall-through
case v6: return someXthingie;
...
...
default:
   doSomething(); // no return statement yet
}

Ici, l'algorithme n'a pas de structure simple et l'instruction switch (de style C) permet des étapes de passage qui peuvent ou non être effectuées intentionnellement dans le cadre de l'algorithme.

Peut-être que l'algorithme est correct, mais mal écrit.

Ou peut-être, par des forces externes au-delà des capacités du programmeur, c'est la représentation réelle (et correcte) d'un algorithme légitimement nécessaire.

C'est peut-être faux.

Pour découvrir la vérité de tout cela, il faut beaucoup plus d'efforts que dans l'exemple précédent. Et là se trouve quelque chose que je crois fermement (sachez que je n'ai aucune étude formelle à l'appui):

En supposant un extrait de code supposé correct:

1. Les instructions de retour multiples augmentent la lisibilité et la simplicité d'un tel extrait de code, si l'extrait de code représente un algorithme simple avec une structure de flux intrinsèquement simple. Par simple, je ne veux pas dire petit, mais je veux dire intrinsèquement compréhensible ou évidence , ce qui ne nécessite pas d'effort de lecture disproportionné (ni inciter les gens à vomir, à maudire la mère de quelqu'un ou à avaler une balle quand ils doivent le lire. )

2. Une seule déclaration de retour augmente la lisibilité et la simplicité d'un tel morceau de code si la valeur de retour est calculée tout au long de l'exécution de l'algorithme ou si les étapes de l'algorithme chargé de le calculer peuvent être regroupées en un seul emplacement dans la structure de l'algorithme .

3. Une seule instruction de retour diminue la lisibilité et la simplicité d'un tel morceau de code si elle nécessite des affectations à une ou plusieurs variables d'indicateur, les emplacements de ces affectations n'étant pas uniformément situés dans tout l'algorithme.

4. Les instructions de retour multiples réduisent la lisibilité et la simplicité d'un tel morceau de code si les instructions de retour ne sont pas réparties uniformément dans l'algorithme et si elles délimitent des blocs de code mutuellement exclusifs qui ne sont pas de taille ou de structure uniformes entre eux.

Cela est étroitement lié à la complexité d'un extrait de code en question. Et ceci est à son tour lié aux mesures de complexité cyclomatiques et halstead. De cela, on a pu observer ce qui suit:

Plus la taille d'un sous-programme ou d'une fonction est grande, plus sa structure de flux de contrôle interne est grande et complexe, et plus vous serez confronté à la question d'utiliser ou non des instructions de retour multiples ou complexes.

La conclusion de ceci est: gardez vos fonctions petites en faisant une seule et unique chose (et en le faisant bien). S'ils présentent des métriques de complexité cyclomatique et halstead nominalement réduites, non seulement ils sont très probablement corrects et implémentent des tâches qui sont compréhensibles, mais leurs structures internes seront également relativement évidentes.

Ensuite, et seulement alors, vous pouvez assez facilement et sans perdre beaucoup de sommeil, vous pouvez décider d'utiliser un seul retour et plusieurs retours sans courir beaucoup de risques d'introduire des erreurs avec l'un ou l'autre choix.

On pourrait également examiner tout cela et suggérer que lorsque les gens sont aux prises avec la question des retours uniques ou des retours multiples, c'est parce que - soit par inexpérience, par stupidité ou par manque d'éthique du travail - ils n'écrivent pas de code propre et ont tendance à écrire fonctions monstrueuses avec mépris total des mesures cyclomatiques et halstead.