si (num est un multiple de 10) { faire ceci }
if (num % 10 == 0) {
// Do something
}
si (num est dans 11-20, 31-40, 51-60, 71-80, 91-100) { faire ceci }
L'astuce consiste à rechercher une sorte de point commun entre les gammes. Bien sûr, vous pouvez toujours utiliser la méthode de la "force brute" :
if ((num > 10 && num <= 20) ||
(num > 30 && num <= 40) ||
(num > 50 && num <= 60) ||
(num > 70 && num <= 80) ||
(num > 90 && num <= 100)) {
// Do something
}
Mais vous pourriez remarquer que, si vous soustrayez 1
de num
vous aurez les gammes :
10-19, 30-39, 50-59, 70-79, 90-99
En d'autres termes, tous les nombres à deux chiffres dont le premier chiffre est impair. Ensuite, vous devez trouver une formule pour exprimer cela. Vous pouvez obtenir le premier chiffre en divisant par 10, et vous pouvez vérifier qu'il est impair en vérifiant que le reste est égal à 1 lorsque vous divisez par 2. En mettant tout ça ensemble :
if ((num > 0) && (num <= 100) && (((num - 1) / 10) % 2 == 1)) {
// Do something
}
Étant donné le compromis entre un code plus long mais maintenable et un code plus court et "intelligent", je choisirais toujours un code plus long et plus clair. Au minimum, si vous essayez d'être intelligent, veuillez inclure un commentaire qui explique exactement ce que vous essayez d'accomplir.
Il est utile de supposer que le prochain développeur qui travaillera sur le code est armé et sait où vous vivez. :-)
17 votes
En général, la longueur d'un bon code est proportionnelle à la longueur de l'anglais décrivant ce qu'il fait. Ainsi, lorsque votre "spécification" indique 11-20, 31-40, 51-60, 71-80, 91-100, vous pouvez vous attendre à ce que votre code mentionne également ces chiffres. Si ces chiffres proviennent de quelque part ou ont été générés par une raison quelconque, voyez si vous pouvez coder la raison plutôt que les chiffres.
40 votes
@user3419168 : Le compilateur ne se soucie guère de la lisibilité de votre code ; il le compilera en une fraction de seconde. Mais pour les humains qui lisent votre code, les choix que vous faites peuvent faire en sorte qu'il soit compris en quelques secondes, minutes, heures, ou jamais. Cela a un coût ; les gens sont payés pour lire et comprendre le code, alors facilitez-leur la tâche. Rédigez toujours le code de production de manière à maximiser sa lisibilité et n'oubliez pas que la concision ne rend pas nécessairement le code plus performant.
0 votes
Les titres de vos deux autres questions sont de très bons titres ; ils décrivent précisément le sujet technique de la question. J'ai édité celui-ci parce qu'il était vague, et concernait plus votre personne que le problème de codage.
0 votes
Je ne vois pas pourquoi, dans un jeu standard de serpents et échelles, il serait nécessaire de découvrir cette information. Pourriez-vous nous expliquer comment ce code est susceptible d'être utilisé ? Je demande seulement parce que cela ne me semble pas être une conception très orientée objet et qu'il pourrait y avoir une meilleure façon de faire.
1 votes
@EricLippert votre point est extrêmement valide. Je vois aussi des gens qui écrivent du code "intelligent", inconscients du fait que la seule personne qui pourrait se soucier de leur intelligence (la prochaine personne qui lit le code) les détestera pour cela, et sans aucun avantage visible en termes de performances. Ça fait pleurer.
1 votes
@Floris Dans ces situations, je laisse parfois le code original, non optimisé, mais commenté. Je pense que cela aide le lecteur à comprendre ce qui se passe.
2 votes
@AmadeusDrZaius - J'ai TRÈS RAREMENT fait de même, mais seulement pour les sections critiques en termes de performances. La boucle la plus serrée qui est appelée 100M fois est admissible - l'instruction if dans un jeu de serpents et échelles ne l'est pas. La ligne de démarcation entre les deux est un choix personnel.
2 votes
Je déteste dire cela, mais ayant fait suffisamment de travail en entreprise, avec des débutants écrivant du vrai code, je dois recommander le forçage brutal. C'est triste mais vrai - dans certains cas, il est intelligent d'être stupide.
22 votes
C'est une bonne question, et je ne veux rien enlever à l'auteur de la question, mais elle ne mérite pas plus de 500 points. C'est comme ça que nous nous retrouvons avec des gens qui ont des milliers de points et qui semblent faire autorité ici. (N'hésitez pas à déplacer ce commentaire s'il a sa place ailleurs).
1 votes
@floris ... et où vous tracez la ligne dans Serpents et échelles est de la plus haute importance >;-)
0 votes
@eggyal Il vous indique la direction de la case suivante. 1-10 vont de gauche à droite le long du bas de la planche. Ensuite, 11 est au-dessus de 10 et 11-20 vont de droite à gauche le long de la deuxième rangée vers le haut, et ainsi de suite. L'OP essaie donc de savoir s'il faut déplacer le compteur vers le haut (si n est un multiple de 10), vers la droite (si n est dans 1-9, 21-29 etc.) ou vers la gauche (si n est dans 11-19, 31-39 etc.).