XimoonLe 21/10/2010 à 10:17
Bon 
- Utilise des valeurs définies par #define plutôt que des valeurs numériques, ça te permettra d'avoir un code plus lisible et plus maintenable.
Typiquement, en l'absence de doc, je ne sais pas à quoi correspond la valeur "2" renvoyée par ta fonction IsOperator.
- Commenter les fonctions et tout j'ai déjà dit Tu connais Doxygen ? 
- Ce n'est manifestement pas du C, donc je vais passer sur "for (; sc.More(); sc.Forward())", c'est peut-être normal.
- Oui les accolades et les tests explicites. Pour les accolades, je trouve que ça apporte en lisibilité, et ça évite les bugs (quand quelqu'un ne se rend pas compte au premier abord qu'il y a un test suivi d'une action, etc).
- J'aurais tendance à me limiter à un seul return par fonction, mais c'est question de goût aussi. Le but est d'améliorer la lisibilité du code (on sait où l'on entre, et on sait où l'on sort, donc s'il y a un bug, c'est plus facile à tracer), mais question de goût aussi.
- Utilise des valeurs définies par #define plutôt que des valeurs numériques, ça te permettra d'avoir un code plus lisible et plus maintenable.
Typiquement, en l'absence de doc, je ne sais pas à quoi correspond la valeur "2" renvoyée par ta fonction IsOperator.
- Commenter les fonctions et tout j'ai déjà dit
Tu connais Doxygen ? 
- Ce n'est manifestement pas du C, donc je vais passer sur "for (; sc.More(); sc.Forward())", c'est peut-être normal.
- Oui les accolades et les tests explicites. Pour les accolades, je trouve que ça apporte en lisibilité, et ça évite les bugs (quand quelqu'un ne se rend pas compte au premier abord qu'il y a un test suivi d'une action, etc).
- J'aurais tendance à me limiter à un seul return par fonction, mais c'est question de goût aussi. Le but est d'améliorer la lisibilité du code (on sait où l'on entre, et on sait où l'on sort, donc s'il y a un bug, c'est plus facile à tracer), mais question de goût aussi.