Guide de style D/Phobos

Question

Je viens de commencer à regarder la source phobos, et elle est jonchée de plusieurs styles différents et d'un code commenté.

Le guide de style sur le côté web est très faible, et je ne ai trouvé des liens cassés à partir de 2006 et un autre de 2004 ...

Y at-il une version plus récente, guide plus complet disponible?

PS: A l'origine a demandé au groupe de discussion D.learn, mais comme je ne l'ai pas eu de réponse, je pensais que je pourrais essayer ici, même si elle est peut-être un coup de feu dans l'obscurité

Answer 1

Tout ce qui existe est hors Guide de date et ne devrait plus exister. Je ne crois pas qu'il y ait une sorte de guide de style D qui soit considéré comme valable, et je ne pense pas que Walter Bright, Andrei Alexandrescu, etc. en veulent un. Aussi, si je me souviens bien, dans C++ Coding Standards: 101 Rules, Guidelines, and Best Practices, Herb Sutter et Andrei ont dit que les guides de style étaient une mauvaise idée (ou du moins que certains étaient vraiment spécifiques), mais je devais sortir le livre pour être sûr de ce qu'ils disaient . Je doute donc que Phobos (dont Andrei est responsable) aurait un guide de style; Je n'en suis certainement pas au courant. Il y a peut-être quelques lignes directrices pour le code de mise en forme qui va dans Phobos (comme faire ressembler votre code au reste du module ou quelque chose comme ça), mais quelqu'un comme Andrei ou l'un des autres développeurs Phobos devrait y répondre. Certainement, avec environ 15 développeurs différents travaillant sur Phobos, vous aurez forcément plusieurs styles différents dans le code s'il n'y a pas de guide de style forcé. Donc, je ne crois pas qu'il y ait vraiment un style de codage recommandé pour D ou Phobos. Si je comprends bien, les gens derrière D ne sont pas particulièrement en faveur des guides de style, et ils n'ont certainement pas poussé un. Donc, il n'y en a pas vraiment en ce moment, et je ne m'attends pas à ce qu'il y en ait un dans le futur. D'accord, je suis allé voir exactement ce que Herb Sutter et Anderi Alexandrescu ont dit au C++ Coding Standards: 101 Rules, Guidelines, and Best Practices. Ce n'est pas exactement parce qu'ils sont contre les normes de codage, mais contre des normes particulièrement restrictives qui imposent des goûts personnels ou des pratiques obsolètes. Je ne vais pas citer le tout ici (c'est un bon livre, et vous devriez probablement le prendre de toute façon), mais voici quelques points clés. Ne pas spécifier combien indenter, mais indenter pour montrer la structure.

N'appliquez pas une longueur de ligne spécifique, mais gardez les longueurs de ligne lisibles.

Ne pas surlégaliser la dénomination, mais faites-nous une convention de nommage cohérente.

Ne précisez pas les styles de commentaires (sauf si les outils extraient certains styles dans la documentation), mais écrivez des commentaires utiles.

Quelques exemples qu'ils ont donné que

• placement de Brace ne devrait pas d'importance, mais il doit être cohérent et lisible.
• Sur les espaces par rapport aux tabulations, ils ne semblent pas se soucier de savoir si la norme de codage en dit long.
• Ils sont contre la notation hongroise en C++ mais pensent qu'il pourrait être utile dans des langages moins sécurisés.
• Ils s'opposent totalement à l'application d'une seule instruction return dans une fonction.Quoiqu'il en soit, ils pensent que la mise en forme doit être cohérente dans un fichier source. Évidemment, Phobos ne s'en tient pas nécessairement à ce point, mais Andrei n'a fait qu'évoquer sur le forum certaines des conventions qui ont tenu et visaient à en imposer peut-être certaines (le message actuel est archivé here). Cependant, bien que Phobos soit open source et que chacun soit libre de soumettre des correctifs, sachez que c'est l'API qui est destinée à la consommation publique. Seuls les développeurs Phobos ont besoin de pour regarder le code (au moins si les documents sont correctement complétés) - ils sont certainement les seuls qui vont travailler dessus directement - donc il n'y a pas besoin d'une norme de codage cotée en bourse même s'ils en utilisent un. On dirait qu'ils pourraient utiliser plus de cohérence et qu'ils travaillent peut-être là-dessus, mais tout ce que ça va faire pour les tierces parties, c'est de le rendre plus lisible. Personne d'autre n'a vraiment besoin de savoir ce qu'est la norme (bien que si vous avez regardé assez de code suivant une norme, vous pourriez comprendre au moins plus ou moins ce que la norme a dit).

  Comme D en général, il sont certaines conventions qui sont considérés comme de bonnes pratiques (telles que l'utilisation généralement auto au lieu de spécifier un type, à moins que vous avez réellement spécifier le type), mais aussi avec C++, vous peut coder avec n'importe quel style de codage que vous voulez, et les développeurs D ne sont pas assez dictatoriaux pour essayer d'imposer un style sur toute la communauté D.

Answer 2

Les choses ont tellement changé que je pense que je devrais répondre à cette question. Vous pouvez voir le guide de style D actuel here, et il est maintenant à jour. Il a quelques règles de formatage (par exemple, pas de tabulation et chaque niveau d'indentation est de 4 espaces), mais presque toutes les règles concernent les conventions de nommage (par exemple, les noms de types sont supposés utiliser PascalCase, alors que les variables et fonctions sont supposées utiliser camelCase). Donc, l'accent est mis sur ce à quoi devrait ressembler l'API et non sur la façon dont le code devrait être formaté. Et comme je l'ai détaillé dans ma réponse précédente, il ne sera jamais possible que les développeurs de Phobos essaient de mandater un style de formatage officiel pour l'ensemble de D. En l'état, il y a beaucoup de programmeurs D qui ne suivent même pas les conventions de nommage dans le guide de style officiel. Il est possible que des directives de mise en forme plus restrictives soient mises en place sur Phobos dans le futur (cela a été discuté mais jamais fait) afin de clarifier le style des soumissionnaires et d'éviter les disputes sur le formatage du code. (Cela est devenu un problème depuis que nous avons migré vers github et le nombre de soumissionnaires a considérablement augmenté), mais à ce stade, il revient principalement à s'assurer que le code dans un module est formaté de manière cohérente. Mais encore une fois, même si des règles de formatage plus restrictives étaient exigées pour Phobos, cela serait spécifique à Phobos et non à la communauté D dans son ensemble. Et il y a beaucoup trop d'opinions différentes sur la façon dont le code doit être formaté pour une norme de formatage à l'échelle de la communauté.