Par exemple, je pense que le 'if (cond) {' sur la même ligne est une question de goût. En revanche, le '} else {' ne me paraît pas bon pour la lisibilité (c'est moins facile de trouver le "else").
c'est moche, c'est tout, une déclaration de type de variable n'a rien à faire dans un for
Ben, il me semble me souvenir que c'est comme ça en Pascal et Ada, non ?
Au moins, ça empêche de faire le truc très moche, parce qu'impossible à porter entre des compilos différents et éventuellement entre des versions du même compilo (il me semble que ce n'est pas garanti par le standard, et heureusement ^^), qui consiste à utiliser la valeur d'une variable d'itération principale hors du corps de la boucle
./23: pour moi, les if sans { } sont à bannir absolument. C'est une source de bugs subtils qui peuvent difficiles à trouver, venant de la transformation, un jour où tu es fatigué / pressé, de
if (val)
une_seule_expression;en
if (val)
une_seule_expression;
une deuxième expression;alors que tu voudrais écrire
if (val) {
une_seule_expression;
une deuxième expression;
}Ce n'est pas hypothétique: j'ai déjà corrigé une occurrence de
if (val)
une_seule_expression;
return;
// !!! ici, il y a du code non atteignable !!!au boulot. L'erreur "unreachable code" n'avait pas été détectée pour cause de warnings trop bas...
Les espaces et tabs mélangés, c'est vraiment TROP bien
(mais quand tu viens après le début d'un projet qui a été formatté avec les pieds, tu peux être obligé de respecter ce format et d'écrire du nouveau code à ce format. En effet, faire des changements whitespace pur met des modifications fonctionnellement inutiles dans l'historique des commits, et complique donc la recherche de qui pourrait être compétent dans un morceau de code donné.)
Ni emacs ni vi, même leurs versions améliorées (vim, etc.), ne sont de vrais éditeurs de texte, de toute façon