Comment faire un code incorrect regarde mal ? Quels modèles utilisez-vous pour éviter les erreurs de sémantiques ?

Question

Jamais depuis que j'ai fait l'erreur de faire une mission dans un if j'ai toujours écrit mes ifs comme ceci:

if (CONST == variable) {

pour éviter de la commune (au moins pour moi) l'erreur de le faire:

if (variable = CONST) { //WRONG, assigning 0 to variable

Et depuis que j'ai lu Joel Spolsky, son essai de Faire les Mauvais Code Regarde Mal , j'ai essayé de mettre ses conseils en pratique.

Donc, ce que les autres modèles) utilisez-vous pour faire de mauvais code regarde mal, ou à la force syntaxique des erreurs si vous faites une erreur sémantique?

Answer 1

Je trouve important de faire de mauvais code regarde mal pour le compilateur. Dans la pratique (et uniquement lors de l'utilisation des langages fortement typés), cela signifie en omettant toute sorte de variable préfixes (même les Applications hongrois) en faveur de types distincts. Pour utiliser Joël exemple, s'il y a deux types distincts pour représenter les chaînes brutes et désinfectés cordes, et il n'y a pas de conversion implicite entre les deux, alors le problème vient du fait que les Applications hongrois adresses ne peuvent même pas se produire.

Il en va de même pour le document Word coordonnées. Dans un sens, Apps hongrois n'est qu'une solution de contournement pour les compilateurs/langues qui n'ont pas assez stricte vérification de type.

Answer 2

Une pratique que j'utilise (et celui que tout le monde ne serait même d'accord avec) est toujours entourant les blocs de code (en C++) avec { et }. Ainsi, au lieu de ceci:

if( true )
    DoSomething();
else
    DoSomethingElse();

Je voudrais écrire ceci:

if( true ) {
    DoSomething();
} else {
    DoSomethingElse();
}

De cette façon, si je (ou quelqu'un d'autre) revient à ce code plus tard pour ajouter plus de code pour l'une des branches, je n'aurai pas à vous soucier d'oublier d'entourer le code entre accolades. Nos yeux vont voir le retrait comme indices de ce que nous essayons de faire, mais la plupart des langues ne sera pas.

Answer 3

Une chose que j'essaie d'utiliser, si possible. est d'éviter d'utiliser les types boolean comme paramètres de fonctions, surtout si il y a plusieurs paramètres.

Qui est plus lisible...

compare("Some text", "Some other text", true);

...ou...

compare("Some text", "Some other text", Compare.CASE_INSENSITIVE);

Certes, cela peut être un peu exagéré parfois, mais il est pas dur à mettre en place, améliore la lisibilité et réduit les chances de l'auteur du tort de rappeler que le "vrai" signifie "Oui, faire la comparaison dans le cas de manière sensible" ou "Oui, faire la comparaison dans une casse'.

Bien sûr, des cas tels que...

setCaseInsenstive(true);

...est simple et suffisamment visible pour être laissé seul.

Answer 4

Toujours déclarer des variables pour être « const » (ou l’équivalent dans votre langage de programmation) s’il n’y a aucune raison pour que la valeur à modifier après l’initialisation.

Si vous transformez cette habitude, vous allez éventuellement commencer à remettre en question chaque fois que vous avez une variable non const.

Answer 5

@Matt Dillard:

Une autre mesure de défense de la programmation est toujours d'utiliser une instruction break dans chaque bloc de code (c'est à dire ne pas laisser une instruction case "automne grâce" à la suivante). La seule exception est si plusieurs cas, les relevés doivent être traitées de manière identique.

Parfois, la manipulation cas X et cas Y faire presque la même chose, auquel cas la chute dans le cas suivant rend le code plus facile à lire. C'est une bonne idée d'indiquer expressément que, avec un commentaire bien:

switch( type ) {
case TypeA:
   do some stuff specific to type A
   // FALL THROUGH
case TypeB:
   do some stuff that applies to both A and B
   break
case TypeC:
   ...
}

Si vous utilisez cette convention, tous les états devraient alors faire une pause, un retour, un de continuer ou d'un commentaire indiquant que c'est de tomber à travers. Un caisson vide sans le commentaire est OK si:

case TypeA:
case TypeB:
   // code for both types