Comment formatez-vous vos instructions composées dans Delphi et C#?

Question

Aussi longtemps Pascal et développeur Delphi, je ALWAYS mon début et se termine ainsi:

begin 
    if x = y then 
    begin 
    ... 
    ... 
    end 
    else 
    for i := 0 to 20 do 
    begin 
     ... 
     ... 
    end; 
end; 

Ce qui me rend fou est le code formaté ainsi:

begin 
    if x = y then begin 
    ... 
    ... 
    end 
    else 
    for i := 0 to 20 do begin 
     ... 
     ... 
    end; 
end; 

Quand il y a quelques niveaux des déclarations composées, je trouve cela difficile à lire. Le code ci-dessus est correct, parce que ce n'est pas si compliqué, mais par souci de cohérence, je préfère que tout commence et se termine. Lorsque je commence à utiliser C#, je me retrouve à aligner des accolades également. Quelle est la norme dans le monde C#?

Edit:

Quelqu'un a fait remarquer que ce type de question qui ne devrait pas être posée sur le SO. Je ne vois pas pourquoi pas. Je suis en train de mettre en place un document de directives de codage. Je sais que je vais avoir une certaine résistance à certaines choses, j'espère obtenir quelques réponses ici, donc je peux être prêt à affronter cette résistance de front.

Answer 1

Tout le monde a des préférences différentes. Dans mon cas, j'ai appris Modula-2 avant d'apprendre Pascal. Modula-2 n'a pas de mot-clé BEGIN et un END requis pour chaque bloc. Donc, le code pourrait ressembler à ceci (Modula-2 arrive à la casse avec des mots clés en majuscules):

IF x = y THEN 
    .... 
END; 

Quand j'ai commencé à coder en Pascal, cela est devenu:

if x = y then begin 
    .... 
end; 

De cette façon, la le code ressemblait plus à ce que j'avais l'habitude de voir, tout en restant dans le domaine du code Pascal acceptable. Pour moi, ces premières impressions ont influencé mon style d'accolade et de retrait préféré pour pratiquement toutes les autres langues avec lesquelles j'ai travaillé. Il n'y a pas vraiment de "norme" particulière pour le code C#, tout comme il n'y en a pas pour C ou Pascal.

La seule vraie règle à suivre est la suivante: Lorsque vous travaillez sur du code existant, utilisez le style qui existe déjà. Lorsque vous travaillez sur un nouveau code, utilisez votre style préféré.

Answer 2

Cela a déjà été demandé. par exemple c-coding-standard-best-practices.

Answer 3

Je n'écrirais jamais le code (votre deuxième exemple) de cette façon. Il serait soit (de préférence)

begin 
    if x = y then begin 
    ... 
    end 
    else begin 
    for i := 0 to 20 do begin 
     ... 
    end; 
    end; 
end; 

ou

begin 
    if x = y then begin 
    ... 
    end 
    else for i := 0 to 20 do begin 
    ... 
    end; 

extrémité;

Parfois j'utilise un tel effondrement (comme dans le second cas) pour combiner if et try..finally.

x := GetMeTheObject; 
if assigned(x) then try 
    ... 
finally FreeAndNil(x); end; 

Answer 4

Je l'habitude d'utiliser un "ballants" commencer à Delphes:

if (SomeCondition) then begin 
    ... 
end; 

Étrangement, je ne l'ai pas avec C, parce que je trouve cela plus lisible:

if (SomeCondition) 
{ 
    ... 
} 

Après un moment, j'ai arrêté d'essayer d'enregistrer une seule ligne ici et là en faveur de la lisibilité:

if (SomeCondition) then 
begin 
    ... 
end; 

J'utilise aussi des blocs begin/end explicites où je pense que cela améliore la lisibilité. Je n'ai pas besoin d'être "intelligent". Je dois être en mesure de suivre l'intention du code en un coup d'œil. Plus important encore, tout le monde peut le lire/le maintenir.

if x = y then 
begin 
    ... 
    ... 
end 
else 
begin 
    for i := 0 to 20 do 
    begin 
    ... 
    ... 
    end; 
end; 

Je ne prends pas la peine d'habitude s'il y a évidemment une seule instruction

if (SomeCondition) then 
    ... 

Answer 5

j'utilise:

if Condition then 
begin 
    DoThis; 
end else 
begin 
    DoThat; 
end; 

Voir Object Pascal Style Guide.

Dans le composé si les déclarations, mettre chaque élément séparant les déclarations sur une nouvelle ligne: Exemple:

// INCORRECT 
if A < B then begin 
    DoSomething; 
    DoSomethingElse; 
end else begin 
    DoThis; 
    DoThat; 
end; 

// CORRECT 
if A < B then 
begin 
    DoSomething; 
    DoSomethingElse; 
end 
else 
begin 
    DoThis; 
    DoThat; 
end; 

Voici quelques autres variations qui sont considérés comme valides:

// CORRECT 
if Condition then 
begin 
    DoThis; 
end else 
begin 
    DoThat; 
end; 

// CORRECT 
if Condition then 
begin 
    DoThis; 
end 
else 
    DoSomething; 

// CORRECT 
if Condition then 
begin 
    DoThis; 
end else 
    DoSomething; 

Answer 6

Par Sur le plan sonore, je préfère compresser les déclarations jointives sur une ligne. Par exemple. end else sur une ligne. Il est plus clair que le prochain bloc de déclarations est lié à celui en cours.

Answer 7

J'ai tendance à faire dans Delphi:

if a=b then begin 
    c; 
end else begin 
    d; 
end; 

if x=y then z; 

simplement parce que je trouve plus lisible que les sauts de ligne supplémentaires. Évidemment, si je travaille avec d'autres, j'utiliserai les standards sur lesquels nous nous entendons (ou ce que la base de code actuelle utilise), mais quand je suis le seul à travailler dessus (comme dans les projets personnels), alors Je le fais comme ça.

Answer 8

standard dans le monde de C est d'aligner les accolades de fermeture soit avec la déclaration de départ:

if (I am nuts) { 
    Psychiatry 
} 

ou même placer l'accolade d'ouverture sur sa propre ligne:

if (I am nuts) 
{ 
    Psychiatry 
} 

Dans certains styles, la accolades ont différentes indentation:

if (I am nuts) 
    { 
    Psychiatry 
    } 

ou même

if (I am nuts) 
    { 
    Psychiatry 
    } 

J'ai utilisé le premier style depuis longtemps en Perl, ce qui était mon chemin pour la suite else:

if (I am nuts) { 
    Psychiatry 
    } else { 
    I am free 
} 

mais après avoir été exposé à Lisp, je ne vois aucune valeur supplémentaire de mettre les accolades sur leur propre ligne quand je suis déjà bien: indentation du

if (I am completely nuts) { 
    Psychiatry } 
    else { 
    I am free } 

Je n'ai pas d'espoir de changer les méthodes traditionnelles C avec ces pensées, cependant. En aparté, Python a complètement abandonné les accolades et ne compte que sur l'indentation, mais cela va trop loin à mon humble avis, car cela mène à des choses ridicules comme si lambda ne pouvait avoir qu'une seule affirmation.

Answer 9

Quelqu'un a posté qu'ils écriraient les éléments suivants:

if x=y then z; 

Ce que je n'aime vraiment pas, et ça n'a rien à voir avec l'esthétique. Supposons que x, y et z sont des fonctions. Si je parcours le code, cela signifie que je ne peux pas passer par x et y et entrer dans z.

1 if x=y then 
2  Z; 

Je peux maintenant entrer dans la ligne 2, sans entrer dans la ligne 1.

Answer 10

ligne I toujours Begin/FINIT comme dans votre exemple. (Sauf que j'aurais un Begin/End autour de l'instruction For aussi - juste au cas où vous ajouteriez du code plus tard.)

De toute façon, si votre code est profond de plusieurs niveaux, alors peu importe où vous mettez votre début/fin car c'est trop compliqué. Si vous vous trouvez sur, disons, 3 niveaux de profondeur, arrêtez, et simplifiez. Créer des sous-routines pour nettoyer les choses. CodeComplete est le meilleur livre de référence sur ce genre de chose. Si tu n'apprends pas quelque chose en lisant ce livre, alors je vais manger mon chapeau.

Answer 11

Il y a quelque temps j'ai utilisé

if <cond> then 
    begin 
    ShowMessage('balablala'); 
    exit; 
    end; 

Mais maintenant je suivre la norme par le

if <cond> then 
begin 
    ShowMessage('balablala'); 
    exit; 
end; 

Comme dans Object Pascal Style Guide

Answer 12

Je tends à la ligne toujours mon IF et ELSE et tiret mon bloc BEGIN/END. Si j'ai une condition multiple IF, je la casse en plusieurs lignes.Si je trouve mon moi profond, je repense ce que je suis en train de coder ou refactoriser en plusieurs méthodes. Donc, mon code ressemble à ceci:

if condition1 then 
    begin 
    // do something 
    end 
else // not condition1 
    begin 
    // do something else 
    end; 

ou plus complexe si conditionals.

if condition1 or 
    condition2 or 
    condition3 and 
    (condition4 or 
    condition5) 
then 
    begin 
    // do something 
    end 
else // not conditions 
    begin 
    // do something else 
    end; 

Answer 13

Tout cela est plutôt amusant. J'ai mon propre mode d'alignement idiosyncratique que, bizarrement, j'utilise dans plusieurs langues, y compris Pascal, C, et même COBOL (mais pas depuis longtemps pour celui-là). Je pense que je l'ai vu pour la première fois dans une classe de Ken Orr. Ma version ressemble beaucoup à une règle de hors-jeu (similaire à Python et F #) où vous pouvez simplement utiliser indenting pour montrer l'imbrication.

Quoi qu'il en soit, voici comment je fais l'exemple:

begin if x = y 
     then begin (* stack to avoid getting too much indentation *) 
      ...  
      ... 
      end 
     else for i := 0 to 20 
      do begin  
       ...  
       ...  
       end; 
     end; 

et oui, le C/C++/Java/C saveur # serait quelque chose comme

{ if (x == y) 
      { ... /* Space as if 'then' is there */ 
      ... 
      } 
    else for (int i = 0; i<21; i++) 
       { ... /* space as if 'do' is there */ 
       ... 
       } 
    } 

J'utilise ce lot. Vous pouvez empiler {et} de la même manière que j'ai commencé et terminé, mais je trouve plus agréable de pouvoir voir un bord et de confirmer les parenthèses correspondantes et la fin du groupe en retrait. Je varie pour garder indenting d'être excessif et pour éviter d'avoir trop de "{" et "}" seul dans une mer d'espace.

Je n'évangélise pas cela. Personne ne s'est plaint de pouvoir le lire. Mettre "{" à la fin d'une ligne semble être un hold-over de la part des pré-processeurs de Ratfor et ainsi de suite, comme Python exige le ":" par endroits. Je ne veux pas avoir à balayer le bord droit déchiqueté du code quand je peux utiliser l'alignement sur les bords gauches plus utilement.

Comme nous le disons ici, YMMV

Answer 14

Utilisez une formatter de code comme code JEDI Format de http://jedicodeformat.sourceforge.net/

Answer 15

Même si elle est une déclaration unique dans if, j'utilise toujours composé begin-end pour éviter toute confusion future. J'ai aussi mis // if après chaque end;.

if A < B then 
begin 
    DoSomething; 
end; // if 

Même chose pour les autres déclarations:

with qryTemp do 
begin 
    First; 

    while not Eof do 
    begin 
    if (A < B) 
     or (C < D) 
    begin 
     DoSomething; 
    end else 
    begin 
     DoSomethingElse; 
    end; // if-else   

    Next; 
    end; // while 
end; // with 

Pour C#, je suivre les instructions composées de style Code Conventions for the Java Programming Language.

if (condition) { 
    statements; 
} // if 

if ((condition1 && condition2) 
     || (condition3 && condition4) 
     ||!(condition5 && condition6)) { 
    doSomethingAboutIt(); 
} else { 
    doSomethingElse(); 
} // if-else 

Pour Delphi et C#, les opérateurs logiques de connexion viennent au début de la ligne suivante.

Answer 16

Je suis un programmeur de fin de semaine donc, étant le seul à travailler sur les projets que je peux me permettre de ne pas suivre une convention de codage spécifique, j'ai de la chance.

En ce qui concerne la lisibilité du code, le code structural highlighting de Castalia est très utile. CnPack a une caractéristique similaire est que je ne me trompe pas.

Answer 17

Hah! Prends ça! ;)

try 
    if Condition1 
    or ( Condition2 
     and Condition3) then 
    begin 
     DoSomething 
     DoSomeMore; 
    end 

    else if Condition4 then // I only do this if the nested "if" has "case"-like characteristics 
    begin     // otherwise the if would obviously be indented and on its own line 
     DoSomethingElse; 

     if Condition5 then 
     begin 
      DoThisToo; 
      DoFoo; 
     end; 
    end 

    else 
    DoTheWholeShebang; 

    case Whatever of 
    A: DoIt; 

    B, C, D: 
     begin 
     DoSomethingSlightly; 
     MoreComplicated; 
     end; 

    else 
    begin 
     DoWhatever; 
     DoLastResort; 
    end; 
    end; 
except 
    on ESomeException do 
    begin 
     HandleIt; 
     raise; 
    end; 
    on ESomeOtherException do 
    DealWithIt; 

    else 
    DoWhateverItTakes; 
end; 

Étrangement cependant, lors de l'écriture dans les langues des accolades Je préfère aussi la mise en page de renfort arrière:

if (condition) { 
    doSomething; 
} else { 
    doSomethingElse; 
} 

Answer 18

laissez votre indent IDE pour vous dans la plupart des cas.

Answer 19

Je trouve le code plus lisible lorsque les mots mots (clé à la fois syntaxiquement et logiquement) sont exposés autant que possible.

Ceci est tellement important pour moi que parfois j'ai recours à (OMI) quelque chose d'assez peu conventionnel.

Voici ce qu'il obtient comme:

if (condition) then begin 
    statement; 
    ... 
    statement; end 
else begin 
    ... 
end; 

je l'avoue, cela peut le rendre un peu moins pratique pour modifier le code. C'est juste que je trouve le «balancement» end au milieu d'une déclaration if, et alignés même que le if, quelque peu confus. Si c'est end, ce doit être le dernier (pour l'instruction), sinon je m'attends à else ou au début de l'instruction suivante à cette position.

Et je ne le laisse généralement pas quand le bloc then est composé, mais le else est une seule instruction. Ce n'est jamais un gros problème avec moi pour inverser la condition et réorganiser les blocs. D'autant plus que je suis assez serré quand il s'agit d'envelopper une seule déclaration avec begin ... end s. À mon avis et à mon expérience, les début-fin abondants sont redondants plus souvent qu'autrement. Bien que je l'aime quand une déclaration a un mot-clé de fin explicite, donc case et repeat sont mes favoris de tous les temps. :)

Une chose sur if s (et while s pour cette question) est que dans le cas d'une condition je ne sais combien-decker j'ai tendance à placer then (do) sur la ligne suivante et aligné sur le démarrage mot clé de l'instruction .

Comme ceci:

if (some_long_conditional_expression) or 
    (some_other_long_conditional_expression) or 
    (some_even_longer_conditional_expression) 
then 
    Exit; 

En outre, il y a d'autres choses déjà mentionnées ici que je ne suis pas étranger à, comme else if doublé une face de (le cas échéant) ou for ... do with ... do try s (oui, ce nouveau peut avoir quelque chose à voir avec ma nature serrée mentionnée ci-dessus). Dans l'ensemble, je serais probablement trop sur la mise en évidence du code et l'indentation, en particulier ce dernier. Peut-être que si ce n'était pas pour l'indentation, je préférerais toujours distinguer les begin s.

Un autre point: le style de formatage d'une personne peut très probablement être causé par son style de programmation. Comme, certaines personnes détestent les routines très importantes et ont tendance à prendre en compte chaque fois que possible, tandis que d'autres préfèrent se concentrer sur le code lui-même et ne se soucient pas de ces différents blocs composés, ce qui peut entraîner des différences de formatage .