Dominic  Feeney

Dominic Feeney

1647499758

Qu'est-ce Que Le Débogage? Comment Déboguer Du Code Pour Les Débutants

Comment le débogage a commencé

Les mots « bogue » et « débogage » dans les logiciels sont communément attribués à l'amiral Grace Hopper . Véritable légende, elle a écrit le premier compilateur qui ait jamais existé.

Dans les années 1940, alors qu'elle travaillait sur un ordinateur en cours de développement pour la marine américaine à l'Université de Harvard, ses associés ont découvert un papillon de nuit (un véritable insecte) coincé dans un relais qui a fait planter l'ordinateur.

Lors de la résolution de ce problème, elle a remarqué qu'ils "déboguaient" le système.

Si vous êtes amateur d'étymologie, vous serez peut-être intéressé par le fait que le mot "débogage" semble avoir été utilisé comme terme dans l'aéronautique avant d'entrer dans le monde des ordinateurs.

Et apparemment, il y a une sorte de preuve que même Thomas Edison l'a utilisé dans le sens d'"erreur technique" en 1878.

Mais ce n'est pas le but de cet article. Le fait est que le débogage est une partie essentielle du développement logiciel. Ça l'a toujours été et ça le sera probablement toujours.

Heureusement, cependant, les cas où nous devons supprimer les insectes réels des ordinateurs sont plutôt rares, maintenant.

Pourquoi devriez-vous en savoir plus sur le débogage ?

Les bogues et les erreurs sont si susceptibles de se produire dans le développement de logiciels car il s'agit d'une activité tellement conceptuelle et abstraite.

En tant que développeurs, nous travaillons avec des informations. Nous l'organisons, le déplaçons, le mettons à jour et le modifions, l'envoyons à des endroits, puis le recevons à nouveau.

Nous travaillons tout le temps avec des informations, mais pas directement avec elles. L'information n'est pas "réellement" là dans l'ordinateur, du moins pas dans le format auquel les utilisateurs pensent.

Dans l'ordinateur, il n'y a que des impulsions électriques, qui sont ensuite résumées en 1 et 0, puis à nouveau résumées dans les informations avec lesquelles nous travaillons.

Pour interagir avec les ordinateurs et les utiliser, nous utilisons des langages de programmation. Ceux-ci fournissent des niveaux d'abstraction à partir des tâches réelles exécutées par l'ordinateur et des représentations des informations que nous gérons.

La programmation peut être une activité très abstraite, et il est très facile de perdre rapidement de vue quelle est la tâche réelle de l'ordinateur ou sur quelles informations nous agissons dans une certaine ligne de code. Et à partir de là, il est facile de donner de fausses instructions à l'ordinateur et de rater la cible que nous recherchons.

Une blague dans le monde du développement logiciel est que les développeurs passent normalement 5 minutes à écrire du code et 5 heures à essayer de comprendre pourquoi les choses ne fonctionnent pas comme elles le devraient.

En tant que développeurs, peu importe à quel point nous devenons bons, nous allons passer d'innombrables heures à déboguer notre code, nous devons donc essayer de nous améliorer et de le faire plus rapidement.

Comment déboguer votre code

Le débogage peut être défini comme le processus consistant à trouver la racine d'un problème dans une base de code et à le résoudre.

Habituellement, nous commençons par réfléchir à toutes les causes possibles, puis testons chacune de ces hypothèses (en commençant par les plus probables), jusqu'à ce que la cause racine ultime soit trouvée. Ensuite, nous le corrigeons et veillons à ce que cela ne se reproduise plus.

Il n'y a pas de solution magique pour les bugs. Habituellement, il faut une combinaison de recherche sur Google, de journalisation de notre code et de vérification de notre logique par rapport à ce qui se passe réellement.

Bien qu'il existe de nombreux outils qui peuvent vous aider à déboguer, l'utilisation de ces outils n'est pas nécessairement la partie la plus difficile. Ce qui est difficile, c'est de vraiment comprendre les erreurs que vous obtenez et de vraiment comprendre quelle est la meilleure solution pour elles.

Commençons donc par parler d'abord de "l'état d'esprit de débogage", puis explorons quelques outils utiles que nous pouvons utiliser pour déboguer notre code.

Comment entrer dans un état d'esprit de débogage

Faites attention aux messages d'erreur

G-Wn7Seyn

Dans presque tous les environnements de développement, si votre code échoue, vous verrez probablement un message d'erreur qui (dans une certaine mesure) explique pourquoi votre code échoue.

Prenez ce code par exemple :

mickTheBug('Im a scary bug!')

const mickTheBug = message => console.log(message)

Ce code génère l'erreur suivante :

ReferenceError: Cannot access 'mickTheBug' before initialization
    at Object.<anonymous> (/home/German/Desktop/ger/code/projects/test.js:4:1)

Comme vous pouvez le voir, le message d'erreur indique clairement le problème et déclare même à quelle ligne il se produit ( test.js:4:1).

Cela peut sembler un conseil stupide, mais vous pourriez être surpris de voir combien de programmeurs ne lisent pas attentivement les messages d'erreur et réagissent simplement au bogue avec la première idée qui leur vient à l'esprit.

Les messages d'erreur sont là pour une raison, et c'est pour nous donner au moins une première idée d'où vient le problème.

Google Choses

ddqvW2927

Si le message d'erreur que vous obtenez n'est pas clair pour vous, ou si vous ne pouvez pas comprendre pourquoi vous l'obtenez, une bonne première étape serait de le rechercher sur Google.

L'une des nombreuses choses étonnantes à propos du codage est que la communauté en ligne est énorme. Il y a presque sûrement des tonnes de personnes qui ont déjà été confrontées au même bogue que vous, et qui l'ont résolu et expliqué pour que d'autres personnes n'aient pas à se débattre avec lui aussi.

Lors de la recherche sur Google, une bonne idée est d'être aussi détaillé que possible dans la recherche.
Suite à l'exemple précédent, j'utiliserais " javascript ReferenceError: Cannot access before initialization ". J'ai constaté que le fait de mentionner la technologie que vous utilisez dans la recherche vous donne des résultats plus précis.

J'ai également appris qu'il est important de supprimer des éléments qui ne sont que particuliers à mon code et non une erreur que tout le monde obtiendrait, comme le nom de ma fonction ( 'mickTheBug' ).

Une autre bonne idée est d'essayer d' utiliser des sources fiables et récentes . Fiable signifie soit une documentation officielle, soit des solutions qui ont été validées par d'autres. Récent signifie des solutions qui ont été mises en œuvre le plus récemment possible, car quelque chose qui fonctionnait il y a cinq ans n'est peut-être pas la meilleure façon de résoudre le problème en ce moment.

La documentation officielle doit toujours être la première chose à vérifier, que vous appreniez quelque chose de nouveau ou que vous traitiez une erreur.

Les documents officiels sont généralement la source d'informations la plus complète et la plus à jour pour un outil donné. Il peut parfois sembler fastidieux ou écrasant de parcourir autant d'informations techniques, mais à long terme, je pense que cela fait gagner du temps.

Le problème avec les documents officiels est qu'ils contiennent parfois tellement d'informations et qu'ils sont expliqués à un niveau si détaillé que c'est plus déroutant qu'explicatif.

Pour cette raison, je pense que c'est une bonne idée de toujours utiliser plus d'une source pour un sujet particulier, et "d'entendre des voix différentes" expliquer la même chose. Habituellement, ce n'est qu'après avoir lu la documentation, quelques articles et regardé quelques vidéos sur YouTube que j'ai l'impression de bien comprendre l'outil avec lequel je travaille.

Expliquez votre logique à une autre personne ou à un canard

lwjv2jUhM

J'ai déjà mentionné comment la programmation peut être une activité abstraite, ce qui permet de perdre facilement de vue les choses, de faire de mauvaises hypothèses et de mal interpréter les informations avec lesquelles nous travaillons.

Une bonne solution consiste à parcourir votre code ligne par ligne, en le lisant et en l'expliquant à voix haute au fur et à mesure. La technique du canard en caoutchouc est une façon populaire de le faire, mais vous pouvez choisir votre animal de compagnie préféré ou votre ami imaginaire. =P

L'idée est de vous forcer à lire votre code au lieu de simplement supposer que vous savez ce qu'il fait. De cette façon, vous pouvez vérifier la logique dans votre esprit par rapport à ce qui se passe réellement dans votre code.

Le fait que nous ayons tendance à supposer les choses et à ne pas prêter une attention particulière à chaque ligne de code est simplement la nature humaine. C'est un mécanisme qui nous aide à économiser de l'énergie et à faire les choses plus rapidement.

Mais lors du débogage, nous devons obliger notre cerveau à travailler avec nous et à être aussi présent que possible sur chaque ligne de code.

Affinez votre problème et comprenez où l'erreur est générée

aEKNV-Iju

Au fur et à mesure que votre base de code s'agrandit, il sera difficile d'analyser chaque ligne de code dans la recherche de votre bogue. C'est donc une bonne idée de diviser pour mieux régner, en commençant votre recherche dans les endroits les plus susceptibles de générer le problème.

Voyons cet exemple. J'ai une fonction qui prend un nombre et le renvoie multiplié par deux, et une autre qui imprime un prénom, un nom et le résultat de la fonction de multiplication.

const multiply = num => num*2

const mickTheBug = async (firstName, lastName, age) => {
  console.log(`My name is ${firstName} ${lastName} and the double of my age is ${multiply(age)}`)
}

mickTheBug('Mick', 10)

Le code a du sens et s'exécute sans générer d'erreur, mais le résultat que j'obtiens est My name is Mick 10 and the double of my age is NaN, ce qui n'est pas ce que je veux.

Ici, je peux voir que 10 c'est l'impression où lastNamedevrait être. Et comme les paramètres sont définis dans la ligne où la fonction est appelée.

C'est probablement une bonne supposition de commencer par vérifier si les paramètres ont été passés de la bonne manière. Et en effet, nous pouvons voir que lorsque j'ai appelé la fonction, je lui ai passé deux paramètres, Micket 10, et la fonction attend trois paramètres firstName, lastName, age.

Tapuscrit nous aurait facilement empêché de faire cette erreur. Plus sur cela plus tard. ;)

Encore une fois, c'est un exemple idiot, mais il illustre comment nous pouvons déduire d'où vient un problème, même si nous n'avons pas de message d'erreur pour nous aider.

Dans ces moments, essayez de vous poser les questions suivantes :

  • Comment puis-je savoir si je vois une erreur ?
  • Quelle contribution est-ce que je fournis ? D'où vient-il ? Cette entrée est-elle la même que celle attendue par la fonction ?
  • Quelle sortie est-ce que j'obtiens ? Comment l'entrée a-t-elle changé ?
  • Y a-t-il d'autres entités qui interagissent avec ce morceau de code ?
  • Ai-je changé quelque chose récemment qui aurait pu faire rompre le code ?

Faites une pause et pensez à autre chose

Ly_kXFJop

Les bogues comme les exemples que nous avons vus jusqu'à présent sont un jeu d'enfant à résoudre. Mais beaucoup d'autres ne le sont pas, et dans de nombreuses occasions, vous devrez vous battre avec des bogues pendant plusieurs heures (ou jours) jusqu'à ce que vous arriviez à une solution.

Dans ces occasions, je trouve qu'il est vraiment important de faire attention à votre état d'esprit. La programmation est une activité très mentale. Ainsi, la façon dont votre cerveau fonctionne à un certain moment ou la façon dont vous vous sentez affectera directement l'apparence de votre code et votre capacité à résoudre les problèmes de manière efficace.

Si vous passez des heures à lire, à répéter à haute voix les mêmes lignes de code, à googler, à passer en revue les questions de Stack Overflow, et que votre code échoue toujours, tôt ou tard, vous serez frustré et commencerez à vous mettre la pression.

Au fur et à mesure que vous essayez différentes solutions et que vous échouez encore et encore, votre souci du détail se diluera probablement et vous commencerez à sauter sur différentes idées et à essayer plusieurs choses à la fois.

Une fois que vous arrivez à ce point, la chose la plus sage à faire est d'aller vous promener ou de le laisser tranquille jusqu'au lendemain.

Si vous continuez dans cet état mental stressé et fatigué, vous ne trouverez probablement pas de solution. Et en plus, vous pourriez même aggraver le bug en touchant des choses qui n'y sont pas vraiment liées.

En laissant les choses tranquilles pendant un moment et en pensant à autre chose, notre cerveau continuera à travailler sur le problème en arrière-plan et à connecter les idées de manière "subconsciente" et créative.

À de nombreuses reprises, il m'est arrivé qu'une nouvelle solution me vienne à l'esprit lorsque je suis sous la douche ou dès que je vois à nouveau le problème le lendemain matin. C'est un de ces moments " Aha! ". C'était probablement juste devant vos yeux, mais parce que vous étiez fatigué et stressé, vous ne pouviez pas le voir.

Être concentré, bien reposé et détendu est la clé pour écrire un bon code et corriger les bugs de manière efficace. La frontière entre travailler dur et s'épuiser l'esprit est mince, mais il est important que nous y prêtions attention et que nous nous reposions chaque fois que nous en avons besoin.

Habituellement, je trouve un bon moment pour faire une pause lorsque je manque d'idées, ou que je commence à perdre ma concentration et à essayer différentes approches de manière impulsive et non systématique.

Aussi, gardez à l'esprit l'idée que les bogues ne font qu'une partie du développement logiciel. Cela ne veut pas dire que vous êtes nul en tant que développeur. Tout le monde a des bogues, même les meilleurs programmeurs. Alors détendez-vous et profitez de la situation pour apprendre quelque chose de nouveau.

Rechercher de l'aide

J'ai déjà mentionné l'importance des communautés en ligne et à quel point il est cool que nous puissions facilement trouver de l'aide pour presque tous les sujets en quelques secondes.

Avoir accès aux bonnes communautés, où vous pouvez demander et parler à des personnes expérimentées dans les outils que vous utilisez est vraiment, vraiment, vraiment utile.

Cela variera selon le type de domaine dans lequel vous travaillez et les outils que vous utilisez, mais pour moi, des sites comme freecodecamp , stackoverflow et les communautés Sack ou Dscord comme meetupjs ont fait une énorme différence.

Lorsque je pose des questions au sein de ces communautés, je trouve qu'il est important de garder à l'esprit ce qui suit :

  • Essayez d'être aussi détaillé que possible . Il n'est pas toujours facile de comprendre le code de quelqu'un d'autre simplement en le lisant, alors essayez d'expliquer sur quoi vous travaillez, ce que vous essayez de réaliser et quel est le problème auquel vous êtes confronté.
  • Montrez l' erreur exacte que vous obtenez.
  • Affichez le code associé qui, selon vous, est à l'origine de l'erreur.
  • Mentionnez les solutions que vous avez essayées jusqu'à présent et pourquoi elles n'ont pas fonctionné.
  • Enquêtez et montrez que vous avez fait des recherches sur le problème. Même si demander de l'aide est tout à fait acceptable, je pense qu'il faut d'abord évacuer les chemins les plus évidents et faciles avant de demander à quelqu'un d'autre de réfléchir à votre place. Cela signifie que vous avez analysé votre code, recherché le problème sur Google, lu d'autres solutions et de la documentation officielle, essayé de nombreuses approches et aucune d'entre elles n'a fonctionné. Ce n'est qu'alors qu'il est acceptable de demander de l'aide à quelqu'un d'autre. Je pense que c'est une question d'être capable d'apprendre et de résoudre des problèmes de manière indépendante, et aussi de respecter le temps des autres.
  • Mentionnez la documentation que vous avez consultée sur ce sujet et que dit cette documentation à ce sujet.
  • Donnez accès à votre base de code complète dans un référentiel en ligne.

Cela permettra à une autre personne de comprendre plus facilement votre problème et, espérons-le, de vous fournir des idées de solutions.

Si vous obtenez des réponses, il est important que vous y répondiez , soit en confirmant que la solution a fonctionné ou qu'elle n'a pas fonctionné et en expliquant pourquoi.

N'oubliez pas que la question que vous avez posée sera probablement stockée et disponible la prochaine fois que quelqu'un viendra chercher le même bogue. L'idée ici est de construire des connaissances et de les rendre accessibles à tous , pas seulement pour résoudre ce bogue particulier.

De plus, si vous finissez par trouver la solution vous-même, c'est une excellente idée de répondre à votre propre question et de partager la solution avec tout le monde.

Dans le même ordre d'idées, si vous participez à ces communautés en posant des questions, il serait bien que vous participiez également en répondant aux questions. Chaque fois que vous le pouvez et constatez que vous avez les connaissances, il est bon de donner en retour. ;)

Ma dernière réflexion à ce sujet est que la plupart des gens dans ce genre de communautés sont gentils, ouverts et très disposés à aider et à partager leurs connaissances. Mais comme dans n'importe quel autre domaine de la vie, vous rencontrez de temps en temps des personnes grossières, arrogantes ou même agressives.

Mon conseil ici est de ne pas laisser les autres vous intimider, même s'ils semblent avoir plus de connaissances que vous.

Personne n'est jamais né en sachant tout, et si vous avez fait vos recherches et travaillé sur le problème, vous avez tout à fait le droit de demander ce que vous voulez. Si d'autres personnes sont arrogantes ou grossières, cela parle mal d'eux, pas de vous.

Assurez-vous que le bogue est mort

xOmnh7_G7

La seule chose plus frustrante que de se battre avec un bogue coriace, c'est de le corriger pour découvrir plus tard que le bogue est toujours là. Ou pire encore, que plus de bogues ont été introduits dans votre code grâce à la "solution".

Pour éviter ce genre de situation, il est essentiel que vous testiez votre code. Et si vous pouvez le faire avec des tests unitaires automatisés, c'est encore mieux.

Idéalement, chaque section ou composant de votre base de code devrait avoir ses propres tests. Et ces tests doivent être exécutés à chaque fois qu'une modification est apportée à la base de code. De cette façon, et si le test est correctement écrit, nous pouvons remarquer un nouveau bug dès son introduction. Ce qui bien sûr facilite la recherche de sa cause et sa résolution.

Si vous n'avez pas de tests automatisés (vous devriez vraiment le faire si vous voulez créer un logiciel de qualité), testez au moins votre code manuellement, en reproduisant toutes les interactions possibles que l'utilisateur pourrait avoir avec lui, et assurez-vous que le bogue a bien été éliminé.

Écrire du code propre

Y4PKO37NS

La meilleure façon de lutter contre les bogues est d'éviter de les insérer en premier lieu. Écrire du code garanti sans bogue est impossible pour n'importe quel programmeur, mais il y a quelques choses que vous pouvez faire pour réduire les risques d'insertion de bogues.

Un bon point de départ sont les principes classiques DRY, KISS et SOLID.

Il existe des livres entiers écrits sur ces sujets, mais pour faire court, ce sont des principes qui visent à rendre les logiciels faciles à développer, faciles à comprendre et à entretenir, et aussi proches que possible de l'absence de bogues.

Ecrire le code SEC

Le principe DRY signifie "Ne vous répétez pas" . Cela signifie essentiellement que nous devons éviter la répétition du même code autant que possible.

Par exemple, si vous voyez que vous effectuez la même opération encore et encore sur différentes parties de votre code, une bien meilleure approche serait d'abstraire cette logique dans une fonction et d'appeler la fonction au lieu d'effectuer directement les opérations sur différents parties de votre code.

De cette façon, si un bogue ou un comportement inattendu se produit dans cette opération, nous savons qu'il n'y a qu'un seul morceau de code responsable, et pas beaucoup dispersés dans la base de code.

Écrire du code simple lorsque cela est possible

Le principe KISS signifie "Keep it simple stupid" . Au fur et à mesure qu'un projet logiciel grandit, il commence inévitablement à devenir de plus en plus complexe. Au fur et à mesure que de nouvelles fonctionnalités non planifiées sont ajoutées et que différents développeurs commencent à y travailler, différentes logiques et façons d'exécuter des tâches peuvent être mises en œuvre dans le même projet.

Cela rend le code plus difficile à comprendre, à maintenir et à utiliser. Et lorsque le code est difficile à comprendre, il devient très facile de faire de mauvaises hypothèses et d'insérer des bogues.

Nous devons toujours viser un logiciel facile à lire et à comprendre, avec une logique limpide et explicite pour tout le monde et pas seulement pour nous.

Gardez à l'esprit que quelqu'un d'autre à l'avenir devra peut-être travailler avec le code que vous avez écrit, alors faites en sorte qu'il soit facile pour cette personne de comprendre ce que vous faites. Même après quelques mois, vous ne vous souviendrez peut-être même pas de ce que vous avez essayé de faire avec cette fonction.

Gardez également à l'esprit qu'aucun logiciel ne reste le même pour toujours. La nature des logiciels est de changer et d'être améliorée par de nouvelles fonctionnalités, votre code doit donc être facile à modifier si nécessaire.

Et pour aller plus loin, vous devez modifier votre code chaque fois que vous pouvez trouver un moyen plus simple d'exécuter les mêmes tâches.

Peut-être qu'après avoir inclus quelques nouvelles fonctionnalités, le design que vous aviez en tête au départ n'est pas toujours la meilleure option. Une autre chose intéressante à propos du codage est que rien n'est gravé dans la pierre et que les choses peuvent être facilement inversées en cas de besoin. Alors profitez-en et habituez-vous à refactoriser constamment votre code à la recherche d'une approche plus simple.

Certains concepts pratiques qui aident à cela utilisent des noms de fonctions et de variables explicites, séparent les préoccupations en différentes fonctions et modules de code, et écrivent de courts commentaires pour expliquer votre code lorsque vos tâches sont inévitablement complexes.

Utiliser les principes SOLID

SOLID est un ensemble de principes qui s'appliquent principalement à la POO . Ils ont été établis par Robert C. Martin (qui se trouve également être l'auteur du manifeste agile ) dans ce livre sur la conception orientée objet.

  • S signifie "Single Responsibility", ce qui signifie qu'une classe doit avoir un et un seul emploi.
  • O signifie "Open Closed Principle", ce qui signifie que vous devriez pouvoir étendre le comportement d'une classe, sans le modifier.
  • L signifie "principe de substitution de Liskov", ce qui signifie que les classes dérivées doivent être substituables à leurs classes de base.
  • I signifie "Interface Segregation", ce qui signifie qu'un client ne devrait jamais être forcé d'implémenter une interface qu'il n'utilise pas, ou que les clients ne devraient pas être forcés de dépendre de méthodes qu'ils n'utilisent pas.
  • D signifie "Dependency Inversion Principle" ce qui signifie que les entités doivent dépendre d'abstractions et non de concrétions. Il stipule que le module de haut niveau ne doit pas dépendre du module de bas niveau, mais qu'il doit dépendre d'abstractions.

Comme mentionné, SOLID est plus applicable à la POO qu'à la programmation générale. Nous n'allons pas approfondir la POO dans cet article, mais il est toujours bon de connaître ces principes et de les garder à l'esprit.

Découvrons maintenant quelques outils que vous pouvez utiliser pour vous aider à déboguer votre code.

Outils de débogage technique

Il existe de nombreux outils que nous pouvons utiliser pour réduire les risques d'insertion de bogues dans notre code ou pour combattre plus efficacement les bogues existants.

À cet égard, nous allons jeter un œil à TypeScript , le populaire (et très utile) console.log et les débogueurs intégrés à VS Code et Chrome .

Ces outils et exemples seront centrés sur JavaScript, mais les principes s'appliquent à tout langage de programmation.

Vous devez également savoir que la plupart des éditeurs de code et des navigateurs Web ont aujourd'hui des débogueurs intégrés, mais nous allons passer en revue le code VS et Chrome car ils sont les plus populaires.

Et enfin, vous devez également savoir qu'il existe des outils de débogage spécifiques que vous pouvez utiliser pour déboguer des types d'applications spécifiques, comme les outils de développement React et Redux , qui sont des extensions de navigateur que vous pouvez installer pour vous aider à déboguer votre code plus efficacement.

Mais nous allons les examiner à l'avenir dans un article séparé sur la façon de déboguer une application React. ;)

Comment TypeScript aide à écrire du code propre

Je mentionne TypeScript comme premier outil, car il est étroitement lié à la section précédente sur l'écriture de code propre.

TypeScript ne vous fournit pas seulement un système de typage robuste pour JavaScript. Il ajoute également un compilateur qui vous aide à identifier les bogues et les idées fausses dans votre code avant même de l'exécuter. Il fournit une auto-complétion étonnante et peut être considéré comme un outil de documentation automatique.

Pour ne voir qu'un aperçu de ses avantages, revoyons l'exemple précédent dans lequel nous n'avons pas fourni les bons arguments à notre appel de fonction.

TYPESCRIPT1

Comme vous pouvez le voir ici, avant même d'exécuter le programme, TypeScript détecte immédiatement qu'il nous manque un argument et nous renvoie l'erreur suivante :

Expected 3 arguments, but got 2.ts(2554)
index.ts(6, 64): An argument for 'age' was not provided.

Ces types de notifications sont extrêmement utiles, en particulier lorsque vous travaillez sur de gros projets dans lesquels vous devez interagir avec de nombreuses API ou différentes sections de code.

Donc, de cette façon, si vous êtes habitué au JavaScript simple, TypeScript peut sembler inutile au début. Mais à long terme, cela vous fera sûrement gagner du temps et vous évitera d'insérer des bogues stupides dans votre code.

Comment utiliser Console.log pour déboguer le code

La journalisation de votre code dans la console est la méthode de débogage la plus basique et la première que nous apprenons à utiliser en tant que développeurs.

L'idée est d'imprimer la valeur des variables, des fonctions, des entrées et des sorties pour vérifier la logique que nous avons dans notre esprit par rapport à ce qui se passe réellement dans notre code. Cela nous aide également à voir quelles hypothèses erronées nous faisons.

Bien que ce soit un outil de base, nous pouvons faire des trucs sympas avec. Laisse moi te montrer.

Si nous appelons console.log, nous obtiendrons l'objet que nous transmettrons en tant que paramètre imprimé dans notre console.

const arr = []
console.log(arr) // []

const populateArr = (elem1, elem2, elem3) => arr.push(elem1, elem2, elem3)
console.log(populateArr) // [Function: populateArr]

populateArr('John', 'Jake', 'Jill')
console.log(arr) // [ 'John', 'Jake', 'Jill' ]

console.tableest idéal lorsque vous travaillez avec des tableaux ou des objets, car il définit les informations dans une table où vous pouvez facilement voir les clés/index et les propriétés/valeurs.

const arr = ['John', 'Jake', 'Jill']
console.table(arr)

//┌─────────┬────────┐
//│ (index) │ Values │
//├─────────┼────────┤
//│    0    │ 'John' │
//│    1    │ 'Jake' │
//│    2    │ 'Jill' │
//└─────────┴────────┘

const obj1 = {
  name: 'John',
  age: 30,
  job: 'Programmer'
}

const obj2 = {
  name: 'Jason',
  age: 32,
  job: 'Designer',
  faveColor: 'Blue'
}

const arr2 = [obj1, obj2]

console.table( arr2 )
// ┌─────────┬─────────┬─────┬──────────────┬───────────┐
// │ (index) │  name   │ age │     job      │ faveColor │
// ├─────────┼─────────┼─────┼──────────────┼───────────┤
// │    0    │ 'John'  │ 30  │ 'Programmer' │           │
// │    1    │ 'Jason' │ 32  │  'Designer'  │  'Blue'   │
// └─────────┴─────────┴─────┴──────────────┴───────────┘

Lorsque vous enregistrez plusieurs choses en même temps, cela console.groupnous donne une manière organisée de voir les choses.

const arr1 = [22, 23, 24]
const arr2 = [25, 26, 27]

console.group('myArrays')
console.log(arr1)
console.log(arr2)
console.groupEnd()


const obj1 = {
  name: 'John',
  age: 30,
  job: 'Programmer'
}

const obj2 = {
  name: 'Jason',
  age: 32,
  job: 'Designer',
  faveColor: 'Blue'
}

console.group('myObjects')
console.log(obj1)
console.log(obj2)
console.groupEnd()

// myArrays
//   [ 22, 23, 24 ]
//   [ 25, 26, 27 ]
// myObjects
//  { name: 'John', age: 30, job: 'Programmer' }
//  { name: 'Jason', age: 32, job: 'Designer', faveColor: 'Blue' }

console.assertest utile pour tester les conditions dans notre code. Il prend deux arguments : le premier est une condition et le second est le message qui se connecte si la condition est fausse.

const arr1 = [22, 23, 24]

console.assert(arr1.indexOf(20) !== -1, '20 is not in my array')
// Assertion failed: 20 is not in my array

console.warn and console.error are useful when debugging errors in our code. The first one will print the error with a yellow background and the second with a red background.

console.warn('No biggie') // No biggie
console.error(new Error('Error detected'))

// Error: Error detected
//     at Object.<anonymous> (/home/German/Desktop/ger/code/projects/test.js:6:15)
//     at Module._compile (node:internal/modules/cjs/loader:1101:14)
//     at Object.Module._extensions..js (node:internal/modules/cjs/loader:1153:10)
//     at Module.load (node:internal/modules/cjs/loader:981:32)
//     at Function.Module._load (node:internal/modules/cjs/loader:822:12)
//     at Function.executeUserEntryPoint [as runMain] (node:internal/modules/run_main:79:12)
//     at node:internal/main/run_main_module:17:47

How to Use Visual Studio Debugger

As our apps grow and start to get more complex, console.logging around becomes a not so efficient practice.

To help us in our fight against bugs, debuggers were developed. They are nothing more than programs that are able to read other programs and go through them line by line, checking whatever information we want along the way (such as the value of variables, for example).

The first example we're going to see is Visual Studio debugger.

To debug a Node.js app we don't need to install anything extra (assuming we have VS Code and Node installed in our computer), as the node debugger comes built-in in VS code.

Si vous déboguez dans un autre langage comme Python ou Java, vous devrez peut-être installer une extension VS spécifique avant d'exécuter le débogueur.

Pour commencer, il suffit de sélectionner le fichier que nous voulons déboguer et d'appuyer sur l'icône de bogue.

vsc1

Après cela, nous serons présentés avec l'écran suivant :

vsc2

Nous sélectionnerons "Exécuter et déboguer", qui exécutera simplement le programme dans l'éditeur pour nous.

Tenez compte du fait que vous pouvez également créer un launch.jsonfichier, qui est un fichier utilisé par le code VS pour "savoir" comment exécuter votre programme. Pour cet exemple simple ce ne sera pas nécessaire, mais sachez que cette possibilité existe.

Après avoir cliqué sur le bouton "Exécuter et déboguer", notre programme s'exécutera et nous arriverons à l'écran suivant :

vsc3

En haut à gauche, nous avons toutes les variables disponibles dans le programme, tant au niveau local que global.

vsc4

En dessous, nous aurons un espace où nous pourrons déclarer des expressions en particulier que nous aimerions regarder. Les expressions peuvent être n'importe quoi, comme des variables ou des fonctions particulières que vous aimeriez surveiller pour évaluer comment elles changent avec votre programme.

Par exemple, j'ai ajouté ma variable arret le code VS me montre la valeur de cette variable :

vsc5

Et en dessous, nous pouvons voir la pile d'appels (si vous ne savez pas ce que c'est , voici une vidéo géniale qui l'explique), les scripts qui sont chargés et les points d'arrêt que nous avons définis dans notre code (nous verrons ce que c'est en une seconde).

vsc6

Les points d' arrêt sont une grande partie de ce qui rend les débogueurs utiles. Comme leur nom l'indique, ce sont des points que vous pouvez déclarer dans votre code où le débogueur arrêtera d'exécuter le programme. Lorsque le programme s'arrête, vous serez en mesure de vérifier toutes les informations que nous avons mentionnées précédemment telles qu'elles sont à ce moment particulier.

Ainsi, les points d'arrêt nous permettent de voir les informations réelles avec lesquelles le programme travaille, sans avoir besoin de se connecter à la console. Plutôt cool!

Vous pouvez identifier un point d'arrêt par les petits points rouges qui apparaissent à gauche des numéros de ligne dans votre code (ou en consultant la section mentionnée ci-dessus).

Par défaut, lorsque vous exécutez le débogueur, un point d'arrêt est inséré dans la dernière ligne de votre code. Pour insérer de nouveaux points d'arrêt, cliquez simplement à gauche du numéro de ligne auquel vous souhaitez que le débogueur s'arrête.

vsc7

Maintenant, lorsque vous exécutez le débogueur, vous verrez qu'il y a une petite flèche vers la gauche au-dessus du premier point d'arrêt, indiquant que c'est là que l'exécution du programme s'est arrêtée.

vsc8

En haut de l'écran, nous avons les commandes , qui nous permettront de parcourir le programme en passant d'un point d'arrêt à un point d'arrêt.

vsc9

  • Le bouton Continuer exécute le programme et s'arrête uniquement sur les points d'arrêt définis par l'utilisateur.
  • Avec Step Over , s'il y a un appel de fonction, il l'exécute et renvoie le résultat. Vous n'entrez pas dans les lignes qui sont à l'intérieur de la fonction. Vous allez juste directement à la valeur de retour de la fonction.
  • Step Into va à l'intérieur de la fonction ligne par ligne jusqu'à ce qu'elle revienne, puis vous revenez à la ligne suivante juste après l'appel de la fonction.
  • Avec le bouton Step Out , si vous êtes entré dans une fonction, vous pouvez sauter l'exécution restante de la fonction et aller directement à la valeur de retour.
  • Restart exécute à nouveau le débogueur depuis le début et Stop quitte le débogueur.

Alors voilà, c'est un débogueur très puissant intégré à votre éditeur de code. Comme vous pouvez le voir, avec cet outil, nous pouvons vérifier de nombreuses informations en même temps, simplement en définissant des points d'arrêt où nous voulons et sans avoir besoin de console.logs.

Débogueur Chrome

Pour déboguer dans Chrome, nous commençons par ouvrir notre application dans le navigateur. Dans mon cas, j'ai créé un simple fichier HTML où mon fichier JS est lié (même fichier que l'exemple précédent).

Ensuite, nous ouvrons les outils de développement (ctrl+shit+i ou clic droit -> inspecter) et allons dans l' onglet " sources ".

Nous devrions voir quelque chose comme ça :

chromé1

Sur le côté gauche, nous pouvons voir les fichiers disponibles dans notre application (dans mon cas, il n'y a qu'un fichier HTML et le fichier JS.) Au milieu, nous pouvons voir le code de notre fichier sélectionné, et sur le côté droit, nous avons un ensemble d'informations très similaire à ce que nous avions dans VS Code.

Pour définir un point d'arrêt, nous devons cliquer en haut de la ligne dans laquelle nous voulons nous arrêter. Dans Chrome, les points d'arrêt sont identifiés par des flèches bleues en haut du numéro de ligne.

chromé2

Ensuite, si nous actualisons notre page, le script s'arrêtera au premier point d'arrêt et nous serons autorisés à le parcourir à l'aide des contrôles, qui fonctionnent exactement de la même manière que dans le code VS.

chromé3

Comme nous l'avons vu, les débogueurs de code Chrome et VS fonctionnent de manière très similaire, et celui que vous décidez d'utiliser n'est qu'une question de préférence.

Conclusion

Le débogage est un élément central de ce que nous faisons en tant que développeurs. Pour cette raison, je pense que c'est une bonne idée d'y penser et de le faire de manière efficace, au lieu de simplement réagir aux bugs au fur et à mesure qu'ils surviennent.

Comme nous l'avons vu, il y a beaucoup de choses que nous pouvons faire, à la fois d'un point de vue mental et technique, pour devenir de meilleurs débogueurs.

Link: https://www.freecodecamp.org/news/what-is-debugging-how-to-debug-code/

#debug #debugging #code 

What is GEEK

Buddha Community

Qu'est-ce Que Le Débogage? Comment Déboguer Du Code Pour Les Débutants
Dominic  Feeney

Dominic Feeney

1647499758

Qu'est-ce Que Le Débogage? Comment Déboguer Du Code Pour Les Débutants

Comment le débogage a commencé

Les mots « bogue » et « débogage » dans les logiciels sont communément attribués à l'amiral Grace Hopper . Véritable légende, elle a écrit le premier compilateur qui ait jamais existé.

Dans les années 1940, alors qu'elle travaillait sur un ordinateur en cours de développement pour la marine américaine à l'Université de Harvard, ses associés ont découvert un papillon de nuit (un véritable insecte) coincé dans un relais qui a fait planter l'ordinateur.

Lors de la résolution de ce problème, elle a remarqué qu'ils "déboguaient" le système.

Si vous êtes amateur d'étymologie, vous serez peut-être intéressé par le fait que le mot "débogage" semble avoir été utilisé comme terme dans l'aéronautique avant d'entrer dans le monde des ordinateurs.

Et apparemment, il y a une sorte de preuve que même Thomas Edison l'a utilisé dans le sens d'"erreur technique" en 1878.

Mais ce n'est pas le but de cet article. Le fait est que le débogage est une partie essentielle du développement logiciel. Ça l'a toujours été et ça le sera probablement toujours.

Heureusement, cependant, les cas où nous devons supprimer les insectes réels des ordinateurs sont plutôt rares, maintenant.

Pourquoi devriez-vous en savoir plus sur le débogage ?

Les bogues et les erreurs sont si susceptibles de se produire dans le développement de logiciels car il s'agit d'une activité tellement conceptuelle et abstraite.

En tant que développeurs, nous travaillons avec des informations. Nous l'organisons, le déplaçons, le mettons à jour et le modifions, l'envoyons à des endroits, puis le recevons à nouveau.

Nous travaillons tout le temps avec des informations, mais pas directement avec elles. L'information n'est pas "réellement" là dans l'ordinateur, du moins pas dans le format auquel les utilisateurs pensent.

Dans l'ordinateur, il n'y a que des impulsions électriques, qui sont ensuite résumées en 1 et 0, puis à nouveau résumées dans les informations avec lesquelles nous travaillons.

Pour interagir avec les ordinateurs et les utiliser, nous utilisons des langages de programmation. Ceux-ci fournissent des niveaux d'abstraction à partir des tâches réelles exécutées par l'ordinateur et des représentations des informations que nous gérons.

La programmation peut être une activité très abstraite, et il est très facile de perdre rapidement de vue quelle est la tâche réelle de l'ordinateur ou sur quelles informations nous agissons dans une certaine ligne de code. Et à partir de là, il est facile de donner de fausses instructions à l'ordinateur et de rater la cible que nous recherchons.

Une blague dans le monde du développement logiciel est que les développeurs passent normalement 5 minutes à écrire du code et 5 heures à essayer de comprendre pourquoi les choses ne fonctionnent pas comme elles le devraient.

En tant que développeurs, peu importe à quel point nous devenons bons, nous allons passer d'innombrables heures à déboguer notre code, nous devons donc essayer de nous améliorer et de le faire plus rapidement.

Comment déboguer votre code

Le débogage peut être défini comme le processus consistant à trouver la racine d'un problème dans une base de code et à le résoudre.

Habituellement, nous commençons par réfléchir à toutes les causes possibles, puis testons chacune de ces hypothèses (en commençant par les plus probables), jusqu'à ce que la cause racine ultime soit trouvée. Ensuite, nous le corrigeons et veillons à ce que cela ne se reproduise plus.

Il n'y a pas de solution magique pour les bugs. Habituellement, il faut une combinaison de recherche sur Google, de journalisation de notre code et de vérification de notre logique par rapport à ce qui se passe réellement.

Bien qu'il existe de nombreux outils qui peuvent vous aider à déboguer, l'utilisation de ces outils n'est pas nécessairement la partie la plus difficile. Ce qui est difficile, c'est de vraiment comprendre les erreurs que vous obtenez et de vraiment comprendre quelle est la meilleure solution pour elles.

Commençons donc par parler d'abord de "l'état d'esprit de débogage", puis explorons quelques outils utiles que nous pouvons utiliser pour déboguer notre code.

Comment entrer dans un état d'esprit de débogage

Faites attention aux messages d'erreur

G-Wn7Seyn

Dans presque tous les environnements de développement, si votre code échoue, vous verrez probablement un message d'erreur qui (dans une certaine mesure) explique pourquoi votre code échoue.

Prenez ce code par exemple :

mickTheBug('Im a scary bug!')

const mickTheBug = message => console.log(message)

Ce code génère l'erreur suivante :

ReferenceError: Cannot access 'mickTheBug' before initialization
    at Object.<anonymous> (/home/German/Desktop/ger/code/projects/test.js:4:1)

Comme vous pouvez le voir, le message d'erreur indique clairement le problème et déclare même à quelle ligne il se produit ( test.js:4:1).

Cela peut sembler un conseil stupide, mais vous pourriez être surpris de voir combien de programmeurs ne lisent pas attentivement les messages d'erreur et réagissent simplement au bogue avec la première idée qui leur vient à l'esprit.

Les messages d'erreur sont là pour une raison, et c'est pour nous donner au moins une première idée d'où vient le problème.

Google Choses

ddqvW2927

Si le message d'erreur que vous obtenez n'est pas clair pour vous, ou si vous ne pouvez pas comprendre pourquoi vous l'obtenez, une bonne première étape serait de le rechercher sur Google.

L'une des nombreuses choses étonnantes à propos du codage est que la communauté en ligne est énorme. Il y a presque sûrement des tonnes de personnes qui ont déjà été confrontées au même bogue que vous, et qui l'ont résolu et expliqué pour que d'autres personnes n'aient pas à se débattre avec lui aussi.

Lors de la recherche sur Google, une bonne idée est d'être aussi détaillé que possible dans la recherche.
Suite à l'exemple précédent, j'utiliserais " javascript ReferenceError: Cannot access before initialization ". J'ai constaté que le fait de mentionner la technologie que vous utilisez dans la recherche vous donne des résultats plus précis.

J'ai également appris qu'il est important de supprimer des éléments qui ne sont que particuliers à mon code et non une erreur que tout le monde obtiendrait, comme le nom de ma fonction ( 'mickTheBug' ).

Une autre bonne idée est d'essayer d' utiliser des sources fiables et récentes . Fiable signifie soit une documentation officielle, soit des solutions qui ont été validées par d'autres. Récent signifie des solutions qui ont été mises en œuvre le plus récemment possible, car quelque chose qui fonctionnait il y a cinq ans n'est peut-être pas la meilleure façon de résoudre le problème en ce moment.

La documentation officielle doit toujours être la première chose à vérifier, que vous appreniez quelque chose de nouveau ou que vous traitiez une erreur.

Les documents officiels sont généralement la source d'informations la plus complète et la plus à jour pour un outil donné. Il peut parfois sembler fastidieux ou écrasant de parcourir autant d'informations techniques, mais à long terme, je pense que cela fait gagner du temps.

Le problème avec les documents officiels est qu'ils contiennent parfois tellement d'informations et qu'ils sont expliqués à un niveau si détaillé que c'est plus déroutant qu'explicatif.

Pour cette raison, je pense que c'est une bonne idée de toujours utiliser plus d'une source pour un sujet particulier, et "d'entendre des voix différentes" expliquer la même chose. Habituellement, ce n'est qu'après avoir lu la documentation, quelques articles et regardé quelques vidéos sur YouTube que j'ai l'impression de bien comprendre l'outil avec lequel je travaille.

Expliquez votre logique à une autre personne ou à un canard

lwjv2jUhM

J'ai déjà mentionné comment la programmation peut être une activité abstraite, ce qui permet de perdre facilement de vue les choses, de faire de mauvaises hypothèses et de mal interpréter les informations avec lesquelles nous travaillons.

Une bonne solution consiste à parcourir votre code ligne par ligne, en le lisant et en l'expliquant à voix haute au fur et à mesure. La technique du canard en caoutchouc est une façon populaire de le faire, mais vous pouvez choisir votre animal de compagnie préféré ou votre ami imaginaire. =P

L'idée est de vous forcer à lire votre code au lieu de simplement supposer que vous savez ce qu'il fait. De cette façon, vous pouvez vérifier la logique dans votre esprit par rapport à ce qui se passe réellement dans votre code.

Le fait que nous ayons tendance à supposer les choses et à ne pas prêter une attention particulière à chaque ligne de code est simplement la nature humaine. C'est un mécanisme qui nous aide à économiser de l'énergie et à faire les choses plus rapidement.

Mais lors du débogage, nous devons obliger notre cerveau à travailler avec nous et à être aussi présent que possible sur chaque ligne de code.

Affinez votre problème et comprenez où l'erreur est générée

aEKNV-Iju

Au fur et à mesure que votre base de code s'agrandit, il sera difficile d'analyser chaque ligne de code dans la recherche de votre bogue. C'est donc une bonne idée de diviser pour mieux régner, en commençant votre recherche dans les endroits les plus susceptibles de générer le problème.

Voyons cet exemple. J'ai une fonction qui prend un nombre et le renvoie multiplié par deux, et une autre qui imprime un prénom, un nom et le résultat de la fonction de multiplication.

const multiply = num => num*2

const mickTheBug = async (firstName, lastName, age) => {
  console.log(`My name is ${firstName} ${lastName} and the double of my age is ${multiply(age)}`)
}

mickTheBug('Mick', 10)

Le code a du sens et s'exécute sans générer d'erreur, mais le résultat que j'obtiens est My name is Mick 10 and the double of my age is NaN, ce qui n'est pas ce que je veux.

Ici, je peux voir que 10 c'est l'impression où lastNamedevrait être. Et comme les paramètres sont définis dans la ligne où la fonction est appelée.

C'est probablement une bonne supposition de commencer par vérifier si les paramètres ont été passés de la bonne manière. Et en effet, nous pouvons voir que lorsque j'ai appelé la fonction, je lui ai passé deux paramètres, Micket 10, et la fonction attend trois paramètres firstName, lastName, age.

Tapuscrit nous aurait facilement empêché de faire cette erreur. Plus sur cela plus tard. ;)

Encore une fois, c'est un exemple idiot, mais il illustre comment nous pouvons déduire d'où vient un problème, même si nous n'avons pas de message d'erreur pour nous aider.

Dans ces moments, essayez de vous poser les questions suivantes :

  • Comment puis-je savoir si je vois une erreur ?
  • Quelle contribution est-ce que je fournis ? D'où vient-il ? Cette entrée est-elle la même que celle attendue par la fonction ?
  • Quelle sortie est-ce que j'obtiens ? Comment l'entrée a-t-elle changé ?
  • Y a-t-il d'autres entités qui interagissent avec ce morceau de code ?
  • Ai-je changé quelque chose récemment qui aurait pu faire rompre le code ?

Faites une pause et pensez à autre chose

Ly_kXFJop

Les bogues comme les exemples que nous avons vus jusqu'à présent sont un jeu d'enfant à résoudre. Mais beaucoup d'autres ne le sont pas, et dans de nombreuses occasions, vous devrez vous battre avec des bogues pendant plusieurs heures (ou jours) jusqu'à ce que vous arriviez à une solution.

Dans ces occasions, je trouve qu'il est vraiment important de faire attention à votre état d'esprit. La programmation est une activité très mentale. Ainsi, la façon dont votre cerveau fonctionne à un certain moment ou la façon dont vous vous sentez affectera directement l'apparence de votre code et votre capacité à résoudre les problèmes de manière efficace.

Si vous passez des heures à lire, à répéter à haute voix les mêmes lignes de code, à googler, à passer en revue les questions de Stack Overflow, et que votre code échoue toujours, tôt ou tard, vous serez frustré et commencerez à vous mettre la pression.

Au fur et à mesure que vous essayez différentes solutions et que vous échouez encore et encore, votre souci du détail se diluera probablement et vous commencerez à sauter sur différentes idées et à essayer plusieurs choses à la fois.

Une fois que vous arrivez à ce point, la chose la plus sage à faire est d'aller vous promener ou de le laisser tranquille jusqu'au lendemain.

Si vous continuez dans cet état mental stressé et fatigué, vous ne trouverez probablement pas de solution. Et en plus, vous pourriez même aggraver le bug en touchant des choses qui n'y sont pas vraiment liées.

En laissant les choses tranquilles pendant un moment et en pensant à autre chose, notre cerveau continuera à travailler sur le problème en arrière-plan et à connecter les idées de manière "subconsciente" et créative.

À de nombreuses reprises, il m'est arrivé qu'une nouvelle solution me vienne à l'esprit lorsque je suis sous la douche ou dès que je vois à nouveau le problème le lendemain matin. C'est un de ces moments " Aha! ". C'était probablement juste devant vos yeux, mais parce que vous étiez fatigué et stressé, vous ne pouviez pas le voir.

Être concentré, bien reposé et détendu est la clé pour écrire un bon code et corriger les bugs de manière efficace. La frontière entre travailler dur et s'épuiser l'esprit est mince, mais il est important que nous y prêtions attention et que nous nous reposions chaque fois que nous en avons besoin.

Habituellement, je trouve un bon moment pour faire une pause lorsque je manque d'idées, ou que je commence à perdre ma concentration et à essayer différentes approches de manière impulsive et non systématique.

Aussi, gardez à l'esprit l'idée que les bogues ne font qu'une partie du développement logiciel. Cela ne veut pas dire que vous êtes nul en tant que développeur. Tout le monde a des bogues, même les meilleurs programmeurs. Alors détendez-vous et profitez de la situation pour apprendre quelque chose de nouveau.

Rechercher de l'aide

J'ai déjà mentionné l'importance des communautés en ligne et à quel point il est cool que nous puissions facilement trouver de l'aide pour presque tous les sujets en quelques secondes.

Avoir accès aux bonnes communautés, où vous pouvez demander et parler à des personnes expérimentées dans les outils que vous utilisez est vraiment, vraiment, vraiment utile.

Cela variera selon le type de domaine dans lequel vous travaillez et les outils que vous utilisez, mais pour moi, des sites comme freecodecamp , stackoverflow et les communautés Sack ou Dscord comme meetupjs ont fait une énorme différence.

Lorsque je pose des questions au sein de ces communautés, je trouve qu'il est important de garder à l'esprit ce qui suit :

  • Essayez d'être aussi détaillé que possible . Il n'est pas toujours facile de comprendre le code de quelqu'un d'autre simplement en le lisant, alors essayez d'expliquer sur quoi vous travaillez, ce que vous essayez de réaliser et quel est le problème auquel vous êtes confronté.
  • Montrez l' erreur exacte que vous obtenez.
  • Affichez le code associé qui, selon vous, est à l'origine de l'erreur.
  • Mentionnez les solutions que vous avez essayées jusqu'à présent et pourquoi elles n'ont pas fonctionné.
  • Enquêtez et montrez que vous avez fait des recherches sur le problème. Même si demander de l'aide est tout à fait acceptable, je pense qu'il faut d'abord évacuer les chemins les plus évidents et faciles avant de demander à quelqu'un d'autre de réfléchir à votre place. Cela signifie que vous avez analysé votre code, recherché le problème sur Google, lu d'autres solutions et de la documentation officielle, essayé de nombreuses approches et aucune d'entre elles n'a fonctionné. Ce n'est qu'alors qu'il est acceptable de demander de l'aide à quelqu'un d'autre. Je pense que c'est une question d'être capable d'apprendre et de résoudre des problèmes de manière indépendante, et aussi de respecter le temps des autres.
  • Mentionnez la documentation que vous avez consultée sur ce sujet et que dit cette documentation à ce sujet.
  • Donnez accès à votre base de code complète dans un référentiel en ligne.

Cela permettra à une autre personne de comprendre plus facilement votre problème et, espérons-le, de vous fournir des idées de solutions.

Si vous obtenez des réponses, il est important que vous y répondiez , soit en confirmant que la solution a fonctionné ou qu'elle n'a pas fonctionné et en expliquant pourquoi.

N'oubliez pas que la question que vous avez posée sera probablement stockée et disponible la prochaine fois que quelqu'un viendra chercher le même bogue. L'idée ici est de construire des connaissances et de les rendre accessibles à tous , pas seulement pour résoudre ce bogue particulier.

De plus, si vous finissez par trouver la solution vous-même, c'est une excellente idée de répondre à votre propre question et de partager la solution avec tout le monde.

Dans le même ordre d'idées, si vous participez à ces communautés en posant des questions, il serait bien que vous participiez également en répondant aux questions. Chaque fois que vous le pouvez et constatez que vous avez les connaissances, il est bon de donner en retour. ;)

Ma dernière réflexion à ce sujet est que la plupart des gens dans ce genre de communautés sont gentils, ouverts et très disposés à aider et à partager leurs connaissances. Mais comme dans n'importe quel autre domaine de la vie, vous rencontrez de temps en temps des personnes grossières, arrogantes ou même agressives.

Mon conseil ici est de ne pas laisser les autres vous intimider, même s'ils semblent avoir plus de connaissances que vous.

Personne n'est jamais né en sachant tout, et si vous avez fait vos recherches et travaillé sur le problème, vous avez tout à fait le droit de demander ce que vous voulez. Si d'autres personnes sont arrogantes ou grossières, cela parle mal d'eux, pas de vous.

Assurez-vous que le bogue est mort

xOmnh7_G7

La seule chose plus frustrante que de se battre avec un bogue coriace, c'est de le corriger pour découvrir plus tard que le bogue est toujours là. Ou pire encore, que plus de bogues ont été introduits dans votre code grâce à la "solution".

Pour éviter ce genre de situation, il est essentiel que vous testiez votre code. Et si vous pouvez le faire avec des tests unitaires automatisés, c'est encore mieux.

Idéalement, chaque section ou composant de votre base de code devrait avoir ses propres tests. Et ces tests doivent être exécutés à chaque fois qu'une modification est apportée à la base de code. De cette façon, et si le test est correctement écrit, nous pouvons remarquer un nouveau bug dès son introduction. Ce qui bien sûr facilite la recherche de sa cause et sa résolution.

Si vous n'avez pas de tests automatisés (vous devriez vraiment le faire si vous voulez créer un logiciel de qualité), testez au moins votre code manuellement, en reproduisant toutes les interactions possibles que l'utilisateur pourrait avoir avec lui, et assurez-vous que le bogue a bien été éliminé.

Écrire du code propre

Y4PKO37NS

La meilleure façon de lutter contre les bogues est d'éviter de les insérer en premier lieu. Écrire du code garanti sans bogue est impossible pour n'importe quel programmeur, mais il y a quelques choses que vous pouvez faire pour réduire les risques d'insertion de bogues.

Un bon point de départ sont les principes classiques DRY, KISS et SOLID.

Il existe des livres entiers écrits sur ces sujets, mais pour faire court, ce sont des principes qui visent à rendre les logiciels faciles à développer, faciles à comprendre et à entretenir, et aussi proches que possible de l'absence de bogues.

Ecrire le code SEC

Le principe DRY signifie "Ne vous répétez pas" . Cela signifie essentiellement que nous devons éviter la répétition du même code autant que possible.

Par exemple, si vous voyez que vous effectuez la même opération encore et encore sur différentes parties de votre code, une bien meilleure approche serait d'abstraire cette logique dans une fonction et d'appeler la fonction au lieu d'effectuer directement les opérations sur différents parties de votre code.

De cette façon, si un bogue ou un comportement inattendu se produit dans cette opération, nous savons qu'il n'y a qu'un seul morceau de code responsable, et pas beaucoup dispersés dans la base de code.

Écrire du code simple lorsque cela est possible

Le principe KISS signifie "Keep it simple stupid" . Au fur et à mesure qu'un projet logiciel grandit, il commence inévitablement à devenir de plus en plus complexe. Au fur et à mesure que de nouvelles fonctionnalités non planifiées sont ajoutées et que différents développeurs commencent à y travailler, différentes logiques et façons d'exécuter des tâches peuvent être mises en œuvre dans le même projet.

Cela rend le code plus difficile à comprendre, à maintenir et à utiliser. Et lorsque le code est difficile à comprendre, il devient très facile de faire de mauvaises hypothèses et d'insérer des bogues.

Nous devons toujours viser un logiciel facile à lire et à comprendre, avec une logique limpide et explicite pour tout le monde et pas seulement pour nous.

Gardez à l'esprit que quelqu'un d'autre à l'avenir devra peut-être travailler avec le code que vous avez écrit, alors faites en sorte qu'il soit facile pour cette personne de comprendre ce que vous faites. Même après quelques mois, vous ne vous souviendrez peut-être même pas de ce que vous avez essayé de faire avec cette fonction.

Gardez également à l'esprit qu'aucun logiciel ne reste le même pour toujours. La nature des logiciels est de changer et d'être améliorée par de nouvelles fonctionnalités, votre code doit donc être facile à modifier si nécessaire.

Et pour aller plus loin, vous devez modifier votre code chaque fois que vous pouvez trouver un moyen plus simple d'exécuter les mêmes tâches.

Peut-être qu'après avoir inclus quelques nouvelles fonctionnalités, le design que vous aviez en tête au départ n'est pas toujours la meilleure option. Une autre chose intéressante à propos du codage est que rien n'est gravé dans la pierre et que les choses peuvent être facilement inversées en cas de besoin. Alors profitez-en et habituez-vous à refactoriser constamment votre code à la recherche d'une approche plus simple.

Certains concepts pratiques qui aident à cela utilisent des noms de fonctions et de variables explicites, séparent les préoccupations en différentes fonctions et modules de code, et écrivent de courts commentaires pour expliquer votre code lorsque vos tâches sont inévitablement complexes.

Utiliser les principes SOLID

SOLID est un ensemble de principes qui s'appliquent principalement à la POO . Ils ont été établis par Robert C. Martin (qui se trouve également être l'auteur du manifeste agile ) dans ce livre sur la conception orientée objet.

  • S signifie "Single Responsibility", ce qui signifie qu'une classe doit avoir un et un seul emploi.
  • O signifie "Open Closed Principle", ce qui signifie que vous devriez pouvoir étendre le comportement d'une classe, sans le modifier.
  • L signifie "principe de substitution de Liskov", ce qui signifie que les classes dérivées doivent être substituables à leurs classes de base.
  • I signifie "Interface Segregation", ce qui signifie qu'un client ne devrait jamais être forcé d'implémenter une interface qu'il n'utilise pas, ou que les clients ne devraient pas être forcés de dépendre de méthodes qu'ils n'utilisent pas.
  • D signifie "Dependency Inversion Principle" ce qui signifie que les entités doivent dépendre d'abstractions et non de concrétions. Il stipule que le module de haut niveau ne doit pas dépendre du module de bas niveau, mais qu'il doit dépendre d'abstractions.

Comme mentionné, SOLID est plus applicable à la POO qu'à la programmation générale. Nous n'allons pas approfondir la POO dans cet article, mais il est toujours bon de connaître ces principes et de les garder à l'esprit.

Découvrons maintenant quelques outils que vous pouvez utiliser pour vous aider à déboguer votre code.

Outils de débogage technique

Il existe de nombreux outils que nous pouvons utiliser pour réduire les risques d'insertion de bogues dans notre code ou pour combattre plus efficacement les bogues existants.

À cet égard, nous allons jeter un œil à TypeScript , le populaire (et très utile) console.log et les débogueurs intégrés à VS Code et Chrome .

Ces outils et exemples seront centrés sur JavaScript, mais les principes s'appliquent à tout langage de programmation.

Vous devez également savoir que la plupart des éditeurs de code et des navigateurs Web ont aujourd'hui des débogueurs intégrés, mais nous allons passer en revue le code VS et Chrome car ils sont les plus populaires.

Et enfin, vous devez également savoir qu'il existe des outils de débogage spécifiques que vous pouvez utiliser pour déboguer des types d'applications spécifiques, comme les outils de développement React et Redux , qui sont des extensions de navigateur que vous pouvez installer pour vous aider à déboguer votre code plus efficacement.

Mais nous allons les examiner à l'avenir dans un article séparé sur la façon de déboguer une application React. ;)

Comment TypeScript aide à écrire du code propre

Je mentionne TypeScript comme premier outil, car il est étroitement lié à la section précédente sur l'écriture de code propre.

TypeScript ne vous fournit pas seulement un système de typage robuste pour JavaScript. Il ajoute également un compilateur qui vous aide à identifier les bogues et les idées fausses dans votre code avant même de l'exécuter. Il fournit une auto-complétion étonnante et peut être considéré comme un outil de documentation automatique.

Pour ne voir qu'un aperçu de ses avantages, revoyons l'exemple précédent dans lequel nous n'avons pas fourni les bons arguments à notre appel de fonction.

TYPESCRIPT1

Comme vous pouvez le voir ici, avant même d'exécuter le programme, TypeScript détecte immédiatement qu'il nous manque un argument et nous renvoie l'erreur suivante :

Expected 3 arguments, but got 2.ts(2554)
index.ts(6, 64): An argument for 'age' was not provided.

Ces types de notifications sont extrêmement utiles, en particulier lorsque vous travaillez sur de gros projets dans lesquels vous devez interagir avec de nombreuses API ou différentes sections de code.

Donc, de cette façon, si vous êtes habitué au JavaScript simple, TypeScript peut sembler inutile au début. Mais à long terme, cela vous fera sûrement gagner du temps et vous évitera d'insérer des bogues stupides dans votre code.

Comment utiliser Console.log pour déboguer le code

La journalisation de votre code dans la console est la méthode de débogage la plus basique et la première que nous apprenons à utiliser en tant que développeurs.

L'idée est d'imprimer la valeur des variables, des fonctions, des entrées et des sorties pour vérifier la logique que nous avons dans notre esprit par rapport à ce qui se passe réellement dans notre code. Cela nous aide également à voir quelles hypothèses erronées nous faisons.

Bien que ce soit un outil de base, nous pouvons faire des trucs sympas avec. Laisse moi te montrer.

Si nous appelons console.log, nous obtiendrons l'objet que nous transmettrons en tant que paramètre imprimé dans notre console.

const arr = []
console.log(arr) // []

const populateArr = (elem1, elem2, elem3) => arr.push(elem1, elem2, elem3)
console.log(populateArr) // [Function: populateArr]

populateArr('John', 'Jake', 'Jill')
console.log(arr) // [ 'John', 'Jake', 'Jill' ]

console.tableest idéal lorsque vous travaillez avec des tableaux ou des objets, car il définit les informations dans une table où vous pouvez facilement voir les clés/index et les propriétés/valeurs.

const arr = ['John', 'Jake', 'Jill']
console.table(arr)

//┌─────────┬────────┐
//│ (index) │ Values │
//├─────────┼────────┤
//│    0    │ 'John' │
//│    1    │ 'Jake' │
//│    2    │ 'Jill' │
//└─────────┴────────┘

const obj1 = {
  name: 'John',
  age: 30,
  job: 'Programmer'
}

const obj2 = {
  name: 'Jason',
  age: 32,
  job: 'Designer',
  faveColor: 'Blue'
}

const arr2 = [obj1, obj2]

console.table( arr2 )
// ┌─────────┬─────────┬─────┬──────────────┬───────────┐
// │ (index) │  name   │ age │     job      │ faveColor │
// ├─────────┼─────────┼─────┼──────────────┼───────────┤
// │    0    │ 'John'  │ 30  │ 'Programmer' │           │
// │    1    │ 'Jason' │ 32  │  'Designer'  │  'Blue'   │
// └─────────┴─────────┴─────┴──────────────┴───────────┘

Lorsque vous enregistrez plusieurs choses en même temps, cela console.groupnous donne une manière organisée de voir les choses.

const arr1 = [22, 23, 24]
const arr2 = [25, 26, 27]

console.group('myArrays')
console.log(arr1)
console.log(arr2)
console.groupEnd()


const obj1 = {
  name: 'John',
  age: 30,
  job: 'Programmer'
}

const obj2 = {
  name: 'Jason',
  age: 32,
  job: 'Designer',
  faveColor: 'Blue'
}

console.group('myObjects')
console.log(obj1)
console.log(obj2)
console.groupEnd()

// myArrays
//   [ 22, 23, 24 ]
//   [ 25, 26, 27 ]
// myObjects
//  { name: 'John', age: 30, job: 'Programmer' }
//  { name: 'Jason', age: 32, job: 'Designer', faveColor: 'Blue' }

console.assertest utile pour tester les conditions dans notre code. Il prend deux arguments : le premier est une condition et le second est le message qui se connecte si la condition est fausse.

const arr1 = [22, 23, 24]

console.assert(arr1.indexOf(20) !== -1, '20 is not in my array')
// Assertion failed: 20 is not in my array

console.warn and console.error are useful when debugging errors in our code. The first one will print the error with a yellow background and the second with a red background.

console.warn('No biggie') // No biggie
console.error(new Error('Error detected'))

// Error: Error detected
//     at Object.<anonymous> (/home/German/Desktop/ger/code/projects/test.js:6:15)
//     at Module._compile (node:internal/modules/cjs/loader:1101:14)
//     at Object.Module._extensions..js (node:internal/modules/cjs/loader:1153:10)
//     at Module.load (node:internal/modules/cjs/loader:981:32)
//     at Function.Module._load (node:internal/modules/cjs/loader:822:12)
//     at Function.executeUserEntryPoint [as runMain] (node:internal/modules/run_main:79:12)
//     at node:internal/main/run_main_module:17:47

How to Use Visual Studio Debugger

As our apps grow and start to get more complex, console.logging around becomes a not so efficient practice.

To help us in our fight against bugs, debuggers were developed. They are nothing more than programs that are able to read other programs and go through them line by line, checking whatever information we want along the way (such as the value of variables, for example).

The first example we're going to see is Visual Studio debugger.

To debug a Node.js app we don't need to install anything extra (assuming we have VS Code and Node installed in our computer), as the node debugger comes built-in in VS code.

Si vous déboguez dans un autre langage comme Python ou Java, vous devrez peut-être installer une extension VS spécifique avant d'exécuter le débogueur.

Pour commencer, il suffit de sélectionner le fichier que nous voulons déboguer et d'appuyer sur l'icône de bogue.

vsc1

Après cela, nous serons présentés avec l'écran suivant :

vsc2

Nous sélectionnerons "Exécuter et déboguer", qui exécutera simplement le programme dans l'éditeur pour nous.

Tenez compte du fait que vous pouvez également créer un launch.jsonfichier, qui est un fichier utilisé par le code VS pour "savoir" comment exécuter votre programme. Pour cet exemple simple ce ne sera pas nécessaire, mais sachez que cette possibilité existe.

Après avoir cliqué sur le bouton "Exécuter et déboguer", notre programme s'exécutera et nous arriverons à l'écran suivant :

vsc3

En haut à gauche, nous avons toutes les variables disponibles dans le programme, tant au niveau local que global.

vsc4

En dessous, nous aurons un espace où nous pourrons déclarer des expressions en particulier que nous aimerions regarder. Les expressions peuvent être n'importe quoi, comme des variables ou des fonctions particulières que vous aimeriez surveiller pour évaluer comment elles changent avec votre programme.

Par exemple, j'ai ajouté ma variable arret le code VS me montre la valeur de cette variable :

vsc5

Et en dessous, nous pouvons voir la pile d'appels (si vous ne savez pas ce que c'est , voici une vidéo géniale qui l'explique), les scripts qui sont chargés et les points d'arrêt que nous avons définis dans notre code (nous verrons ce que c'est en une seconde).

vsc6

Les points d' arrêt sont une grande partie de ce qui rend les débogueurs utiles. Comme leur nom l'indique, ce sont des points que vous pouvez déclarer dans votre code où le débogueur arrêtera d'exécuter le programme. Lorsque le programme s'arrête, vous serez en mesure de vérifier toutes les informations que nous avons mentionnées précédemment telles qu'elles sont à ce moment particulier.

Ainsi, les points d'arrêt nous permettent de voir les informations réelles avec lesquelles le programme travaille, sans avoir besoin de se connecter à la console. Plutôt cool!

Vous pouvez identifier un point d'arrêt par les petits points rouges qui apparaissent à gauche des numéros de ligne dans votre code (ou en consultant la section mentionnée ci-dessus).

Par défaut, lorsque vous exécutez le débogueur, un point d'arrêt est inséré dans la dernière ligne de votre code. Pour insérer de nouveaux points d'arrêt, cliquez simplement à gauche du numéro de ligne auquel vous souhaitez que le débogueur s'arrête.

vsc7

Maintenant, lorsque vous exécutez le débogueur, vous verrez qu'il y a une petite flèche vers la gauche au-dessus du premier point d'arrêt, indiquant que c'est là que l'exécution du programme s'est arrêtée.

vsc8

En haut de l'écran, nous avons les commandes , qui nous permettront de parcourir le programme en passant d'un point d'arrêt à un point d'arrêt.

vsc9

  • Le bouton Continuer exécute le programme et s'arrête uniquement sur les points d'arrêt définis par l'utilisateur.
  • Avec Step Over , s'il y a un appel de fonction, il l'exécute et renvoie le résultat. Vous n'entrez pas dans les lignes qui sont à l'intérieur de la fonction. Vous allez juste directement à la valeur de retour de la fonction.
  • Step Into va à l'intérieur de la fonction ligne par ligne jusqu'à ce qu'elle revienne, puis vous revenez à la ligne suivante juste après l'appel de la fonction.
  • Avec le bouton Step Out , si vous êtes entré dans une fonction, vous pouvez sauter l'exécution restante de la fonction et aller directement à la valeur de retour.
  • Restart exécute à nouveau le débogueur depuis le début et Stop quitte le débogueur.

Alors voilà, c'est un débogueur très puissant intégré à votre éditeur de code. Comme vous pouvez le voir, avec cet outil, nous pouvons vérifier de nombreuses informations en même temps, simplement en définissant des points d'arrêt où nous voulons et sans avoir besoin de console.logs.

Débogueur Chrome

Pour déboguer dans Chrome, nous commençons par ouvrir notre application dans le navigateur. Dans mon cas, j'ai créé un simple fichier HTML où mon fichier JS est lié (même fichier que l'exemple précédent).

Ensuite, nous ouvrons les outils de développement (ctrl+shit+i ou clic droit -> inspecter) et allons dans l' onglet " sources ".

Nous devrions voir quelque chose comme ça :

chromé1

Sur le côté gauche, nous pouvons voir les fichiers disponibles dans notre application (dans mon cas, il n'y a qu'un fichier HTML et le fichier JS.) Au milieu, nous pouvons voir le code de notre fichier sélectionné, et sur le côté droit, nous avons un ensemble d'informations très similaire à ce que nous avions dans VS Code.

Pour définir un point d'arrêt, nous devons cliquer en haut de la ligne dans laquelle nous voulons nous arrêter. Dans Chrome, les points d'arrêt sont identifiés par des flèches bleues en haut du numéro de ligne.

chromé2

Ensuite, si nous actualisons notre page, le script s'arrêtera au premier point d'arrêt et nous serons autorisés à le parcourir à l'aide des contrôles, qui fonctionnent exactement de la même manière que dans le code VS.

chromé3

Comme nous l'avons vu, les débogueurs de code Chrome et VS fonctionnent de manière très similaire, et celui que vous décidez d'utiliser n'est qu'une question de préférence.

Conclusion

Le débogage est un élément central de ce que nous faisons en tant que développeurs. Pour cette raison, je pense que c'est une bonne idée d'y penser et de le faire de manière efficace, au lieu de simplement réagir aux bugs au fur et à mesure qu'ils surviennent.

Comme nous l'avons vu, il y a beaucoup de choses que nous pouvons faire, à la fois d'un point de vue mental et technique, pour devenir de meilleurs débogueurs.

Link: https://www.freecodecamp.org/news/what-is-debugging-how-to-debug-code/

#debug #debugging #code 

Tyrique  Littel

Tyrique Littel

1604008800

Static Code Analysis: What It Is? How to Use It?

Static code analysis refers to the technique of approximating the runtime behavior of a program. In other words, it is the process of predicting the output of a program without actually executing it.

Lately, however, the term “Static Code Analysis” is more commonly used to refer to one of the applications of this technique rather than the technique itself — program comprehension — understanding the program and detecting issues in it (anything from syntax errors to type mismatches, performance hogs likely bugs, security loopholes, etc.). This is the usage we’d be referring to throughout this post.

“The refinement of techniques for the prompt discovery of error serves as well as any other as a hallmark of what we mean by science.”

  • J. Robert Oppenheimer

Outline

We cover a lot of ground in this post. The aim is to build an understanding of static code analysis and to equip you with the basic theory, and the right tools so that you can write analyzers on your own.

We start our journey with laying down the essential parts of the pipeline which a compiler follows to understand what a piece of code does. We learn where to tap points in this pipeline to plug in our analyzers and extract meaningful information. In the latter half, we get our feet wet, and write four such static analyzers, completely from scratch, in Python.

Note that although the ideas here are discussed in light of Python, static code analyzers across all programming languages are carved out along similar lines. We chose Python because of the availability of an easy to use ast module, and wide adoption of the language itself.

How does it all work?

Before a computer can finally “understand” and execute a piece of code, it goes through a series of complicated transformations:

static analysis workflow

As you can see in the diagram (go ahead, zoom it!), the static analyzers feed on the output of these stages. To be able to better understand the static analysis techniques, let’s look at each of these steps in some more detail:

Scanning

The first thing that a compiler does when trying to understand a piece of code is to break it down into smaller chunks, also known as tokens. Tokens are akin to what words are in a language.

A token might consist of either a single character, like (, or literals (like integers, strings, e.g., 7Bob, etc.), or reserved keywords of that language (e.g, def in Python). Characters which do not contribute towards the semantics of a program, like trailing whitespace, comments, etc. are often discarded by the scanner.

Python provides the tokenize module in its standard library to let you play around with tokens:

Python

1

import io

2

import tokenize

3

4

code = b"color = input('Enter your favourite color: ')"

5

6

for token in tokenize.tokenize(io.BytesIO(code).readline):

7

    print(token)

Python

1

TokenInfo(type=62 (ENCODING),  string='utf-8')

2

TokenInfo(type=1  (NAME),      string='color')

3

TokenInfo(type=54 (OP),        string='=')

4

TokenInfo(type=1  (NAME),      string='input')

5

TokenInfo(type=54 (OP),        string='(')

6

TokenInfo(type=3  (STRING),    string="'Enter your favourite color: '")

7

TokenInfo(type=54 (OP),        string=')')

8

TokenInfo(type=4  (NEWLINE),   string='')

9

TokenInfo(type=0  (ENDMARKER), string='')

(Note that for the sake of readability, I’ve omitted a few columns from the result above — metadata like starting index, ending index, a copy of the line on which a token occurs, etc.)

#code quality #code review #static analysis #static code analysis #code analysis #static analysis tools #code review tips #static code analyzer #static code analysis tool #static analyzer

Samanta  Moore

Samanta Moore

1621137960

Guidelines for Java Code Reviews

Get a jump-start on your next code review session with this list.

Having another pair of eyes scan your code is always useful and helps you spot mistakes before you break production. You need not be an expert to review someone’s code. Some experience with the programming language and a review checklist should help you get started. We’ve put together a list of things you should keep in mind when you’re reviewing Java code. Read on!

1. Follow Java Code Conventions

2. Replace Imperative Code With Lambdas and Streams

3. Beware of the NullPointerException

4. Directly Assigning References From Client Code to a Field

5. Handle Exceptions With Care

#java #code quality #java tutorial #code analysis #code reviews #code review tips #code analysis tools #java tutorial for beginners #java code review

Houston  Sipes

Houston Sipes

1604088000

How to Find the Stinky Parts of Your Code (Part II)

There are more code smells. Let’s keep changing the aromas. We see several symptoms and situations that make us doubt the quality of our development. Let’s look at some possible solutions.

Most of these smells are just hints of something that might be wrong. They are not rigid rules.

This is part II. Part I can be found here.

Code Smell 06 - Too Clever Programmer

The code is difficult to read, there are tricky with names without semantics. Sometimes using language’s accidental complexity.

_Image Source: NeONBRAND on _Unsplash

Problems

  • Readability
  • Maintainability
  • Code Quality
  • Premature Optimization

Solutions

  1. Refactor the code
  2. Use better names

Examples

  • Optimized loops

Exceptions

  • Optimized code for low-level operations.

Sample Code

Wrong

function primeFactors(n){
	  var f = [],  i = 0, d = 2;  

	  for (i = 0; n >= 2; ) {
	     if(n % d == 0){
	       f[i++]=(d); 
	       n /= d;
	    }
	    else{
	      d++;
	    }     
	  }
	  return f;
	}

Right

function primeFactors(numberToFactor){
	  var factors = [], 
	      divisor = 2,
	      remainder = numberToFactor;

	  while(remainder>=2){
	    if(remainder % divisor === 0){
	       factors.push(divisor); 
	       remainder = remainder/ divisor;
	    }
	    else{
	      divisor++;
	    }     
	  }
	  return factors;
	}

Detection

Automatic detection is possible in some languages. Watch some warnings related to complexity, bad names, post increment variables, etc.

#pixel-face #code-smells #clean-code #stinky-code-parts #refactor-legacy-code #refactoring #stinky-code #common-code-smells

Fannie  Zemlak

Fannie Zemlak

1604048400

Softagram - Making Code Reviews Humane

The story of Softagram is a long one and has many twists. Everything started in a small company long time ago, from the area of static analysis tools development. After many phases, Softagram is focusing on helping developers to get visual feedback on the code change: how is the software design evolving in the pull request under review.

Benefits of code change visualization and dependency checks

While it is trivial to write 20 KLOC apps without help of tooling, usually things start getting complicated when the system grows over 100 KLOC.

The risk of god class anti-pattern, and the risk of mixing up with the responsibilities are increasing exponentially while the software grows larger.

To help with that, software evolution can be tracked safely with explicit dependency change reports provided automatically to each pull request. Blocking bad PR becomes easy, and having visual reports also has a democratizing effect on code review.

Example visualization

Basic building blocks of Softagram

  • Architectural analysis of the code, identifying how delta is impacting to the code base. Language specific analyzers are able to extract the essential internal/external dependency structures from each of the mainstream programming languages.

  • Checking for rule violations or anomalies in the delta, e.g. finding out cyclical dependencies. Graph theory comes to big help when finding out unwanted or weird dependencies.

  • Building visualization for humans. Complex structures such as software is not easy to represent without help of graph visualization. Here comes the vital role of change graph visualization technology developed within the last few years.

#automated-code-review #code-review-automation #code-reviews #devsecops #software-development #code-review #coding #good-company