Coloration Motorola 68k pour Code::Blocks - Page 5

Mais quel rapport avec le vert fluo ?

Hmmm, Pen^2, bien que je n'aime pas trop ta technique accoladatoire, je dois bien reconnaitre que :
- ça crée l'interligne souhaité
- les accolades évitent toute équivoque
- si on veut rajouter un traitement après le if, les accolades sont déjà là, pas besoin de tout péter

Mais j'aime bien quand les colonnes de mes accolades ouvrantes et fermantes sont les mêmes. Faut que je réfléchisse à la question.

L'est pas fluo
Mais bon ça n'est pas trop directement le sujet même si un peu quand même

Folco (./122) :
Hmmm, Pen^2, bien que je n'aime pas trop ta technique accoladatoire, je dois bien reconnaitre que :
- ça crée l'interligne souhaité
- les accolades évitent toute équivoque
- si on veut rajouter un traitement après le if, les accolades sont déjà là, pas besoin de tout péter

Mais j'aime bien quand les colonnes de mes accolades ouvrantes et fermantes sont les mêmes. Faut que je réfléchisse à la question.

J'avoue que je n'écrivais pas l'accolade quand elle n'était pas nécessaire. Finalement, je trouve c'est plus équilibré avec. Il n'y a pas vraiment de raison de ne pas l'écrire, ça fait deux écritures distinctes pour la même chose.

Quand les blocs sont un peu gros, je saute rapidement une ligne en plus de l'accolade. Mais typiquement, je trouvais ça trop éloigné pour des si petits blocs dans ton exemple du ./116

Ximoon (./123) :
L'est pas fluo
Mais bon ça n'est pas trop directement le sujet même si un peu quand même

Il n'est pas gris, en tout cas

Ximoon (./109) :
./105 > exactement (et pour les mêmes raisons que je donnais pour la présence d'une seule instruction "return").

Pourtant dans certains cas, seul l'utilisation de goto/break permettent de n'avoir qu'un seul return, sans bloater le code

Une variable d'état, c'est pas tellement bloatant.

C'est le seul moyen de mettre des breakpoints comme il faut et de savoir ce qui se passe en intégration. Et puis ce n'est pas moi qui ai fait les normes de codage, même si j'y adhère

Tiens, question de concept du parser :
Immaginons que j'ai une ligne de code asm :
move.w #$12AB%01010,d0
En passant sur les détails de la coloration du move et du d0, si on regarde "l'entier", il est évidemment invalide.
Seulement, le parseur va y voir un nombre hexa valide (et le colorer en tant que tel), puis le '%' (donc l'état "hexa" sera droppé), puis comme '%' est un indicateur de nombre binaire, il va entrer dans l'état "binaire". On aura donc réussi à colorer cet truc "$12AB%01010", alors qu'en soi ça n'a aucun sens.

Est-ce au boulot du parser d'analyser le code pour se dire "tiens, il y a bien des nombres, mais à la suite comme ça c'est pas normal. Donc je droppe la coloration pour le nombre binaire, et tant qu'à faire pour "ce qu'il y a avant" (c'est possible de lui dire ça).

Ou est-ce que le parser doit être bête : "un nombre hexa ? je le colore. Un nombre binaire ? Pas de souci, je colore aussi" ?


Parce qu'en soi, il est certainement possible de faire le parser "parfait" qui ne colore que le code valide (en faisant l'analyse que ferait un assembleur en fait), mais c'est beaucoup plus lourd évidemment.

Bah, à ta place je m'embêterais pas. De toute façon, tu vas bien compiler ton code, l'erreur apparaîtra à ce moment-là.

Dans la logique d'un parseur simple sans backtracking, tu devrais faire soit nombre hexa + nombre binaire (deux parties séparées), soit nombre hexa + caractère invalide + nombre. En fait, ça ça va dépendre de la logique que tu choisis, mais en aucun cas tu ne devrais colorer une chaîne invalide dans son intégrité.
Les questions que tu dois te poser sont;
Est-ce que le % a une signification spéciale à l'intérieur d'un nombre hexa ? (Non)
Est-ce que le % a une signification spéciale ? (Par exemple modulo, mais je ne crois pas que ça soit le cas ici)
Est-ce que mettre deux nombre à la suite de l'autre est une opération valide ? Qui plus est sans espaces ?

Après, ce n'est pas non plus au colorateur de faire une analyse syntaxique évoluée, son boulot est juste de faire une coloration du code qui soit la plus juste possible, en tenant compte des éventuelles erreurs, donc le backtracking pour détecter que toute la chaîne #12AB%01010 est invalide, il peut le faire, mais il ne devrait pas (ça devrait faire partie d'un autre ensemble de fonctionnalités plus avancées de l'IDE)

Merci pour vos réponses, bien qu'elles soient opposées dans le principe.

Pour le moment, je fais juste des petits ajustements de ce type. Exemple, je ne colore un < ou un > que s'il sont suivis du même symbole (décalage de bits). Mais ça devient comprexe si on veut gérer toutes les instructions et ce à quoi elles ont droit. Ca équivaut à réécrire une table pour les strings des instructions, et une table de leurs droits (mnémoniques autorisées pour les longueurs, nombre d'arguments, type de ces arguments etc...). Les fonctions built-in permettent de reconnaitre une instruction, sans dire laquelle est-ce.
Ca deviendrait à mon avis une usine à gaz, je préfère rester sur une analyse très primaire. Je verrai si je peux ajouter deux choses sans trop en rajouter : ne rentrer dans l'état "nombre" que si l'on est dans l'état "default" par exemple, etc...

Ayé, cette fois c'est au poil pour les fonctionnalités, ça marche de partout !

Un petit screen : Fichier joint : (snapshot9.png)

C'est très chargé en style et coloré, mais c'est pour montrer les différentes possibilités.
Voici ce que le lexer identifie, et qui est donc paramétrable séparément en couleur et style :
- style par défaut
- commentaires
- nombres décimaux
- nombres binaires
- nombres hexadécimaux
- chaines (doubles quotes)
- chaines (simples quotes)
- opérateurs mathématiques (plus la virgule, c'est toujours le séparateur des opérandes)
- les instructions processeur
- les instructions étendues (celles mixées pour le linker, genre 'jbsr' ou 'jra')
- les registres
- les directives
- les arguments de macro (\1, \2, ...)
- les labels
- les identifiants divers (macros, constantes, offsets, labels, ...)
- les déclarations de macro

Voilà, ça fait 15 styles bien distincts, qu'on peut mettre à son gout.
S'il en manquent qui vous viennent à l'idée, n'hésitez pas.
(et si un graphiste veux bien me donner des codes couleurs qui rendraient bien, alors là je lui roule une moche de gamelle )


Et si certaines bonnes volontés ont encore la force d'apporter des critiques à mon code, je les en remercie d'avance. J'ai essayé de faire un mix de vos conseils : Des commentaires pas trop intrusifs (entre les lignes), des accolades discrètes mais efficaces, des commentaires de fonctions et des defines, sans toute fois tomber dans un code... aérien.

Merci encore à tous.

Au fait, le lien : http://www.mirari.fr/G0Sn
(téléchargez pas tous à la fois svp, vous allez encore faire tomber mirari )

Beau travail

Folco (./116) :
Uther : Si t'as des critiques par rapport au post ./81, c'est le moment, merci d'avance (peut-être )

Alors il s'agit des règles personelles, à toi de voir si ça te convient, mais quand je coupe une expression sur plusieurs lignes:
- je fais en sorte que la ligne suvante commence par un opérateur, ca crée un petit décalage avec la première ligne, mais ca permet de voir au premier coup d'oeil qu'il s'agit d'une expression coupée.
- je fais un retour a la ligne avant le "{". D'habitude, je préfère le laisser sur la même ligne car l'indentation suffit, mais dans ce cas précis, ca permet de bien voir la distinction entre l'expression et le bloc qui le suis.

}

ex:if ((sc.state == SCE_A68K_COMMENT)                                                           // Comment 
    || ((sc.state == SCE_A68K_NUMBER_DEC) && isdigit(sc.ch))                                 // Decimal number 
    || ((sc.state == SCE_A68K_NUMBER_BIN) && IsBin(sc.ch))                                   // Binary number 
    || ((sc.state == SCE_A68K_NUMBER_HEX) && isxdigit(sc.ch))                                // Hexa number 
    || ((sc.state == SCE_A68K_MACRO_ARG) && isdigit(sc.ch))                                  // Arg of macro 
    || ((sc.state == SCE_A68K_STRING1) && (sc.ch != '\''))                                   // String single-quoted 
    || ((sc.state == SCE_A68K_STRING2) && (sc.ch != '\"'))                                   // String double-quoted 
    // Label. ' ' and '\t' are needed to handle macro declarations 
    || ((sc.state == SCE_A68K_LABEL) && (sc.ch != ':') && (sc.ch != ' ') && (sc.ch != '\t')) 
    || ((sc.state == SCE_A68K_IDENTIFIER) && (sc.ch < 0x80) && IsIdentifierChar(ch)))        // Identifier
{          
    continue; 

autant couper correctement alors

if(     (sc.state == SCE_A68K_COMMENT   )                                                    // Comment  
    || ((sc.state == SCE_A68K_NUMBER_DEC) && isdigit(sc.ch))                                 // Decimal number  
    || ((sc.state == SCE_A68K_NUMBER_BIN) && IsBin(sc.ch))                                   // Binary number  
    || ((sc.state == SCE_A68K_NUMBER_HEX) && isxdigit(sc.ch))                                // Hexa number  
    || ((sc.state == SCE_A68K_MACRO_ARG ) && isdigit(sc.ch))                                 // Arg of macro  
    || ((sc.state == SCE_A68K_STRING1   ) && (sc.ch != '\''))                                // String single-quoted  
    || ((sc.state == SCE_A68K_STRING2   ) && (sc.ch != '\"'))                                // String double-quoted  
    // Label. ' ' and '\t' are needed to handle macro declarations  
    || ((sc.state == SCE_A68K_LABEL     ) && (sc.ch != ':') && (sc.ch != ' ') && (sc.ch != '\t'))  
    || ((sc.state == SCE_A68K_IDENTIFIER) && (sc.ch < 0x80) && IsIdentifierChar(ch)))        // Identifier 
{           
    continue;  
}  

Merci à tous.

Meric Uther, c'est bien vu ton premier point, en effet on voit immédiatement les conditions, c'est très clair comme ça, bonne idée.
Pour les accolades, moi aussi je préfère ce style, mais pour les toutes petites conditions (une seule instruction au cas où la condition est vraie), ça fait un code très long, donc plus chiant à bien visualiser.

Bref, ça dépend du source qu'on écrit je pense.

squalyl -> Oui, ça m'arrive de faire des jolis truc comme ça, je trouve ça chouette en effet.

Folco (./138) :
Pour les accolades, moi aussi je préfère ce style, mais pour les toutes petites conditions (une seule instruction au cas où la condition est vraie), ça fait un code très long, donc plus chiant à bien visualiser.

Moi c'est l'inverse : pour les accolade d'habitude je ne fait jamais de retour à la ligne: l'indentation permet de voir simplement qu'on est dans un bloc.

Je fais juste une exception pour les blocs qui suivent une expression sur plusieurs lignes car du coup l'indentation n'est plus aussi évidente. Dans ton code, pour l'exemple que j'ai pris, le "continue" se retrouve aligné avec l'expression, ce qui donne l'impression au premier coup d'oeil qu'il en fait partie.

moi j'indente que pour les fonctions.

Uther (./139) :
Je fais juste une exception pour les blocs qui suivent une expression sur plusieurs lignes car du coup l'indentation n'est plus aussi évidente. Dans ton code, pour l'exemple que j'ai pris, le "continue" se retrouve aligné avec l'expression, ce qui donne l'impression au premier coup d'oeil qu'il en fait partie.

Je pense en effet que ça résoud proprement le problème de visibilité du "continue", merci bien pour le tip.

void function()
{
    if(chose) {
        prout();
    }
}

ça permet de bien voir le proto de la fonction.

et au boulot, on nous oblige à faire:

void function()
    {
    if(chose)
        {
        prout();
        }
    }

Tiens, j'ai corrigé un bug (les arguments de macros dont le numéro était >= 10 étaient mal parsés).
J'ai mis l'archive a jour (lien identique).

Je ne vous félicite pas pour votre review les gars

squalyl (./143) :

void function()
{
    if(chose) {
        prout();
    }
}

ça permet de bien voir le proto de la fonction.

et au boulot, on nous oblige à faire:

void function()
    {
    if(chose)
        {
        prout();
        }
    }

(je compatis)

Folco (./144) :
Tiens, j'ai corrigé un bug (les arguments de macros dont le numéro était >= 10 étaient mal parsés).
J'ai mis l'archive a jour (lien identique).

Je ne vous félicite pas pour votre review les gars

Justement, on en discutait : on se demandait si tu allais finir par trouver

Pen^2: merci

Pen^2 (./146) :

Folco (./144) :
Tiens, j'ai corrigé un bug (les arguments de macros dont le numéro était >= 10 étaient mal parsés).
J'ai mis l'archive a jour (lien identique).

Je ne vous félicite pas pour votre review les gars

Justement, on en discutait : on se demandait si tu allais finir par trouver

Oué style genre

squalyl (./143) :

void function()
{
    if(chose) {
        prout();
    }
}

ça permet de bien voir le proto de la fonction.

et au boulot, on nous oblige à faire:

void function()
    {
    if(chose)
        {
        prout();
        }
    }

Ok, Tu voulais dire que tu fais un retour a la ligne seulement pour les fonctions.
Si tu n'indentes que les fonction ça donne plutôt ça:

void function() { 
    if(chose) { 
    prout(); 
    } 
}

d'ou le

squalyl (./143) :et au boulot, on nous oblige à faire:

void function()
    {
    if(chose)
        {
        prout();
        }
    }

Le style "whitesmith". Il devrait juste y avoir une loi pour interdire ça.
Pour plus d'info sur les différents styles : http://en.wikipedia.org/wiki/Indent_style

ah oué je confirme le ce serait illisible . j'ai mal décrit le truc.

edit : ah ça a un nom cette horreur en plus?