Ximoon (./86) :plus clair comme ça
Je pensais surtout à "WordList &cpuInstruction = *keywordlists[0];" pour dire ça

Ximoon (./86) :plus clair comme ça
Je pensais surtout à "WordList &cpuInstruction = *keywordlists[0];" pour dire ça

Ximoon (./84) :
"for (; sc.More(); sc.Forward())"
 



Ximoon (./92) :
- Si ce n'est pas un vrai for(), pourquoi mettre un for() ?

Ximoon (./92) :
- Je n'aime pas les appels de fonctions dans des tests, ça tu le sais

bool val = sc.More();
while (val != FALSE) // (sic !)
{
    ...
    val = sc.More();
    sc.Forward();
}Ximoon (./92) :
- On ne sait pas sur quoi on boucle (incrément ? bornes ?)



Ximoon (./92) :
Oui mais juste que je trouve ça super moche, pour plusieurs raisons :
- On ne sait pas sur quoi on boucle (incrément ? bornes ?)
- Je n'aime pas les appels de fonctions dans des tests, ça tu le sais- Si ce n'est pas un vrai for(), pourquoi mettre un for() ?
 (et même si "foreach" serait la meilleure solution, "for" me parait beaucoup plus logique qu'un "while" ici)
 (et même si "foreach" serait la meilleure solution, "for" me parait beaucoup plus logique qu'un "while" ici) ) ne m'ont pas fait penser spontanément à un foreach, je pensais qu'il parcourait le fichier, ou je ne sais pas quoi.
) ne m'ont pas fait penser spontanément à un foreach, je pensais qu'il parcourait le fichier, ou je ne sais pas quoi. 

 )
) (comme "break" à part pour les "switch")
 (comme "break" à part pour les "switch")Ouais, bon, pour le coup l'instruction "continue" est bannie de mon répertoire(comme "break" à part pour les "switch")

Folco (./103) :Tiens, bonne remarque !
Un avantage du for est qu'il embarque l'incrémentation (sc.Forward()). Donc on peut faire un continue où l'on veut dans la boucle, sans avoir à se soucier du compteur (et éviter une boucle infinie en cas d'erreur).


 (et pour les mêmes raisons que je donnais pour la présence d'une seule instruction "return").
 (et pour les mêmes raisons que je donnais pour la présence d'une seule instruction "return").vince (./102) :Ca n'est pas entièrement faux. L'abus de commentaire peut parfois au contraire rendre un code beaucoup moins lisible. Je le constate tous les jours, où à cause de certaines pseudo "bonnes pratique" on se retrouve avec des commentaire partout souvent pour mentionner des évidences.
entendu à l'instant au bureau : "de toutes manières, on évite de mettre des commentaires parce que ça alourdi inutilement les fichiers sources"
Ximoon (./109) :
et pour les mêmes raisons que je donnais pour la présence d'une seule instruction "return"

/* début du commentaire note : pas de commentaire fin du commentaire*/
 
        // Label and macro identifiers start at the beginning of a line
        // We set both as a label, but if it weren't one (no ':' at the end),
        // it will be changed as a macro identifier.
        if (sc.atLineStart && IsLabelStart(sc.ch))
        {
            sc.SetState(SCE_A68K_LABEL);
        }
        // Comments
        else if (sc.ch == ';')
        {
            sc.SetState(SCE_A68K_COMMENT);
        }
        // Decimal numbers haven't prefix
        else if (isdigit(sc.ch))
        {
            sc.SetState(SCE_A68K_NUMBER_DEC);
        }
        // Binary numbers are prefixed with '%'
        else if (sc.ch == '%')
        {
            sc.SetState(SCE_A68K_NUMBER_BIN);
        }        else if (sc.ch == '\"')
            sc.SetState(SCE_A68K_STRING2);
        else if ((sc.ch == '\') && (isdigit(sc.chNext)))
            sc.SetState(SCE_A68K_MACRO_ARG);
        else if (IsIdentifierStart(sc.ch))
            sc.SetState(SCE_A68K_IDENTIFIER);
 )
) Pen^2
 Pen^2else if ( sc.ch == '\"' ) {
   sc.SetState(SCE_A68K_STRING2) ; 
}
else if ( sc.ch == '\' && isdigit(sc.chNext) ) {
   sc.SetState(SCE_A68K_MACRO_ARG) ; 
}
else if ( IsIdentifierStart(sc.ch) ) {
   sc.SetState(SCE_A68K_IDENTIFIER) ;
}
