Importance du code de mise en forme Specificly espacement

Question

Quelle est l'importance pour la lisibilité que le code soit sous cette forme:

public void DoStuff() 
{ 
    var v = new Object(); 
    v.PropertyID = "abc"; 
    v.Type = "abc"; 
    v.Style = "abc"; 
    v.SetMode(Mode.Abc); 
    v.Draw(); 
} 

contre

public void DoStuff() 
    { 
    var v = new Object(); 
     v.PropertyID = "abc"; 
     v.Type = "abc"; 
     v.Style = "abc"; 
     v.SetMode(Mode.Abc); 
    v.Draw(); 
    } 

J'ai tendance à aimer le premier meilleur style, il fait des choses facile à lire, comment pourriez-vous guider doucement les gens vers le premier et loin de ce dernier? Ou ne le feriez-vous pas?

Answer 1

Est-ce que les gens écrivent réellement du code qui ressemble à ce dernier? C'est un cauchemar de maintenabilité.

Je dirais que ce n'est pas si important quelles sont vos conventions de formatage de code - plus que vous les suivez de manière cohérente. Le premier exemple n'est pas cohérent et donc illisible et impossible à maintenir.

Si vous rencontrez des problèmes pour orienter les utilisateurs vers la cohérence, demandez-leur d'imaginer revenir à un code très incohérent en un an.

Answer 2

Le format est très important mais pas essentiel. J'ai tendance à être légèrement ennuyé si je vois du code comme celui-ci. Si vous prenez le temps d'écrire le code, assurez-vous de prendre le temps de le formater correctement.

Answer 3

La deuxième façon ne fait pas vraiment de tabulation. L'éviter.

Je pense aussi que les gens ont tendance à se laisser emporter par le formatage. Dans un mois un autre gars viendra et voudra ce format

public void DoStuff() 
    { 
    var v    = new Object(); 
     v.PropertyID  = "abc"; 
     v.Type   = "abc"; 
     v.Style   = "abc"; 
     v.SetMode  (Mode.Abc); 
     v.Draw   (); 
    } 

Cela devient assez stupide et plutôt difficile à travailler.

Si les gens codent comme ça, questionnez leur raisonnement et leur capacité de programmation.

Answer 4

Dans le deuxième exemple, vos accolades ne sont pas indentées de manière égale.

L'espacement est important pour moi de lire le code. Si vous écrivez du code chez moi, je devrai probablement le lire à un moment donné. Si vous ne formatez pas votre code, j'utiliserai un autoformatter pour obtenir ce dont j'ai besoin.

Answer 5

Le style est extrêmement important lorsque vous travaillez en équipe. Donc, peu importe le style que vous choisissez, assurez-vous que tout le monde est d'accord ... et ensuite appliquez l'accord. Définissez votre IDE pour formater votre code automatiquement .. et assurez-vous que l'IDE de tout le monde est le même.

Answer 6

Si vous voulez être aimable, donnez-les Code Complet à lire. Si vous voulez être méchant, d'introduire des bugs sublte comme celui-ci dans leur code:

if (x==y); 
    DoSomething(); else 
DoSomethingElse(); 
while(Whatever) 
SomeFunction(); 

(S'ils trouvent le bug en moins d'un jour, vous ne pas être assez sublte.)

Answer 7

I préfère ton espacement, même si je le ferais un peu différemment. Je crois que votre question la plus importante est de savoir comment convaincre quelqu'un que votre approche est la meilleure: Le formatage du code peut être très subjectif. Certaines personnes s'opposent parce que cela prend trop de temps pour aller droit. D'autres objectent parce que l'équipe n'a pas de normes de codage. Certains objets parce que le sentiment qu'il est entassé dans leur cou.

La meilleure méthode consiste à travailler avec votre équipe pour parvenir à un consensus selon lequel votre approche particulière est la meilleure pratique.Cela est vrai si vous êtes le chef de file, ou si vous êtes un contributeur individuel. Une fois qu'un consensus d'équipe est généralement accepté (il peut ne pas être universel), alors je trouve que les révisions de code sont le meilleur endroit pour s'assurer que les pratiques d'équipe sont suivies. Je suggère que vous trouverez la pression des pairs est le moyen le plus efficace d'encourager les autres à suivre une bonne pratique acceptée. Le corralling est souvent vrai; il est difficile pour une personne de conduire ce genre de chose en équipe sans consensus.

Voici quelques-unes de mes réponses StackOverflow liées

• Do any other developers get yelled at for making every thing public?
• How would you format/indent this piece of code?
• How do you perform code reviews?

Answer 8

Si elle était mon code, je le ferais comme ceci:

public void DoStuff() 
{ 
    var v = new Object(); 

    v.PropertyID = "abc"; 
    v.Type  = "abc"; 
    v.Style  = "abc"; 

    v.SetMode(Mode.Abc); 
    v.Draw(); 
} 

De cette façon, il est clair quelles lignes sont des affectations de propriétés et lesquelles sont des appels de méthode. Je suis également d'accord avec la réponse de Jamie, qui dit que "le format est très important mais pas essentiel". Ce qui compte, c'est que la mise en forme n'est pas si mauvaise qu'elle nuit à la capacité des autres à la lire. Je ne crois pas qu'une poignée d'onglets supplémentaires ou de nouvelles lignes va faire une énorme différence pour un programmeur compétent la plupart du temps.

Answer 9

Comme d'autres l'ont dit, le premier exemple est la norme; le second en diffère.

De même, assurez-vous que tous ceux qui travaillent sur le même ensemble de fichiers ont la même convention pour ce qu'est un 'onglet'. Il est préférable de définir cela comme un certain nombre d'espaces et de s'assurer que les éditeurs de texte et les EDI sont d'accord.

Cela devient gênant lorsque trois ou quatre personnes travaillent dans le même référentiel SVN et éditent chaque fichier avec différentes conventions d'espacement.