Méthodes pour éviter les bugs de typo communs

Je viens de passer les dernières heures à verser sur le code à essayer de comprendre la source d'un bug pour constater que mon erreur était nul autre que le évidemment faux, mais le compilateur accepté:Méthodes pour éviter les bugs de typo communs

if (a = b)

où il aurait dû être

if (a == b)

Qu'est-ce que vous faites les gars pour se protéger contre ces erreurs frustrant? Quel autre commun "évidemment faux, mais le compilateur ne se plaindra pas" bugs dois-je aussi faire attention?

Source

2010-09-12 Faken

+10

Votre compilateur n'a pas au moins une * option * pour vous avertir à ce sujet?!?! Cela a été une caractéristique de charpie assez standard depuis au moins * quand j'ai travaillé avec Borland TurboC en 1988 ... Vous pourriez vérifier pour voir que vous activez les avertissements. Si votre compilateur ne fait pas, regardez dans un bon outil de peluches - http://en.wikipedia.org/wiki/Lint_(software) (Je ne sais pas pourquoi je n'ai pas fait de cette réponse une réponse [corrigé] (http://stackoverflow.com/questions/3696961/methods-for-avoiding-common-typo-bugs/3696976#3696976).) –

Si cela aide, le compilateur VC++ a de nombreux avertissements désactivés par défaut. Peut-être les allumer aidera-t-il. –

+1 pour le peluchage. – ocodo

La plupart des compilateurs offrent des options pour donner des avertissements dans ces situations. Ils sont généralement appelés avertissements "peluches" après le nom d'un programme initial pour leur fournir le code source C (au début, les compilateurs C ne les avaient pas intégrés, mais ils le font principalement maintenant). Vous pouvez vérifier que vous activez tous les avertissements fournis par votre compilateur. Si votre compilateur ne fournit pas de fonctionnalités de peluches, regardez dans un bon lint tool.

Source

2010-09-12 22:50:12

Eh bien, il y a de meilleurs moyens de m'informer que les compilateurs ont ces caractéristiques que de me battre par dessus la tête avec plusieurs questions alternées et points d'exclamation. Si je ne sais pas, je ne sais pas. C'est pourquoi je suis venu ici pour le savoir. – Faken

Votre réponse est parfaitement bonne sans les deux premières phrases. Nous n'étions pas tous nés au courant des linters. –

@Faken, @Michael: Vous avez tous les deux raison, et des excuses. J'allais pour l'humour collégial, et a raté un peu la marque. Fixé. –

~~beaucoup de gens font if(0 == var) pour les nombres littéraux, parce que 0 = x; est une erreur du compilateur. Pour if(a = b), je ne connais pas de solution générale.~~ Edit: suivez les conseils de GMan et n'adoptez pas ce style. c'est moche, difficile à lire et totalement inutile si vous compilez simplement avec des avertissements.

Un autre exemple de la façon d'éviter les fautes de frappe est de mettre des accolades pour/tout/si les blocs. Je l'ai vu:

if(x) 
    doSomething(); 
somethingElse();

cause des problèmes, par exemple si le dev on ne m'a pas prêter attention, avait onglets/espaces vissés de façon à ce retrait a eu tort ou autre chose. Supprimer la ligne doSomething() ou ajouter des éléments au bloc if() nécessite des modifications sur d'autres lignes. Safer est:

if(x) 
{ 
    doSomething(); 
} 
somethingElse();

Source

2010-09-12 22:46:37 tenfour

Les Yoda-conditionnels :).Personnellement, je ne les aime pas, ils ont l'air anormal, je préfère juste allumer tous les avertissements et laisser le compilateur me dire si je mets des devoirs dans des conditions. –

S'il vous plaît n'adoptez pas vraiment ce style, c'est moche, difficile à lire et totalement inutile. Compilez simplement avec des avertissements. – GManNickG

Un des développeurs principaux de mon équipe m'a appris cette astuce quand je commençais juste mais je ne l'ai jamais pris car il faisait toujours moins ressembler le code à une phrase en anglais lorsqu'il était lu à haute voix. J'ai l'impression que cela fait plus pour nuire à la lisibilité que pour aider à prévenir les bugs. :( – leoger

Un problème courant pour moi n'est pas de vérifier qu'un pointeur existe (pas NULL) avant de l'utiliser. Ce problème a créé de nombreuses ruptures inattendues dans mon code.

Source

2010-09-12 22:47:26

Espérons que toutes les allocations faites avec new lèvent une exception quand elles échouent, donc il est plus difficile d'ignorer ces erreurs qu'avec malloc –

Ce n'est pas quand les allocations échouent, c'est quand elles n'arrivent jamais –

Honnêtement, je ne sais pas –

La meilleure chose que vous pouvez faire est de coller avec les -W/-pedantic diverses options que le compilateur mises à votre disposition ..

un coup d'oeil here, il y a de nombreux avertissements que vous pouvez activer pour prévenir de nombreux types d'erreurs, mais vous ne pouvez rien faire à propos de certaines erreurs si ce n'est en vous servant de vous-même pour les éviter :)

Source

2010-09-12 22:48:32 Jack

+1 Je commence toujours mes projets avec "-Wall -Werror -Wextra -pedantic", et je trouve que cela m'aide. – greyfade

@greyfade: moi aussi :) Et puis je dois faire usage de pragmas lors de l'intégration de code tiers :( –

@ Matthieu M .: Avec GCC, vous pouvez configurer vos includes avec le '- isystem' switch (par opposition à '-I'), qui désactive la plupart des avertissements pour ceux-ci, de sorte que vous obtenez les avantages de garder les avertissements sur votre code sans l'inconvénient d'avoir à patauger à travers la merde de 3e p code arty. – greyfade

Méthodes pour éviter les bugs de typo communs

Répondre

Questions connexes