Je suis assez nouveau à la programmation et à l'apprentissage, j'ai vu différentes manières de formater le code, des commentaires, etc. et ont été recommandés sur différentes techniques.
Je programme surtout dans C #, C ++ et Java, donc je souhaite savoir quel est le meilleur moyen de mettre le code de mise en page afin que d'autres personnes où la suivi, elles seraient impressionnées par la simplicité et la facilité de la comprendre est.
13 Réponses :
La meilleure règle à suivre est: (et probablement la seule règle que tout le monde sera d'accord)
être cohérent!
Choisissez un style et collez-le avec. Mettez toujours vos accolades au même endroit. Utilisez des conventions de nommage similaires. Ne mélangez pas les onglets et les espaces, etc ...
cela étant dit. Il est également une bonne idée d'essayer de suivre les conventions déjà en place pour une langue.
Lorsque vous travaillez sur une équipe avec des gens, assurez-vous que vous êtes tous d'accord sur un style et de rester en contact avec elle. Si vous ne le faites pas, souvent, un développeur reformatera un fichier avec leur formateur automatique, puis vous pouvez avoir des centaines de petits conflits qui n'étaient que causés par des espaces.
Bonne réponse. J'ai essayé d'impliquer que dans mon commentaire, mais je n'ai pas pensé que ma version était suffisamment bonne pour être une réponse.
@MJB Je suis prêt à parier que c'est la seule "bonne" réponse. Personne ne sera jamais d'accord sur le style 100%. Mais les gens conviendront que vous devriez toujours être cohérent.
Certaines choses sont raisonnablement objectives. Par exemple, la plupart des gens conviennent que les fichiers Java doivent contenir des pauses de ligne et ne pas être un fichier entier sur une ligne. Et si vous êtes d'accord avec et de justifier de manière objective que, il y a probablement plus de choses que vous pouvez justifier de manière objective. Tels que l'indentation (en l'utilisant vs non l'utilisant). Mais +1, car la cohérence est le facteur le plus important.
Vous devriez mentionner que vous devez être cohérent dans un référentiel source pour être lisible comme des commits / diffs. Douleur majeure si vous ne le faites pas.
Soyez cohérent et avoir un outil pouvant formater des sources en fonction de la norme choisie.
Bonne réponse - Les gens devraient prendre les parties audacieuses au cœur ...
@Marius merci! Je suis d'accord.
"Un développeur reformatera un dossier avec leur format automatique ..." J'ai vu cela arriver quelque part auparavant. :)
@Bill, haha, c'est exactement ce que je pensais quand j'ai tapé cette dernière partie de ma réponse.
J'ai donné plus de pensée que cela mérite probablement, mais je suis respectueusement en désaccord. Le formatage automatiquement (mais aveuglément) est beaucoup plus nocif que la mise en forme manuelle que vous s'il vous plaît. Le formatage constant est un effet secondaire du codage minutieux, pas une règle à suivre. J'irais aussi loin que l'autoformatère est un outil avancé à ne pas utiliser légèrement (bien que dans les cas où un style soit convenu, il peut être rendu inoffensif).
J'envoie des nouveaux membres de l'équipe à cette question après des boules (par exemple, une question de production qui ne peut être retrouvée à un seul commit). Il a amélioré considérablement les problèmes de production de débogage dans mes équipes. WhitSpace est important et il y a exactement une bonne façon de traiter avec elle. La réponse acceptée est fausse.
Les choses les plus importantes sont que
Tout le monde aura ses propres nuances. Si votre patron indique que vous-êtes - utilisez des onglets, vous utilisez des onglets. Si la Convention de la société est de 4 espaces sur le code compilé et 2 sur les fichiers de méta-données, c'est ce que vous faites.
Mais soyez cohérent et assurez-vous qu'il est lisible. La lisibilité est le seul critère significatif.
chose presque tout le monde sera d'accord sur:
pour code> DÉCLARATIONS LOOP) LI>
- Indencer le corps de tous les blocs (tout ce qui est à l'intérieur
{} code>) par un onglet ou quatre espaces (votre choix) li>
- Mettez une nouvelle ligne après une fermeture
} code> qui termine un bloc (à quelques exceptions près) li>
ul> Il y a beaucoup plus de choses que ce que certaines équipes insisteront sur la cohérence, mais ces éléments du formatage du code sont universels. P>
Il y a essentiellement deux façons de traiter avec Si code> bloque et quelque chose avec le même format ( pour code>, tandis que code>, en utilisant p> if (condition) {
/* code */
} else if (condition2) {
/* code */
} else {
/* code */
}
Je ne dirais pas d'espaces après que les virgules sont universels. Je connais beaucoup de gens qui les haïssent ...
En outre, celui-ci: "Mettez une nouvelle ligne après une fermeture } " Je ne peux pas être d'accord avec cela 100% du temps.
@Kendrick, ces personnes devraient être battues avec le Cluebat. (Je n'ai jamais rencontré quelqu'un que les espaces évoqués après des virgules).
Je suis d'accord sur les espaces après des virgules, mais je do aime mettre sinon si et sinon après une corde de fermeture - je trouve cela aide à garder le connecté des blocs évidents.
+1 Bien que je préfère la 2e option, où il est plus apparent où le {est fermé et ce que le} se ferme.
Newline après la fermeture } n'est pas non plus universel lorsqu'il s'agit de faire des boucles. Je mets le pendant sur la même ligne que la fermeture } .
Je ne conviens pas que vous avez besoin de quatre espaces pour indenter le corps d'un bloc, et ce n'est certainement pas universel. Et j'accepte qu'une nouvelle ligne après une fermeture } est souvent bonne, mais je ne le ferai pas entre } catch (//... ou } else {. Ce n'est certainement pas universel.
Deux choses manquantes. (Soyez cohérent était couvert par une autre réponse.) L'autre chose est après un bloc de code logique, envisagez une nouvelle ligne supplémentaire ou deux d'espaces, de séparer visuellement les choses à l'écran.
Il existe de nombreux styles ou règles de codage autour. Je pense que personne ne sera impressionné par la mise en page ou l'espacement et payer plus d'attention au code lui-même. Les outils peuvent convertir d'un style de codage à une autre (embellissement de code) afin que vous puissiez choisir de manière assez en toute sécurité. Comme Jjnguy dit, le plus important est d'être cohérent.
Le langage de programmation blanche . Une langue qui n'a que des espaces blancs
Il y a toujours un dans la foule.
Ceci est un sujet assez controversé (et subjectif), il n'ya donc pas de réponse "correcte". Cependant, mes conseils utilisent avec parcimonie verticale, car trop de cela réduit la quantité de code que l'on peut voir à l'écran à l'écran à un moment donné.
i Personnellement, j'aime utiliser des espaces horizontaux pour rendre le code plus lisible comme suit:
public void MyMethod( int param1, double param2 ) {
if ( param1 < param 2 ) {
member.OtherMethod( param1 );
}
}
Personnellement, je dirais que le contraire, utilisez des espaces verticaux chaque fois que vous devez délimiter un paragraphe logique ou un groupe, mais je suis d'accord - ne mettez pas autant de code dans une méthode que vous finissez par sortir de l'écran de la plupart des méthodes. Ne jetez pas la lisibilité pour le cramming de code, il suffit de mieux.
J'utilise des lignes vides pour séparer les blocs logiques dans la même portée, alors je suis d'accord là-bas. Mettre des bretelles d'ouverture sur la même ligne qu'un bloc me donne un espace supplémentaire pour travailler avec, cependant.
En général, Whitaespace est votre ami. Ajoutez-le sans que ce soit le code plus lisible. WhitSpace compile au code le plus efficace possible: Aucun!
En général, et c'est subjectif ... p>
Bretelles bouclées ouvertes et fermées (par exemple, {et}) Allez sur une ligne par elles-mêmes. (Exception pour JavaScript, où la corde bouclée ouverte se passe sur la ligne qui crée le bloc.) P>
laisser une ligne vierge entre les méthodes. P>
Si cela aide la lisibilité, laissez une ligne blanche entre Propriétés. P>
Ce n'est pas strictement un problème de blancheur, mais déclarez seulement une variable par ligne. Ne empilez pas les variables dans les déclarations. P>
int i, j; // stacked declaration - don't do this!
Soyez cohérent, même lors de la modification d'un autre code de développeurs. Si les normes indentées (le cas échéant) de votre projet ne prescrivent pas comment formater votre code ou que vous n'utilisez pas un outil automatique comme Narrange , ou Resharper , puis essayer de rester avec le formatage utilisé par l'autre développeur. Oui, allumez-vous des indicateurs d'espace blanc si vous devez (pour le débat sur l'onglet vs. espaces)
WhitSpace n'est pas le facteur principal de la création de code lisible. En effet, je ne serais jamais "impressionné par la manière dont la simple et facile à comprendre est" en raison de l'utilisation de l'espace blanc de l'auteur. Je pourrais aller dans l'autre sens et penser que certains codes sont très illisibles en raison d'une mauvaise utilisation de WhitSpace, mais au mieux, vous allez me chercher à ne pas être déçu de vous.
La réelle lisibilité provient du code modularisé et auto-documentant. Il évolue de la cohérence, de la dénomination intelligente des champs et des fonctions et des principes de conception (en particulier la séparation des préoccupations). Ces choses m'impressionneront. Pour WhitSpace, j'ai des formateurs auto-formateurs.
Quant aux suggestions sur les meilleures pratiques avec WhitSpace, je pense que les autres réponses ont tous les bons points couverts.
Je vous recommande de lire code complet et Clean Code . Ces livres vous apprendront au sujet du code de formatage, de commentaire et de nombreux autres sujets.
garder vos diffs propres.
Faites ce que vous aimez avec WhitSpace dans les restrictions suivantes:
pourquoi?
Le facteur le plus important dans le traitement de WhitSpace n'est pas la lisibilité des fichiers eux-mêmes, mais la lisibilité des diffs. Les diffs sont les choses que vous allez regarder lorsque la sueur froide est ruisselant votre colonne vertébrale et la pensée semble plus difficile que d'habitude.
Les deux règles ci-dessus assurent que les diffs sont propres et lisibles. Être cohérent dans la façon dont vous traitez avec des espaces blanche, mais il est infaillible que dans un monde parfait. C'est une bonne chose à rechercher, mais pas aussi importante que de garder la diffusion propre.
Comme optimisation, vous pouvez essayer de mettre d'accord sur le style de code avec d'autres afin de ne pas perdre de temps à vous conformer à 1 et 2.
C'est un bon point et j'ai violé le n ° 1 quelques fois. Il a généralement fait une douleur majeure plus tard.
Certaines choses à faire: assurez-vous de rechercher un débordement de pile pour plus d'exemples avec des étiquettes similaires.
Qu'est-ce qu'un bon programmeur ressemble?
https://stackoverflow.com/questions/563036/what-is-elegant-code
Stuff à ne pas faire:
https://stackoverflow.com/questions/237719/ plus-frustrant-programmation -style-youve-rencontré
Il n'y a pas de formatage "meilleur", mais si vous utilisez le même formatage que la plupart des autres programmeurs, il leur facilite la lecture de votre code, et il vous est plus facile de lire leur code!
Quelques directives pour savoir comment d'autres programmeurs utilisent des sapes blanches (du monde de Java):
J'ai essayé d'ajouter une balise "subjective", mais ne peut pas à cause de 5 limites de balise. Cependant, pas que les réponses seront quelque peu subjectives!
Il existe exactement N "meilleurs" façons de le faire, où n est le nombre de personnes que vous posez. Je suppose que vous obtiendrez une poignée de grandes suggestions ici; Choisissez lequel vous préférez et collez-vous. La cohérence facilite la lecture, mais n'impressionnera jamais les futurs programmeurs. D'autre part, si vous changez d'utilisation de l'utilisation des espaces, ces futurs programmeurs qui viennent pour résoudre votre code vous détesteront.
Essayez
WhitSpace pour la programmation. C'est bien."Je veux savoir quel est le meilleur moyen de créer un code de mise en page afin que, si d'autres personnes pour y passer, elles seraient impressionnées par la simplicité et facile à comprendre." Lorsque les futurs programmeurs passent sur votre disposition de code, WhitSpace sera le moindre de leurs préoccupations.
Il m'intéresse toujours une question quand une réponse à une question quelque peu subjective est acceptée si vite ...
@Mark, j'ai aussi été surpris.
Tout ce que j'ai déjà connu, mais personne n'a jamais souligné l'importance d'être cohérent. Alors juste, c'est de dire que j'ai posé une question et j'ai répondu.
@MJB: Je dirais que c'est quelque chose de plus proche du journal (n) ^ 2 ...
@RCIX: D'accord ... Y a-t-il des maths pour prouver que, ou ne pas aimer mon chiffre rond?
@MJB: Pas de mathématiques pour le prouver, mais j'ai observé qu'il y avait généralement plusieurs styles pour une langue donnée et que les gens adhèrent à (une petite variation de) une de ces. :)
@RCIX: C'est bon, je venais de désordre avec vous.
J'ai nommé la question de la réouverture car elle a reçu une réponse soutenue par des faits et une expertise (mine) qui est objectivement et de manière provoquée. Le fait qu'il y ait aussi beaucoup de bavardage subjectif (ennuyeux) sur le style de code est sans importance et aucune bonne raison de fermer la question.