Touyt ca pour dire que ya çç% des gens qui font pas de l'indentation, mais un semblant d'indentation (c'ad on indente quand on veut..)
Link a écrit :
PS: L'écran DOS peut faire 50 lignes: mode con lines=50
Kevin Kofler a écrit :
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.
tu t'en est servi plus d'une heure au moins (1h, cad le temps de voir que le 100eme de ses possibilites et de dire "berk c pas bo ca pue emacs"), et puis emacs graphique est tres beau, et incomparablement mieux que cette tigcc ide de m*** ()
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 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.
).
Vive les normes contre-productives!
(et en general, vu ce qu'on doit faire, plus c court plus c efficace...)
Mais le standard, c'est 24 lignes (vt100) ou 25 lignes (configuration standard de MS-DOS).
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.
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;
[i]for (truc = 1; truc++ < machin;[/i][i]) tab[truc] = chose;[/i]
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.
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.
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.
Ben oui, ma préférence personnelle est qu'il y a plein de "sauf si".
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:__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)); } }
(Je l'ai mise en blanc pour que ceux qui ont peur peuvent s'abstenir de la lire.
Vive les normes contre-productives!
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));}
}
sBibi a écrit :
et puis a mon avis, du Vertyos ca aurait plutot ete un truc du genre:
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));} }
pourtant apparemment selon bob ya eu une grande amelioration non? [ftp83plus]
a écrit : Link> évolue !!!
char GetListArg(ESI *list_ptr)
{
if(count[0] == maximum)
{
error("Arg : Trop d'arguments LIST");
return cycle | capture;
}
switch(GetArgType(*list_ptr-1))
{
case STR_TAG:
if(count[1] == maximum)
{
error("Arg : Trop d'arguments NUM");
return cycle | capture;
}
vartype[count[0]] = ((count[1]++) <<1 );
break;
case NEGINT_TAG: case POSINT_TAG:
if(count[2] == maximum)
{
error("Arg : Trop d'arguments STR");
return cycle | capture;
}
vartype[count[0]] = ((count[2]++) << 1 ) + 1;
break;
default:
*list_ptr = next_expression_index(*list_ptr);
error("Arg : LIST invalide");
return cycle | capture;
break;
}
varvalue[count[0]++] = *lst - 1;
*list_ptr = next_expression_index(*list_ptr);
return stop;
}
Link a écrit :VESA2 c koi?
j'aimerais bien... $$$
au passage t'aurais pas une carte graphique pas cher mais compatible VESA2? Parce que ma S3 trio me gène pour ZSNES...
void exe_alng(long lng)
{
unsigned short siz=0;
long cpy;
if((cpy=abs(lng))) do siz++; while((cpy>>=8));
if(rtc<(siz+2) && !exe_amod(rtm+2500)) return;
ret[rtc-1]=lng>=0?POSINT_TAG:NEGINT_TAG;
ret[rtc-2]=siz;
for(cpy=siz;cpy;cpy--)
{
ret[rtc-cpy-2]=lng%256;
lng>>=8;
}
rtc-=(siz+2);
}
) facilement.