Interpréter le code source des autres [fermé]

Remarque: je suis au courant de cette question. Cette question est un peu plus spécifique et approfondie, cependant, se concentrant sur la lecture du code réel plutôt que sur le débogage ou la question de l'auteur.

En tant qu'étudiant dans un cours d'informatique de niveau d'introduction, mes amis me demandent parfois de les aider dans leurs tâches. La programmation est quelque chose dont je suis très fier, donc je suis toujours heureux d'obliger. Cependant, j'ai généralement du mal à interpréter leur code source.

Parfois, cela est dû à un style étrange ou incohérent, parfois à des exigences de conception étranges spécifiées dans la mission, et parfois c'est simplement à cause de ma stupidité. En tout cas, je finis par ressembler à un idiot regardant l'écran pendant plusieurs minutes en disant "Euh ..."

Je vérifie généralement les erreurs courantes en premier - les points-virgules ou les parenthèses manquants, en utilisant des virgules au lieu des opérateurs d'extraction, etc.

Le problème vient quand cela échoue. Souvent, je ne peux pas passer au travers d'un débogueur parce que c'est une erreur de syntaxe, et je ne peux souvent pas demander à l'auteur parce qu'il / elle-même ne comprend pas les décisions de conception.

Comment lisez-vous généralement le code source des autres? Lisez-vous le code de haut en bas ou suivez-vous chaque fonction comme on l'appelle? Comment savoir quand dire "Il est temps de refaçonner?"

Premier conseil: utilisez un IDE (ou un très bon éditeur :)) pour repérer les erreurs de syntaxe, les parenthèses mal placées et autres erreurs triviales.

Deuxième étape: formater automatiquement tout le code dans un format avec lequel vous vous sentez à l'aise. On pourrait penser que cela n'a pas beaucoup d'importance, mais étonnamment, c'est le cas.

N'ayez pas peur de renommer des variables locales si elles sont mal nommées. (Si vous avez accès au système complet, vous pouvez renommer n'importe quoi et vous devriez.)

Ajoutez-vous des commentaires lorsque vous découvrez ce que fait une certaine fonction / méthode.

Sois patient. Comprendre le code extraterrestre n'est pas facile, mais il y a toujours un moment décisif où la plupart des pièces du puzzle se mettent soudainement en place. Jusque-là, tout le travail et la corvée sont difficiles, j'ai peur. La bonne nouvelle est qu'avec la pratique, ce moment eureka arrivera plus tôt.

Puis-je dire que je pense que vous adoptez la mauvaise approche avec cela. Si les gens se tournent vers vous pour obtenir de l'aide avec leur code, je pense que vous avez la responsabilité de vous retourner et de leur dire de vous expliquer leur code. Vous pouvez corriger leurs erreurs pour eux, et ils peuvent apprendre quelque chose (par cœur), s'ils peuvent repérer leurs propres erreurs (avec votre aide), ils en apprendront probablement plus. De plus, vous gagnerez une expérience plus large de la façon dont différentes personnes abordent le codage (ce qui vous permettra à son tour de lire / comprendre plus de code) - un cycle vertueux ...;)

Je crois que cette capacité est un mélange d'expérience et de talent. Nous avons eu des employés qui pourraient résoudre plus ou moins n'importe quoi si nous leur demandions de faire quelque chose à partir de zéro, tout en étant complètement incapables de trouver des bogues évidents dans des morceaux de code qu'ils n'avaient pas écrits. Et, simultanément, nous avons eu des employés auxquels nous ne ferions pas confiance avec quoi que ce soit de plus que la conception de base, mais qui pourraient plonger dans le code des autres et traquer les problèmes en peu de temps.

Cela dit, la façon d'aborder cela est de changer le code. Reformatez-le comme vous en avez l'habitude, changez le nom des variables en quelque chose qui vous semble logique, ajoutez des commentaires si le code n'est pas clair. S'il vous a demandé de l'aide, vous devriez simplement aller de l'avant et changer les choses jusqu'à ce que vous déceliez le problème. Ensuite, laissez à votre ami le soin de corriger le code d'origine ou d'utiliser le vôtre.

Tout d'abord, s'il y a des erreurs de syntaxe, il vous suffit de lire attentivement les erreurs du compilateur. Souvent, une ligne est mise en surbrillance comme une erreur, mais c'est en fait la ligne précédente qui a l'erreur.

Sachez que, pour un étudiant d'introduction, il peut y avoir des artefacts d'édition qui empêcheront la compilation du programme qui ne peuvent pas être vus. Par exemple, j'ai vu une fois un étudiant (pas un des miens) qui a utilisé la barre d'espace au lieu de revenir: son code avait l'air normal sur un éditeur qui se terminait après 80 colonnes (l'étudiant était très patient), et le code a même fonctionné jusqu'à ce qu'il ajoute un //commentaire de style " ", qui a commenté tout le reste du programme. De même, si vous copiez des exemples de code à partir d'un site Web, il y a souvent des caractères non imprimables qui sont également copiés (selon la façon dont le site Web a formaté le code). En cas de doute, retapez une ligne sans copier-coller. [C'est assez incroyable, mais je l'ai vu se produire beaucoup plus récemment.]

Pour les erreurs de compilation désagréables, vous devrez peut-être développer le programme, en créant un nouveau fichier et en tapant tout le code au fur et à mesure. Assurez-vous de compiler après chaque étape principale avant de passer à la suivante.

OK, qu'en est-il s'il n'y a pas d'erreurs de syntaxe? Il est alors temps de parcourir le code! Vous pouvez utiliser un débogueur pour cela, mais passer des appels à printftout le code est également très efficace. Par exemple, s'il y a une forboucle, ajoutez une instruction print pour le compteur de boucles. Dans le cas de forboucles imbriquées , vous pouvez constater que la mauvaise variable est incrémentée.

L'avantage d'utiliser printfs est sa capacité à "compresser" dans le temps / l'espace ce que vous regardez actuellement. Lorsque vous accédez à un débogueur, vous voyez également beaucoup d'état non pertinent et cela peut être plus fastidieux. De plus, sans voir l'historique de ce qui a été imprimé sur la console, vous risquez de manquer certains modèles. Le point ici est que le débogueur et printfs sont des techniques complémentaires, et ni l'un ni l'autre n'est toujours meilleur que l'autre.

Enfin, demandez simplement à votre ami ce qui se passe! Au lieu de le regarder et de dire "euh", demandez-leur ce qu'ils font: "maintenant que fait n-il?" En démarrant la boîte de dialogue, ils peuvent finir par répondre à leur propre question, ou vous pouvez vous rendre compte que la façon dont ils ont conceptualisé le programme avait un défaut, ce qui peut vous conduire à une solution.

Comme indiqué ailleurs, tout cela s'améliore avec l'expérience. Même si je programme depuis 20 ans, ce n'est qu'au cours des 5 dernières années que j'ai travaillé avec des étudiants que je me suis amélioré pour les aider à corriger leurs erreurs.

Je déteste dire ça, mais il n'y a pas de solution miracle ici.

Franchement, si j'étais assez clairvoyant pour pouvoir comprendre ce que les autres voulaient dire lorsqu'ils écrivaient ce qu'ils faisaient, même dans 10% des cas, je gagnerais sans l'ombre d'un doute des millions à ce jour.

Sur une note plus pratique, l'utilisation d'un IDE intelligent est l'étape 1.

L'étape 2 serait d'exécuter doxygen ou quelque chose de similaire pour comprendre la hiérarchie du code source.

L'étape 3 consiste à trouver des fonctions d'ancrage ou des objets, des éléments qui traitent votre ligne de commande ou votre fichier, puis exécutent la logique.

Parallèlement à l'étape 3, suivez les informations globales si vous les utilisez. Demandez également à vos amis s'ils utilisent un algorithme spécifique connu - lire l'algorithme (s'il en existe un) avant de regarder le code est toujours bénéfique.

En un mot: l'expérience, plus vous en acquérez, plus vous en apprenez sur les meilleures pratiques et pouvez juger / comprendre le code des autres. Cela ne vient pas automatiquement, au lieu de cela, cela ne vient souvent que de la même erreur!

Cela dit, il est essentiel que les programmeurs apprennent à commenter correctement leur code, car lorsque vous regardez le code, il est souvent le résultat d'un processus de réflexion majeur qui est souvent très difficile à extrapoler à partir du code. Quelques commentaires, un fichier texte avec des idées de conception peut faire la différence entre comprendre le code et le mal comprendre complètement.

On m'a souvent demandé la même chose dans le laboratoire de l'école. Habituellement, la question commençait par "Comment puis-je corriger cette erreur de compilation?" donc je suis devenu assez bon pour repérer les pendants else, les points-virgules manquants et autres. (Les macros sont également amusantes à déboguer - #define CUBE(x) x * x * xc'est une erreur que nous sommes tous destinés à faire.) Un avantage que j'avais était que j'avais suivi les mêmes cours avec les mêmes professeurs, donc j'étais déjà familier avec les exigences.

Le processus que j'ai trouvé le plus efficace consiste à garder une boîte de dialogue active. Vous ne voulez pas écrire le programme pour eux, car c'est eux qui doivent apprendre. Cela signifie que vous devez être sur le même ordinateur avec eux. Au laboratoire, je venais vers leur ordinateur. J'essaierais de leur faire repérer l'erreur, en commençant par le message du compilateur. (Nous utilisions C.) Commencez par le numéro de ligne et indiquez où le message et l'erreur correspondent. S'il y a plusieurs erreurs identiques, je leur demanderais ce qui était similaire à ces deux erreurs.

L'idée est d'aider à guider l'autre élève. Réécrire leur code pour eux ne les aidera pas à apprendre.

Les erreurs de syntaxe sont beaucoup plus faciles à trouver que les erreurs logiques. Si la plupart de leurs problèmes sont liés à la syntaxe, recherchez un IDE, copiez et collez leur code dedans et corrigez les erreurs. Les erreurs logiques sont beaucoup plus difficiles. Je ne sais pas pourquoi vous dites que vous ne pouvez pas leur demander d'expliquer leur code. J'ai trouvé beaucoup d'erreurs logiques en expliquant le code à quelqu'un d'autre.