Commentaires «//…» à la fin du bloc de code après}

18

Fermé . Cette question est basée sur l'opinion . Il n'accepte pas actuellement les réponses.

Voulez-vous améliorer cette question? Mettez à jour la question afin d'y répondre avec des faits et des citations en modifiant ce message .

Fermé il y a 4 ans .

J'ai souvent vu de tels commentaires utilisés:

function foo() {
   ...
} // foo

while (...) {
   ...
} // while

if (...) {
   ...
} // if

et parfois même jusqu'à

if (condition) {
   ...
} // if (condition)

Je n'ai jamais compris cette pratique et ne l'ai donc jamais appliquée. Si votre code est si long que vous devez savoir quelle est cette fin, }alors vous devriez peut-être envisager de le diviser en fonctions distinctes. De plus, la plupart des outils de développement sont capables de passer au support correspondant. Et enfin le dernier est, pour moi, une violation claire du principe DRY; si vous modifiez la condition, vous devez vous rappeler de modifier également le commentaire (sinon cela pourrait devenir compliqué pour le responsable, ou même pour vous).

Alors pourquoi les gens l'utilisent-ils? Faut-il l'utiliser, ou est-ce une mauvaise pratique?

source-code comments

— gablin
source

En PHP, j'utilise la syntaxe alternative pour les structures de contrôleif(condition): ... else: ... endif;

— systemovich

@Geoffrey van Wyk - vraiment? Je n'ai jamais vu personne utiliser ces fichiers en dehors des fichiers modèles. Ils sont extrêmement atypiques, mais pour chacun le leur, je suppose.

— Craige

4

@Craige: Toute construction de langage supportée nativement par PHP n'est pas "Extrêmement Unstandard" - l'interpréteur PHP définit ce qu'est le "standard".

— Billy ONeal

Ada a des marqueurs spécifiques pour la fin de la plupart des constructions: if ... then ... end if; while ... loop ... end loop; procedure Foo is ... end Foo;. Je trouve que cela aide à la lisibilité (et il est vérifié par le compilateur, ce qui n'est pas le cas).

— Keith Thompson

32

Je dirais que si votre code est si long que vous ne pouvez pas facilement suivre vos accolades, votre code doit être refactorisé, pour la plupart des langues.

Cependant, dans les langages de modèles (comme PHP), cela pourrait être valide, car vous pourriez avoir un grand bloc de code HTML qui sépare le début et la fin de la condition ou de la structure de la boucle.

— Matt Ellen
source

5

Point complètement valide pour PHP, si vous utilisez PHP mélangé avec du HTML. 1 point pour Gryffondor.

3

Même avec PHP comme langage de template mélangé avec HTML, vous pouvez toujours mettre en retrait. Vous ne devriez pas non plus utiliser d'accolades lorsque vous utilisez PHP comme langage de modèle, mais plutôt les constructions while(): endwhile;et foreach(): endforeach;etc. etc.

— Htbaa

9

Je ne vois pas vraiment pourquoi vous ne devriez pas refactoriser le PHP. Probablement dans une autre langue.

— Tom Hawtin - tackline

@Htbaa: Je ne peux pas croire que j'utilise PHP depuis tout ce temps et que je ne les connaissais pas. Merci! En ce qui concerne l'indentation, je préfère garder le HTML conditionnel indenté comme le reste de la page, plutôt que dans la ligne du PHP qui le crée.

— Matt Ellen

3

@Tom: J'ai ri, mais je me sens coupable. : P

17

C'est une odeur de code et généralement une gueule de bois d'un style de code à l'ancienne. Avant le refactoring des IDE décents était plus difficile et pas aussi courant qu'aujourd'hui, les méthodes étaient donc plus longues et ces commentaires étaient là pour aider à mieux les naviguer.

— Alb
source

15

Il s'agit d'une horrible pratique rendue obsolète par de nombreux facteurs.

La plupart des IDE modernes mettent en évidence l'accolade correspondante lorsque le curseur est sur l'un ou l'autre des symboles.
Si vous codez proprement, vous trouverez rarement un endroit où votre méthode comporte plus de 10 lignes.

Je remarque que beaucoup de programmeurs Java ont cet état d'esprit, et cela rend le code Java très sale et détourne l'attention du code et vers les commentaires.

Je recommande fortement de ne pas l'utiliser.

4

J'ai un collègue (développeur java) qui fait ça. Sauf au lieu de // pour et // s'il utilise // rof et // fi. Ça me rend fou et il le fait partout.

— Jay

Oui, j'en ai eu un qui a insisté dessus. AAAAAGHHHHH.

— Rig

2

Cela n'a vraiment rien à voir avec Java ou les programmeurs Java, et ce n'est pas courant ou une chose standard de facto à faire lors de la programmation en Java.

— Jesper

1

+1 000 pour "est une horrible pratique".

— scunliffe

6

Le code est lu 10 fois plus qu'il n'est écrit.

Si cela facilite la lecture, faites-le.

Je suggérerais également à quiconque fait cela de chercher d'autres moyens de faciliter la lecture. Les techniques de refactoring, les crochets sur différentes lignes, etc. que d'autres personnes ont mentionnées sont toutes bonnes. Il est également bon de diviser les choses en différentes fonctions, méthodes ou classes afin que le code soit auto-commenté. Il existe également des moyens d'éliminer la plupart des "si" et de placer les boucles "pour" dans des endroits évidents, éliminant ainsi la nécessité de tout cela.

Mais parfois, les gens apprennent. Si c'est quelque chose qu'ils font qui rend vraiment le code plus lisible, encouragez-le, puis encouragez également d'autres pratiques. Les personnes qui apprennent méritent et bénéficieront d'encouragements, quelle que soit la façon dont elles commencent. Dire "c'est mauvais" n'est pas aussi utile que dire "cette autre chose est meilleure".

— Lunivore
source

6

C'est mauvais. Même les manuels de niveau débutant ne font pas cette atrocité. "Le code est lu 10 fois plus qu'il n'est écrit" ... Raison de plus de ne pas perdre le temps du lecteur avec ce code cru.

— Thomas Eding

@trinithis Que faire si vous avez une instruction switch de 20 cas? Parfois, vous devez prendre en charge 20 options différentes, et il est préférable de les regrouper en un seul endroit plutôt que de les «refactoriser» dans un schéma de prise de décision à plusieurs niveaux.

— quant_dev

je crois que c'est une pratique des codeurs qui sous-estiment leurs pairs :) que les autres ne sont pas assez intelligents pour lire le code à moins. en général, je suis contre cette pratique, mais bon si quelqu'un le fait parce qu'il y a une jungle de} s qui le rend à peine lisible. je ne fais pas ça de toute façon!

— WinW

1

@trinithis Il ne s'agit pas de savoir si c'est mauvais ou non, mais de trouver des moyens efficaces d'aider les gens à s'améliorer afin qu'ils grandissent. Être efficace> avoir raison. C'est aussi une chose parfaitement sensée à faire si, par exemple, vous refactorisez du code hérité qui est encore plus un gâchis. Parfois, de mauvaises choses peuvent faire de meilleures étapes intermédiaires et conduire à quelque chose de mieux encore.

— Lunivore

1

@trinithis Désolé, je ne peux pas comprendre ce que vous voulez dire quand tout est sur une seule ligne comme ça. Je pense avoir mentionné qu'il existe également d'autres façons de refactoriser le code que les développeurs pourraient apprendre.

— Lunivore

4

J'ai une grande base de code (C ++) pleine de ce genre de chose:

int Class::AccessorMethod(void)
{
    return privateValue;
}//end AccessorMethod

Pour quelque chose d'aussi petit, je dirais que cela va au-delà de "l'odeur de code" en "puanteur de code". Surtout dans un IDE où je peux faire correspondre l'accolade de fermeture avec une frappe pour trouver l'accolade d'ouverture. Étant donné une méthode plus longue, je prendrai toujours l'accolade correspondant au commentaire du terminal. De tels commentaires me distraient et j'ai tendance à les considérer comme du bruit.

— PSU
source

Hum, je suppose que je n'ai pas de mise en forme sur ce site; chaque accolade doit être sur sa propre ligne, tout comme le corps de la méthode.

— PSU

En C ++, j'ouvrirai souvent un espace de noms anonyme en haut pour des trucs d'implémentation cachés. Ensuite, à un moment donné, je ferme cette accolade et il est utile de savoir ce que signifie l'accolade rapprochée ici.

— CashCow

4

En C ++, il y a deux suspensions où cela est toujours utile et le conseil de "diviser votre code" ne tient pas nécessairement:

Pour les espaces de noms. Un espace de noms peut englober un fichier entier, et cette dernière parenthèse peut parfois décourager les gens, donc l'ajout d'un commentaire pour indiquer que la parenthèse est la fermeture d'un espace de noms est utile. Pour le style de codage particulier de mon entreprise, cela est important car nous n'indentons pas les espaces de noms car il a été décidé qu'une telle indentation ne ferait que gaspiller de l'espace dans un fichier.
Pour les paires #ifdef / #endif. Parfois, il y a beaucoup de code pour la compilation conditionnelle, cela peut devenir désagréable avec l'imbrication, et l'éditeur que nous utilisons souvent de manière "lourde" élimine l'indentation, les commentaires sont donc utiles lors d'un bref aperçu.

— Joris Timmermans
source

+1 pour le commentaire de l'espace de noms et les raisons. C'est la seule fois que je fais ça et pour la même raison

— JohnB

+ longues instructions de commutation.

— quant_dev

1

Pour moi, le code doit être déroutant pour ajouter un commentaire comme celui que vous avez spécifié.

Si elle indique simplement // IF Statement. Ensuite, vous devez vous demander pourquoi il est là en premier lieu.

— TeaDrinkingGeek
source

Je suis d'accord, cela ressemble à une ligne qui a été commentée, plutôt qu'à une vieille école//endif

— StuperUser

1

L'alternative à voir ce que votre accolade ferme est d'avoir l'ouverture sur la même colonne que la fermeture. Je trouve cela beaucoup plus clair et plus lisible.

Le commentaire est utile lorsqu'il serait normalement difficile à retracer car l'ouverture s'est produite il y a longtemps. Cela ne devrait normalement se produire que pour un espace de noms (en particulier celui anonyme en C ++, utilisé pour les détails d'implémentation dans l'unité de compilation). Dans la plupart des autres cas, ce que vous fermez devrait être évident.

— Vache à lait
source

1

Il s'agit en grande partie d'un vestige de l'ancien temps de travail dans des fenêtres de terminal de 80 x 24 caractères, surtout si vous utilisiez un éditeur de fenêtres comme EVE. Même maintenant, je fais la plupart de mon travail dans une session de terminal en utilisant vim, et je peux diviser la session en trois ou quatre sous-fenêtres, donc je ne peux vraiment voir que quelques lignes à la fois.

Cela dit, je n'ai jamais vraiment apprécié la convention, même si cela aurait sauvé mon bacon à plus d'une occasion. Je le vois juste comme du bruit. Si vos boucles ou conditions conditionnelles deviennent si importantes, oui, vous voudrez peut-être envisager une refactorisation.

— John Bode
source

0

vous donnez essentiellement toutes les raisons valables de ne pas l'utiliser. Chaque programmeur décent devrait les appliquer. Alors pourquoi les gens l'utilisent-ils? Parce qu'ils font mal et ne savent pas mieux.

— stijn
source

euh, expliquez le downvote s'il vous plaît. Je n'ai pas seulement inventé cette réponse, elle découle d'une expérience de la vie réelle: mon collègue qui est assis à quelques mètres à côté de moi a programmé pour plus de 10 oreilles comme ça et n'avait aucune idée de pourquoi c'est mal jusqu'à ce que je lui explique .

— stijn

Peut-être qu'il a été utilisé dans certains manuels, donc un tas de gens sont sortis de l'université en l'utilisant? Il pourrait avoir sa place dans un texte d'introduction. Également raisonnablement valide dans un préprocesseur, en particulier dans # ifdef / endif, y compris les gardes

— Martin Beckett

Commentaires «//…» à la fin du bloc de code après} - bon ou mauvais? [fermé]