sBibi a écrit :
bah utilise emacs et ils feront 8 characteres, et puis c tres bien 8 tabs, pourquoi changer? c'est la norme des balises <pre> en plus 
Le règlage le plus utilisé est 8 caractères, mais beaucoup de gens utilisent autre chose, de style 4 caractères, ou carrément 1 pouce (M$ Word). Personnellement, j'ai des tabs de 2 caractères dans
TIGCC IDE pour que les sources indentées avec des tabs (et en utilisant les tabs comme prévu, pas en en abusant pour réduire le nombre d'espaces) soient lisibles. C'est un abus des tabs que de les utiliser là où on utiliserait 8 espaces! Quant à
emacs, déjà je parie que la largeur des tabs est paramétrable là-dedans (tout est paramétrable dans
emacs 
) et ensuite je ne toucherai pas à cet éditeur horrible si on ne m'y oblige pas.
c'est pas du tout "mon prof m'a dit de faire comme ca", on a pas de profs,
Alors c'est peut-être "mon supérieur m'a dit de faire comme ça", mais le mot à mettre à la place de "prof" n'a aucune importance pour comprendre l'idée de ce que j'ai dit.
c'est une norme qu'on doit respecter (moi pas toi), mais je la trouve tres logique et j'y adere tout a fait, dc je la defends (a part les 25 lignes 
), ta ligne est pas forcement illisible, mais la preuve, en lisant ton code, j'avais pas fait gaffe au code que t'avais apres certains de tes if...
C'est parce que tu n'as pas l'habitude des
if en une ligne, c'est tout. Si on a l'habitude, on s'y retrouve très bien.
ca entraine aussi chez certains une recherche des 25 lignes qui apporte certaines aberrations dans le code, par exemple (entre autres) remplacer tous les if par des ternaires meme quand l'es expressions dans le ternaire ne renvoient pas de valeurs...
Vive les normes contre-productives!
mais je suis en partie d'accord aussi:
1/ pour l'ecran terminal, c'est 80 colonnes, pas forcement 25 lignes
Mais le standard, c'est 24 lignes (vt100) ou 25 lignes (configuration standard de MS-DOS).
2/ on nous impose cette contrainte AU DEBUT, quand on comence a apprendre a coder, pour nous eviter de faire des programmes qui tiennent en 1 seule fonction (genre vrally by Vark?
Je n'ai pas vu les sources de
vrally, mais je ne vois pas où est le problème d'avoir un programme en une seule fonction.
ce point la de la norme va bcp s'assouplir, a la fin de la piscine, on est passe a 30 lignes, la c devenu encore plus souple, bien qu'on nous conseille encore et tjrs de faire les fct les plus petites possibles.
sBibi a écrit :
a la rigueur, la norme que t'utilise depend des personnes avec qui tu travailles, l'important c'est d'avoir la meme norme que les personnes avec qui tu partages des sources, pour que ca soit le plus facilement lisbible par tout le monde... le truc que je supporte le moins c'est de voir des sources avec un coup ca:
for( truc= 1 ; truc ++ < machin;[i][/i])
tab[truc] = chose;
un coup ca:
for (truc =1; truc++ < machin; )
tab [ truc ]=chose;
Là, il est vrai que c'est vraiment inconsistent comme truc. Pratiquement tout le format change. Mais si ce sont des morceaux de code de développeurs différents, je trouve que c'est tout à fait normal que le format soit différent. Même si tes 2 exemples sont quand-même extrèmes.
Et au fait, c'est beaucoup mieux comme ça:
for (truc=1;truc++<machin;) tab[truc]=chose;
ou un coup ca:
if (chose)
truc;
et un coup ca:
if (chose) truc;
Là, de mon point de vue, tout dépend de la longueur de
chose et de
truc. J'utilise la deuxième variante si ça tient en une ligne, et la première sinon.
tout depend de ta norme, pour moi, si tu identes, t'identes partout, si tu vas a la ligne apres les if, t'y vas dans tous les cas, sinon apres ca devient bordelique
Mais non, mon système est tout à fait logique: on va à la ligne s'il n'y a plus de place dans la ligne (et mon critère pour "plus de place dans la ligne", c'est 80 colonnes maximum). Sinon, on continue dans la même ligne.
pke je trouve ca moins lisible, encore la: la preuve, j'av pas fait gaffe au code que t'av apres tes if-sur-la-meme-ligne
Parce que soit tu n'as pas l'habitude, soit tout simplement tu ne t'y attendais pas. Maintenant, tu sais qu'il y a des
if en une ligne dans mon code. Et d'ailleurs,
TIGCC IDE me montre très bien (à l'aide du code de couleurs des parenthèses) que la parenthèse ouverte après le
if est refermée bien avant la fin de la ligne. J'ai déjà dit que le format de
Backgammon (la source était un extrait de
Backgammon - j'ai d'ailleurs choisi une fonction lisible; la fonction
DrawCheckers d'en-dessous risque de te faire pleurer si tu la lis: ça ressemble beaucoup à du Vertyos
) n'est vraiment lisible qu'avec la coloration syntaxique.
tjrs le meme probleme... "je fais comme ca sauf si ca et ca et aussi ca a moins que ca"
non! soit tu le fais soit tu le fais pas, y a pas de sauf si, la encore, c'est une preference personnelle...
Ben oui, ma préférence personnelle est qu'il y a plein de "sauf si".
Et mes critères sont d'ailleurs surtout empiriques ("je n'aime pas ce morceau de code comme ça, je vais plutôt le mettre comme ça"); j'ai toujours du mal quand j'essaye de les formuler dans une discussion comme celle-ci.
je prefere avoir un code plus long et etre motive a le raccourcir en me disant "putain c'est long" et en raccourcissant EFFECTIVEMENT le code, et pas juste remettre des trucs sur la meme ligne en me disant apres "ah tiens c cool c'est + court"
Ce n'est pas pour dire "c'est plus court" que je fais ça, mais parce que je m'y repère mieux si la source utilise moins de lignes. Et puis l'idée de laisser du vide me repousse.
Et pour compléter le tout, voici la fonction
DrawCheckers mentionnée plus haut:
[0]__attribute__((regparm(4)))
void DrawCheckers(signed char n, short x, short y, short dir)
{
for (int i=0;i<abs(n);i++) {
DrawSprite((unsigned char *)(n>0?white_checker:black_checker),
x+(abs(n)<=5)+Q((i/5)*((abs(n)<=10)+1),(abs(n)<=10)+(i/5)*2),
y+(i%5)*dir*Q(9,11));
}
}[/0]
(Je l'ai mise en blanc pour que ceux qui ont peur peuvent s'abstenir de la lire.
)
), ta ligne est pas forcement illisible, mais la preuve, en lisant ton code, j'avais pas fait gaffe au code que t'avais apres certains de tes if...
), ca permet d'apprendre a modulariser son code, au final, il est generalement plus petit... et pour ce qu'on nous demande(demandait 