Pourquoi tant de code est comme ça ? - page 3
Vous manquez des opportunités de trading :
- Applications de trading gratuites
- Plus de 8 000 signaux à copier
- Actualités économiques pour explorer les marchés financiers
Inscription
Se connecter
Vous acceptez la politique du site Web et les conditions d'utilisation
Si vous n'avez pas de compte, veuillez vous inscrire
Mais cela ne signifie-t-il pas que s'ils demandent de l'aide pour la syntaxe ou la logique, le code ne sera pas " ...syntaxiquement et logiquement correct ;" ?
Oui, vous avez raison. Mais dans le contexte de la discussion sur les styles/pratiques de codage plus (ou moins) efficaces, l'aspect le plus important est que le code soit syntaxiquement et logiquement correct, quel que soit le style de codage utilisé. Je suppose qu'une autre façon de le dire est que le style doit céder la place à un code syntaxiquement et logiquement correct - la question principale n'est pas de savoir si le code est beau et facilement lisible, mais plutôt s'il est syntaxiquement et logiquement correct pour effectuer la tâche pour laquelle il est écrit. :)
Je suis également d'accord sur les // commentaires. On ne peut jamais avoir trop de // commentaires, à la fois pour rafraîchir l'esprit du programmeur original quant aux particularités des différentes parties du code et pour aider les autres à comprendre le code après son achèvement/implémentation.
Oui, vous avez raison. Mais dans le contexte d'une discussion sur les styles/pratiques de codage plus (ou moins) efficaces, l'aspect le plus important est que le code soit syntaxiquement et logiquement correct, quel que soit le style de codage utilisé. Je suppose qu'une autre façon de le dire est que le style doit céder la place à un code syntaxiquement et logiquement correct - la question principale n'est pas de savoir si le code est beau et facilement lisible, mais plutôt s'il est syntaxiquement et logiquement correct pour effectuer la tâche pour laquelle il est écrit. :)
Ah OK, je vois ce que vous voulez dire... Un code bien présenté ne sert à rien s'il ne fonctionne pas... mais il est peut-être plus facile à corriger ?
Je pense que la plupart des styles de codage permettent autant de lisibilité que le codeur le souhaite ou en a besoin. Je ferme mon code lorsqu'il est terminé et fonctionnel, mais il est facile de le rouvrir avec quelques interlignes si je dois le partager ou en discuter. Je pense qu'un format de codage doit permettre d'identifier facilement une accolade manquante et les paires if else lorsqu'il s'agit d'un arbre if else complexe à branches multiples. Je n'ai jamais adopté le style K&R et j'aimerais donc voir comment les codeurs du style K&R s'y prennent.
Je ferme mon code lorsqu'il est terminé et fonctionnel, mais il est facile de le rouvrir avec quelques interlignes si j'ai besoin de le partager ou d'en discuter.
Pourquoi le fermer ? Je ne comprends vraiment pas l'intérêt de fermer le code. Si vous avez besoin de l'ouvrir pour le partager/discuter, qu'est-ce que cela implique ?
Je pense qu'un format de codage devrait faciliter l'identification d'une accolade manquante, et l'identification des paires if else lorsqu'il y a un arbre if else complexe avec plusieurs branches. Je n'ai jamais adopté le style K&R et j'aimerais donc voir comment les codeurs du style K&R s'y prennent.
Pour le style K&R, l'accolade inférieure s'aligne sur la correspondance de la condition. J'utilise personnellement
1. Une indentation cohérente
2. Pour les clauses d'une seule déclaration , soit vous les mettez entre crochets et en retrait, soit vous les faites suivre de la condition sans crochets.
3. Utilisez un éditeur de programmeur décent qui fait correspondre les accolades.
Les accolades correspondantes ne sont pas un problème - la plupart du noyau linux est écrit dans ce style, et c'est le standard Java. Bien que je puisse voir l'attrait du style Allman car, avec le style K&R, j'insérais souvent une ligne blanche supplémentaire après la condition pour désencombrer le code. Hmm je pourrais être converti :)
Pourquoi le fermer du tout ? Je ne comprends vraiment pas l'intérêt d'un code écrasé. Si vous avez besoin de l'ouvrir pour partager/discuter, qu'est-ce que cela implique ?
Pour le style K&R, le support inférieur s'aligne avec la condition correspondante. J'utilise personnellement
1. Une indentation cohérente
2. Pour les clauses d'une seule déclaration , soit vous les mettez entre crochets et en retrait, soit vous les faites suivre de la condition sans crochets.
3. Utilisez un éditeur de programmeur décent qui fait correspondre les accolades.
Les accolades correspondantes ne sont pas un problème - la plupart du noyau linux est écrit dans ce style, et c'est le standard Java. Bien que je puisse voir l'attrait du style Allman car, avec le style K&R, j'insérais souvent une ligne blanche supplémentaire après la condition pour désencombrer le code. Hmm je pourrais être converti :)
Je le ferme simplement pour qu'il prenne moins de place à l'écran. J'aime voir autant de choses que possible en même temps sur l'écran. Je n'ai pas besoin d'un comparateur d'accolades, je le formate de façon à ce que si je place un curseur derrière une accolade et que je le fais courir verticalement le long des lignes avec la touche fléchée, lorsqu'il touche une autre accolade, celle-ci constitue sa paire.
Dans cette section du code, il est facile de voir que la troisième paire else correspond au premier if, que la deuxième paire else correspond au deuxième if et que la première paire else correspond au troisième if, car les accolades derrière chaque else sont alignées verticalement derrière l'accolade if correspondante. De même, il est facile de voir quels sont les if qui n'ont pas de else, car chaque crochet if s'aligne verticalement avec son crochet de fermeture correspondant dans le cluster derrière le else. Je ne suggère pas que tout le monde devrait formater le code de cette façon, juste parce que je l'aime, mais pour moi, c'est compact et logique.
Je ne peux pas répondre à cette question pour tous les codeurs qui utilisent k&r. Honnêtement, plus je regarde votre format, plus je l'aime. Si j'avais adopté le style Allman, je me verrais bien utiliser votre version modifiée. Les accolades s'alignent les unes sous les autres, ce qui évite que les accolades ouvrantes et fermantes occupent une ligne entière. Vous pouvez passer votre curseur le long du i sur le if et trouver les accolades manquantes, sans vous soucier des conventions de taille de tabulation/indentation, mode compact {voir la plupart de vos codes à l'écran}. Alors oui, c'est plutôt cool, c'est juste qu'au premier abord, parce que je n'y suis pas habitué, cela m'a semblé confus. Et c'est le cœur du problème ici.
Pour moi, il semble que beaucoup de codeurs américains adoptent le style [KnR & Allman] alors que le style Whitesmiths semble populaire chez les Européens. Whitesmith est également le style par défaut de Mt4. Il n'y a rien de mal à ces styles, mais lorsque j'aide quelqu'un, je dois sans cesse me rappeler d'ignorer mon style K&R et de penser plus Whitesmith. Ça ou utiliser un formateur de code.
Pourquoi quelqu'un voudrait-il écrire des "arbres complexes if else" me dépasse. Lorsque quelqu'un laisse tout l'espace blanc et le formatage dans un if_nest complexe, on dirait qu'il a essayé de concevoir un Snake | Spaghetti | ZigZag à travers la page. Le premier if commence à la ligne 1 et se termine à la ligne 300, environ 150 ou 50 % de ces lignes sont tenues par des accolades. Au lieu des "arbres if else complexes", pourquoi ne pas simplement créer une fonction. Puis laissez la ligne 1 se terminer sur la ligne 1 avec if( false ){ return ; }.
Merci ubzen, je suis content que quelqu'un aime mon format lol. J'utilise souvent if else, probablement parce que lorsque j'ai commencé à coder, quelqu'un m'a dit que if else rendait le code rapide, alors j'ai pris l'habitude de le faire de cette façon.
Merci ubzen, je suis content que quelqu'un aime mon format lol. J'utilise beaucoup if else, probablement parce que lorsque j'ai commencé à coder, quelqu'un m'a dit que if else rendait le code rapide, alors j'ai pris l'habitude de le faire de cette façon.
Il n'y a rien de personnel
C'est dans des moments comme celui-ci qu'il aurait été bon d'avoir un standard formel auquel tout le monde travaille... alors nous aurions tous fait la même chose et nous aurions tous aimé votre code. Et avant que vous ne demandiez, non, je vais m'en tenir à mon style Whitesmiths... au moins je sais comment l'appeler maintenant, merci ubzen.