Convention syntaxique.

[Vaasref]

Alors je trouve que vous codez comme des cochons.

Des fois vous mettez les registes en majuscules d'autre fois non, encore d'autres fois vous mettez des Opcodes en majuscules, etc. Et c'est juste une horreur j'ai quand même un certain niveau de tolérance, mais là franchement c'est trop.

Donc moi je propose quelque chose comme ça :

:fonction
    set A, B
    ifn A, C
        set A, C

C'est simple ça marche c'est lisible.

Pour les Tab c'est pas aussi simple donc bon, là moi je suis plutot tolérant, parce que c'est pas toujours simple d'indenter correctement en DASM, mais pour les fonction et les if il en faut quand même.

[L3nn0x]

J'indente toujours les if. Pas le reste il est vrai...

[Vaasref]

L'indentation c'est le moins pire, ça se corrige facielement, mais pour le reste...

[Vaasref]

Missclick

[Yamakaky]

https://github.com/FrOSt-Foundation/FrOSt/wiki/Conventions-de-codage

C'est récent, le code 'ancien' est pas migré. Je peux m'en occuper si vous voulez (merci sed ^^).

[L3nn0x]

J'aime pas la première tabulation directement après le label. Je trouve que ça mélange un peu fonctions/boucles/conditions. Après, je suis contre les espaces autours du "+" et du "-", et de l'espace après la virgule. Ensuite, les instructions push,pop,seek ne devraient pas être en majuscules pour moi, vu que c'est la contraction de "["+"SP"+"..."+"]". Enfin, pas tous les éditeurs permettent d'utiliser le caractère spécial pour la tabulation. Donc c'est un peu dommage de n'accepter que ça.

Bon, après, ce n'est que mon humble avis.

[Vaasref]

Moi les "push" et "pop" c'est "PUSH" et "POP" ya pas moyen. En fait c'est simple sauf pour les labels ce qui est après un opcode c'est en maj pour moi.

Et puis pour la virgule c'est juste la règle point, c'est un caractère de ponctuation on respecte la règle qui va avec et qui dit toujours un espace après.

P.S : Je me foutais de la gueule de ceux qui disaient qu'il était possible de voir qui avait codé quoi rien qu'en regardant le code, est bah je reconnais mon erreur, je viens de tomber sur un bout de code de Fearie, eh bah c'est flagrant.

[Yamakaky]

Pour les tab/space, ça n'a pas d'importance, mais il faut choisir. Je dirais space.

[L3nn0x]

XD Moi, du moment que le code est bon, je me fiche un peu de sa mise en forme... Après, je comprends tout à fait que certains ne veulent pas lire du code ni aéré ni commenté.

Ps : tu devrais voir certains codes en C++ que j'ai fais Vaasref, je crois que tu tomberais dans les pommes... :p

[azertyfun]

On NE fait PAS du code avec des ESPACES pour indenter depuis environ 30 ans que le caractère d'indentation existe. Avec un tab tu peux choisir le nombre d'espaces qui le représenteront, et c'est 20 fois moins chiant à écrire ou à effacer que des espaces.

@FaerieFrOSt : Oui c'est bien sympa de faire du code à l'arrache, mais non :p Dans une fonction, et ce depuis que les langages de programmation existent, on indente le code une fois. C'est logique c'est basique et ça me semble clair ^^'

[Yamakaky]

@azertyfun : si ton IDE est bien configuré, l'insertion de spaces est transparent. On peut configurer DevCPU (eclipse inside) pour insérer des spaces et pas de tab.

[azertyfun]

Wais mais tu peux dire que tu préfères que le tab affiche 4, 3 ou deux espaces mais tu peux pas décider si tes 3 espaces se transforment en 4 espaces. Et ça fait quand même chier pour effacer les 4 espaces, c'est plus simple avec un tab. Franchement je vois pas quel est l'avantage d'utiliser des espaces. C'est une habitude qu'ont les programmeurs de plus de 50 ans, avant même que la touche tab n'existe.

[L3nn0x]

Le problème, c'est que certains éditeurs ne connaissent pas le caractère "tab", ou le remplacent par des espaces.

[azertyfun]

Ca s'appelle pas un éditeur, ça fait 10 ans que même le bloc-notes le reconnait. Ou alors sous linux vous êtes vraiment restés en 1980 0_o

[Yamakaky]

C'est un éditeur de merde alors. Emacs vim et nano les gèrent.

[L3nn0x]

Bon bon, si vous le dites.

[azertyfun]

Nan mais c'est quoi ton éditeur tout pourri qui gère pas tab ? O__o

[Yamakaky]

Pour en revenir au débat, tab/space n'a pas beacoup d'importance (l'indentation est simple et assez peu présente), mais faut se mettre d'accord car je pense que tout le monde est d'accord pour dire que mélanger les 2, c'est le maaaaaaal XD Perso, je pencherai pour space, juste parce que nano ne permet pas de toggle space/tab uniquement pour un type de fichier, c'est un toggle global.

[Vaasref]

Moi j'en ai rien à branler même que ce soit mélanger, c'est le comment de l'indentation qui m'importe.

Pour moi une fonction ou une sous fonction le label est forcément sans tab. Ce qui permet de savoir si on peu intervertir le code contenu dans le label ou pas.

:prog_fonction
    <code>
    :prog_fonction_loop0
        <code>

:prog_fonction_sous-fonction
    <code>

là je sais que je peux bouger la sous fonction par contre

:prog_fonction
    <code>
    :prog_fonction_loop0
        <code>
    :prog_fonction_sous-fonction
    <code>

là je sais qu'il faut pas la bouger parceque ça peut "venir d'en haut"

[azertyfun]

Ben disons que la prochaine fois que vous aurez une emmerde dans votre code vous aurez aucune chance de vous faire aider si vous indentez pas assez, avec des espaces, mal, que vous ne commentez pas et que vous ne respectez aucune autre convention...

[Vaasref]

Euh c'est plutot l'inverse qui se passe ça merde parce que c'est quelqu'un d'autre qui pige pas comment ça marche.

Et puis franchement azertyfun c'est quoi ce vieux chantage/menace like ?

[azertyfun]

Ben non mais ça m'énerve quand je veux aller voir ce qui marche pas dans le scheduler et je tombe sur un code sans aucune identation (à part les IFE, yepee), sans commentaire avec une syntaxe horrible (pas d'espaces après les virgules, push pop peek en minuscules). Va un peu voir ça : https://github.com/FrOSt-Foundation/FrOSt/blob/1c99a52497c08ccd3ab949c2ecd974647962e686/kernel/Scheduler.dasm Et dit moi si c'est un code qui donne envie d'être débuggé. La première chose que j'ai faite quand j'ai eu le droits de commit, c'est réindenter l'intégralité du projet, parce que j'arrivais pas à comprendre la moitié du code !

[Vaasref]

Ouais bah dans ta diligence tu t'es trompé. Dommage hein ? Moi je préfère pas indenté que mal.

D'ailleurs je trouve que tu as un ratio d'erreur dans tes commits plutôt grand, bah j'en fais pas un foin. Je l'ai pas tellement entendu réclamé de l'aide donc bon, si il gère, il gère.

Tu sais, on est en collaboration, apporter sa pierre a l'édifice, c'est pas nécessairement travailler sur la même pierre que le voisin.

[azertyfun]

À la base c'est pas moi qui voulait faire des conventions de syntaxe hein. M'enfin si c'est "chacun son code" d'accord ^^

[L3nn0x]

Techniquement, j'ai rien demandé non plus, mais j'ai quand même remercié Azertyfun qui s'est donné la peine d'indenter comme il le souhaitait. Il l'a fait, je vois pas pourquoi je me plaindrais. ;)

Après, je suis d'accord que pour se faire aider, c'est plus facile si c'est bien présenté et commenté. D'ailleurs, à chaque fois que je demande de l'aide, je commente mon code. (Par exemple pour la nouvelle branche avec le sheduler, j'ai commenté parce que j'ai des bugs et que ça peut aider celui qui vient pour tenter de corriger.)

Par contre, si tout fonctionne, je vois pas pourquoi il faudrait commenter plus que l'entête de la fonction. Après tout, elle fonctionne, donc si quelqu'un veut vérifier/améliorer la fonction, qu'il se débrouille. S'il ne comprend pas ce qui s'y passe, c'est qu'il n'a pas le niveau requis (ou qu'il a la flemme de comprendre), donc qu'il n'a pas besoin de toucher à cette fonction.

Encore une fois, ce n'est que mon humble avis.

Ps : pour les conventions de de syntaxe, c'est à Yama qu'il faut s'adresser, et c'est vraiment récent. Donc on a un peu de mal à s'y mettre, c'est tout. :)

[azertyfun]

Pour les têtes de fonctions, notemment dans les dirvers, je suis d'accord. Mais dans un module complet de l'OS, genre un scheduler ou un gestionnaire de mémoire, ne serait-ce qu'expliquer en gros est important. Surtout si on veut que notre OS puisse servir à certains pour se perfectionner en DASM (après l'hypotétique sortie du jeu ça risque d'être vraiment le cas)

[Yamakaky]

Si vous voulez, je peux renormaliser le code à grand coups de sed ^^

[Vaasref]

Problème c'est qu'il ne suffit pas d'indenter il faut aussi comprendre le code.

[azertyfun]

Oui mais un code indenté est plus compréhensible. Imagine le pauvre gars qui veut se perfectionner en DASM (bah oui, FrOSt est libre de droits donc y'a des chances pour que ça arrive), et qui tombe devant ça !

[Vaasref]

Tu répondais pas à moi j'espère si ?

[Yamakaky]

Au niveau de l'indentation, j'ai fait le tour des fichiers et une grosse majorité sont indentés. Du coup, on garde les tabs ou spaces ? Autant se décider maintenant et s'y tenir, vu que c'est transparent dans l'éditeur.

[Vaasref]

Mais les tabs !

[L3nn0x]

@Azertyfun : Si un bonhomme veut se perfectionner en dasm, je doute qu'il aille voir la fonction la plus complexe d'un OS... Il penchera plutôt pour la console ou les drivers.

[azertyfun]

Dans tous les cas il faut montrer l'exemple et lui donner un code aussi lisible que possible. Sinon oui on garde des tabs, vu que c'est transparant dans l'éditeur (au contraire des espaces qui eux sont chiant à gérer dans tous les éditeurs)