web-dev-qa-db-fra.com

Pourquoi les développeurs C # ouvrent-ils les crochets ouvrants?

J'ai passé la plupart des dernières années à travailler principalement avec C # et SQL. Chaque programmeur avec qui j'ai travaillé au cours de cette période avait l'habitude de placer l'accolade d'ouverture d'une fonction ou d'une instruction de flux de contrôle sur une nouvelle ligne. Donc ...

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 #, comme:

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

Mais presque personne ne les a utilisés. Tout le monde a fait la chose bouclée sur une nouvelle ligne.

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 avec une accolade bouclée, mais avec toutes les nouvelles bibliothèques et autres éléments fantaisistes, la plupart des développeurs ont mis l'accolade d'ouverture après la déclaration:

function MyJavaScriptFunction() {
    //do something
}

Vous pouvez voir le sens de cela, car l'utilisation de fermetures et de pointeurs de fonction étant devenue populaire en JavaScript, elle économise beaucoup d'espace et rend les choses plus lisibles. Je me suis donc demandé pourquoi cela n'était pas vu comme la chose faite en C #. En fait, si vous essayez la construction ci-dessus dans Visual Studio 2013, elle la reformate en fait pour vous, mettant l'accolade d'ouverture 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-yo Dans lequel J'ai appris qu'en Java, un langage que je ne connais pas trop, il est considéré comme de la rigueur d'ouvrir vos accolades juste après la déclaration, de façon JavaScript moderne.

J'avais toujours compris que C # était à l'origine modélisé d'après Java et respectait un grand nombre des mêmes normes de codage basal. Mais dans ce cas, il ne semble pas. Je suppose donc qu'il doit y avoir une bonne raison: quelle est la raison? Pourquoi les développeurs C # (et Visual Studio) appliquent-ils l'ouverture des accolades sur une nouvelle ligne?

javac#javascriptsyntax
48
Bob Tway

L'attelle à la fin de la ligne est l'ancienne norme K&R C, du livre de Brian Kernighan et Dennis Ritchie The C Programming Language , qu'ils ont publié en 1978 après co -inventer le système d'exploitation UNIX et le langage de programmation C (je pense que C a été principalement conçu par Ritchie), chez AT&T.

Il y avait des guerres enflammées sur "le seul vrai style de corset".

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

En outre, une grande partie de ce petit livre Le langage de programmation C est des exemples de code qui plaçant les accolades à la fin des lignes au lieu de sur leurs propres lignes auraient sauvé un montant d'argent appréciable à l'impression.

Ce qui est vraiment important, c'est la cohérence tout au long d'un projet, ou au moins dans un fichier de code source donné.

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

if( true )
    {
    // do some stuff
    }

C # a toujours pris en charge l'évaluation d'une seule commande après une expression de branchement, soit dit 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 ne fait que cette commande un goto (le compilateur crée une portée à l'aide des 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".

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

[~ # ~] éditez [~ # ~] : Allez voir le Apple goto fail bug pour un exemple parfait de ce problème exact, 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 elle est mise en retrait au même niveau que l'instruction doSomething(), elle est facile à manquer. Ce n'est pas vraiment défendable; études soutiennent cela. Il s'agit d'une grande source de bogues introduits dans le code source lors de la maintenance.

Pourtant, je dois admettre que la syntaxe de fermeture JavaScript semble un peu idiote avec des accolades sur leurs propres lignes ... esthétiquement. :-)

70
Craig

La raison pour laquelle les développeurs C # le font est qu'il s'agit du 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 donc tous les développeurs d'une équipe doivent choisir la majorité.

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

31
Timwi

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

Personnellement, je crois qu'il faut suivre l'adage "à Rome, faites comme les Romains". J'utilise Allman's en C #, mais K&R en Java. Je suis tellement habitué à cela que changer la convention dans un sens ou dans l'autre me choque.

Je crois qu'une certaine diversité de conventions est en fait bénéfique pour un développeur "multilingue" car elle aide à se souvenir de la langue dans laquelle ils codent en ce moment et permet de différencier facilement diverses habitudes. C'est un équivalent mental de la mémoire musculaire, pour ainsi dire.

19
Konrad Morawski

La convention que vous associez à Java est le style K&R, ou "One true brace style", et provient à l'origine de C. Cette page indent-style from the vénérable fichier de jargon montre l’âge de la distinction.

J'ai toujours pensé que le style Allman et ses variantes reflètent la façon dont les auteurs pensent le code, élevant les délimiteurs de blocs au niveau de mots-clés similaires à la façon dont certaines langues utilisent "début" et "fin" autour des blocs de code.

15
John Bickers