Pourquoi les développeurs C # newline ouvrent-ils des crochets? [fermé]


44

J'ai passé la plupart de ces dernières années à travailler principalement avec C # et SQL. Tous les programmeurs avec lesquels j'ai travaillé au cours de cette période avaient l'habitude de placer l'accolade ouvrante d'un énoncé de fonction ou de flux de commande sur une nouvelle ligne. Alors ...

public void MyFunction(string myArgument)
{
     //do stuff
}

if(myBoolean == true)
{
    //do something
}
else
{
    //do something else
}

J'ai toujours été frappé par le gaspillage d'espace, en particulier dans les déclarations if / else. Et je sais que des alternatives existent dans les versions ultérieures de C #, telles que:

if(myBoolean == true)
    //do something on one line of code

Mais presque personne ne les utilisait. Tout le monde a fait la chose curly-brace-on-newline.

Puis je me suis remis à faire du JavaScript après une longue absence. Dans ma mémoire, les développeurs JavaScript avaient l'habitude de faire exactement la même chose, mais avec toutes les nouvelles bibliothèques sophistiquées, la plupart des développeurs ajoutent l'accolade ouvrante après la déclaration:

function MyJavaScriptFunction() {
    //do something
}

Vous pouvez voir le sens de ceci, car depuis l'utilisation de fermetures et de pointeurs de fonctions est devenue populaire en JavaScript, cela économise beaucoup d'espace et rend les choses plus lisibles. Je me suis donc demandé pourquoi cela n'était pas vu comme une chose faite en C #. En fait, si vous essayez la construction ci-dessus dans Visual Studio 2013, elle la reformate pour vous, plaçant l'accolade ouvrante sur une nouvelle ligne!

Maintenant, je viens de voir cette question sur Code Review SE: https://codereview.stackexchange.com/questions/48035/questions-responses-let-me-tell-you-about-you Dans lequel j’ai appris qu’à Java, un langage que je ne connais pas très bien, il est considéré comme de la rigueur d’ouvrir vos accolades juste après la déclaration, à la manière de JavaScript moderne.

J'ai toujours compris que C # était à l'origine basé sur Java et respectait les mêmes normes de codage de base. Mais dans ce cas, il semble que non. Donc, je suppose qu'il doit y avoir une bonne raison: quelle est la raison? Pourquoi les développeurs C # (et Visual Studio) imposent-ils l'ouverture des accolades sur une nouvelle ligne?


30
La convention est simplement cela.
Oded

19
Visual Studio n'applique rien, le style de code est configurable. Quelque chose doit être le défaut. Le défaut est "mieux", c'est le bikeshedding du plus haut niveau.
Phoshi

23
L’attelle au bout de la ligne est l’ancienne norme K & R C. Kernighan et Ritchie ont inventé le langage C alors que les écrans d’affichage ne contenaient que 25 lignes (23 si vous ajoutez des lignes d’en-tête et d’état). Ce n'est plus vraiment le cas, non? Ce qui est important, c'est la cohérence tout au long d'un projet. Il existe également des études scientifiques montrant que l'accolade sur sa propre ligne (au même niveau que le code) améliore la compréhension du code malgré ce que les gens pensent qu'ils pensent de l'esthétique.
Craig

10
C # a toujours été favorable à l’évaluation d’une seule ligne de code après une condition, en passant. En fait, c'est la seule chose qu'il fait, même maintenant. Mettre du code entre accolades après une expression de branchement transforme cette instruction en un goto (le compilateur crée une portée à l'aide d'instructions jmp). C ++, Java, C # et JavaScript sont tous plus ou moins basés sur C, avec les mêmes règles d'analyse sous-jacentes, pour la plupart. Donc, dans ce sens, C # n'est pas "basé sur Java".
Craig

10
En note de bas de page, if(myBoolean == true)cela n’a aucun sens pour moi. Tant que nous y sommes, mais pas if ((myBoolean == true) == true)?? Juste if (myBoolean)et ça suffit. Désolé, une bête noire.
Konrad Morawski

Réponses:


67

L’attelle au bout de la ligne est l’ancien standard K & R C, tiré du livre The C Programming Language de Brian Kernighan et Dennis Ritchie , publié en 1978 après avoir co-inventé le système d’exploitation UNIX et le langage de programmation C (je pense que C principalement conçu par Ritchie), chez AT & T.

Il y avait des guerres de flammes à propos du «seul style de corset».

Ritchie a inventé le langage C et Kernighan a écrit le premier tutoriel, alors que les écrans d'ordinateur ne montraient que quelques lignes de texte. En fait, le développement de UNICS (plus tard UNIX) a démarré sur un DEC PDP-7, qui utilisait une machine à écrire, une imprimante et une bande de papier pour une interface utilisateur. UNIX et C ont été finis sur le PDP-11, avec des terminaux texte à 24 lignes. L'espace vertical était donc très important. Nous avons tous des écrans légèrement meilleurs et des imprimantes de résolution supérieure, non? Je veux dire, je ne sais pas pour vous, mais j’ai trois (3) écrans 24 "1080p devant moi en ce moment. :-)

De plus, le petit langage de programmation C est constitué d’échantillons de code qui placent les accolades au bout des lignes plutôt que sur leurs propres lignes, ce qui aurait économisé un montant appréciable sur l’impression.

Ce qui est vraiment important, c'est la cohérence d'un projet à l'autre, ou du moins dans un fichier de code source donné.

Il existe également des études scientifiques montrant que l'accolade sur sa propre ligne (au même niveau que le code) améliore la compréhension du code malgré ce que les gens pensent qu'ils pensent de l'esthétique. Cela indique très clairement au lecteur, visuellement et instinctivement, quel code est exécuté dans quel contexte.

if( true )
    {
    // do some stuff
    }

En passant, C # a toujours pris en charge l’évaluation d’une seule commande après une expression de branchement. En fait, c'est la seule chose qu'il fait, même maintenant. Mettre du code entre accolades après une expression de branchement transforme cette commande en goto (le compilateur crée une portée à l'aide d'instructions jmp). C ++, Java, C # et JavaScript sont tous plus ou moins basés sur C, avec les mêmes règles d'analyse sous-jacentes, pour la plupart. Donc, dans ce sens, C # n'est pas "basé sur Java".

En résumé, c’est un peu un problème religieux / guerre de flammes. Mais il y a des études qui en fait assez clair que l' organisation du code dans des blocs améliore humain compréhension. Le compilateur s'en fout. Mais ceci est également lié à la raison pour laquelle je ne mets jamais une ligne de code après une branche sans accolades - il est trop facile pour moi ou un autre programmeur de gifler une autre ligne de code plus tard et de glisser sur le fait que cela ne le fera pas. exécuter dans le même contexte avec la ligne juste avant ou après.

EDIT : Il suffit de regarder le bogue Applegoto fail pour un exemple parfait de ce problème, qui a eu de très graves conséquences dans le monde réel.

if( true )
    doSomething();

devient...

if( true )
    doSomething();
    doSomethingElse();

Dans ce cas, doSomethingElse()s'exécute à chaque fois, quel que soit le résultat du test, mais comme il est mis en retrait au même niveau que l' doSomething()instruction, il est facile de l'ignorer. Ce n'est pas vraiment discutable; les études soutiennent cette place. C'est une source importante de bogues introduits dans le code source lors de la maintenance.

J'admettrai tout de même que la syntaxe de fermeture JavaScript a l'air un peu ridicule avec des accolades sur leurs propres lignes ... esthétiquement. :-)


13
La partie sur les blocs conditionnels est légèrement trompeuse. En C, le conditionnel a toujours une seule déclaration, mais un bloc (aussi appelé instruction composée) est une sorte d’instruction . C # suit ce précédent. Quoi qu’il en soit, l’évaluation conditionnelle implique toujours une sorte d’instruction conditionnelle de type goto ou branchement, en raison de la nature linéaire de tous les jeux d’instructions courantes. Une condition sans bloc n'est pas qualitativement différente d'une condition avec un bloc (sauf en ce qui concerne la portée).
amon

3
@Craig, rappelez-vous, c'était aux Bell Labs, à l'époque où ils étaient chargés de "faire des choses intéressantes" qui n'étaient pas forcément pratiques. Mettez des gens intelligents dans un bâtiment, dites-leur de faire une recherche intéressante, sortez-les de ce qu'ils font, ce n'est pas "intéressant", et, chose amusante, des choses intéressantes (comme les transistors et Unix) ont tendance à sortir. La DARPA avait en quelque sorte le même objectif, au début, et elle a financé BEAUCOUP de bons travaux, au nom de la recherche fondamentale.
John R. Strohm

3
@Craig: À l’époque des jours Pascal / Delphes, je l’évitais généralement pour les blocs monolignes, comme le fait Pascal beginet endà la place des accolades, ce qui rend ces erreurs très difficiles à échapper, et il est également plus strict en ce qui concerne le placement des points-virgules. 4 jours l’année dernière, un problème en C embarqué avait été corrigé, ce qui était dû au manque de placement des accolades ..... Je pense qu’il devrait exister une option de compilation qui rend l’accolade obligatoire pour les instructions de contrôle!
Mark K Cowan

12
Veuillez fournir des références pour "... études scientifiques montrant que le corset repose sur sa propre ligne ...". Sans au moins deux références (sinon, il s'agirait d'une étude , pas d'une étude ), il s'agit simplement de tirer au hasard dans les airs.
ErikE

2
@Craig, pourriez-vous donner des pistes pour trouver les études de recherche que vous avez mentionnées?
Grzegorz Adam Kowalski

30

Les développeurs C # le font parce que c'est le paramètre par défaut du formateur automatique de Visual Studio. Bien que ce paramètre puisse être modifié, la plupart des gens ne le font pas et tous les développeurs d'une équipe doivent donc suivre la majorité.

Quant à savoir pourquoi c'est la valeur par défaut dans Visual Studio, je ne le sais pas.


15
C'est le comportement par défaut de Visual Studio, car c'était le style de codage généralement accepté par Microsoft, qui remontait en arrière. En fait, dans certaines équipes de Microsoft, le style ne consistait pas uniquement en accolades sur leurs propres lignes, mais en accolades sur leurs propres lignes. et en retrait. C'est donc une option dans Visual Studio également (je le préfère personnellement).
Craig

20
@Craig: Ewwwwwwwww
Courses de légèreté avec Monica

5
@ PreferenceBean Hmm. Personnellement, je n'aime pas le style K & R, car les crochets sont simplement perdus dans le bruit aux extrémités des lignes et le texte me semble encombrant, ce qui n'est pas seulement une préférence esthétique, mais qui a un impact réel sur la lisibilité / compréhension. J'aime les espaces verticaux. C'était un peu différent sur les moniteurs 12 "avec 24 lignes de texte à l'époque où l'espace vertical était précieux.
Craig

10
@Craig: Ce n'est pas une excuse pour mettre en creux les accolades: P
Lightness Races avec Monica

2
@Craig Pour rendre les employés de Microsoft misérables?
Mateen Ulhaq

18

Comme je l'avais supposé dans cette réponse ici: https://softwareengineering.stackexchange.com/a/159081/29029 - Je suppose que la décision d'utiliser le contreventement d'Allman pourrait être un signe de l'héritage de Pascal, étant donné que Hejlsberg a créé Delphi avant d'avoir conçu C # . Identique à la casse Pascal pour les noms de méthodes.

Personnellement, je crois qu'il faut suivre l'adage "à Rome, fais comme les Romains". J'utilise Allman en C #, mais K & R en Java. Je suis tellement habitué à cela que changer de convention dans l'un ou l'autre sens me fait mal au cœur.

Je pense qu'une certaine diversité de conventions est en fait bénéfique pour un développeur "multilingue", car cela aide à se souvenir de la langue dans laquelle il est en train de coder et facilite la différenciation des habitudes. C'est un équivalent mental de la mémoire musculaire, pour ainsi dire.


7
+1 pour la ligne "développeur multilingue", en fait. Je préfère sérieusement les accolades sur leurs propres lignes et en retrait. Cependant, dans les travaux sur, par exemple, les projets ASP.NET (MVC), je constate que j'aime le C # avec le style "correct" et le JavaScript avec le style "JavaScript". C'est un peu ironique, mais honnêtement, la syntaxe de fermeture de JavaScript est plus attrayante, avec l'accolade au bout de la ligne. Je suis donc autant esclave de l'esthétique que quiconque ...
Craig

PascalCase pour les noms de méthodes était un standard chez Microsoft longtemps avant que Anders Hejlsberg ne quitte Borland pour devenir un ingénieur logiciel distingué chez Microsoft.
Craig

2
Fait intéressant, j'utilise Allman pour tous les langages par bloc. Cependant, je suis de plus en plus intéressé par ce qu'une conversion de prétraitement en blocs à accolades avant traitement pourrait ressembler à Java. Le code "java" peut sembler extrêmement propre, une fois que j'ai enveloppé mon esprit de reconnaissance de modèle autour de lui. Je pense que Python a peut-être raison: il n'y a pas vraiment de bonne raison pour que les accolades soient dans une langue.
tgm1024

Utiliser des espaces pour contrôler le déroulement du programme est de la folie. Python est populaire ces jours-ci, mais cet aspect de Python est un peu fou depuis son apparition.
Craig

@Craig Python fan ici, en essayant de faire quelque chose en javascript. Si vous examinez votre autre réponse, et votre modification à propos de goto fail, utilisez l’indent pour contrôler le déroulement du programme, c’est ce que les humains veulent naturellement faire. Par conséquent, ce que vous voyez est ce qui s’exécute. Si c'est faux, cela ne fonctionne pas. Devoir décoder ce que signifient ces accolades, s’ils reflètent réellement l’indentation, est un travail supplémentaire qui va au-delà de la compréhension du programme. L'indentation est redondante pour les accolades, alors pourquoi les programmeurs l'utilisent-elles si les accolades sont utiles? L'imbrication profonde est inintelligible dans toutes les langues. Jus 'sayin'.
Neil_UK

14

La convention que vous associez à Java est le style K & R ou "One true brace style" et provient à l'origine de C. Ce style de retrait de page du vénérable fichier Jargon indique l'âge de la distinction.

J'ai toujours pensé que le style Allman et ses variantes reflétaient la façon dont les auteurs pensent le code, élevant les délimiteurs de blocs au niveau de mots clés similaires à ceux utilisés par certaines langues comme "begin" et "end" autour de blocs de code.


J'ai l'impression que ces jours-ci, OTBS (un vrai style d'accolade) implique également de ne jamais laisser les accolades après les instructions de contrôle, même pour des lignes de code simples. Voir le bug Apple goto fail.
Craig
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.