• [^] # Re: color2gray et organisation du code

    Posté par . En réponse à la dépêche G’MIC 1.6.2.0 : Colorisation de BD, transfert de couleurs, aide au détourage et autres réjouissances. Évalué à 10.

    Désolé je vais faire mon chieur, mais promis je ne le fais qu'une seule fois.

    Non ça n'a rien d'anecdotique.

    Déjà pour ton argument. Si 2 développeurs touchent un même fichiers ils touchent les même lignes c'est un fait, tu as des parties communes (les includes, les créations de macro,...). Mais même sans ça l'historique est bien plus compliqué à suivre.

    Le plus grave, c'est le risque important d'effets de bord que tu peux avoir, il faut être très précautionneux sur l'utilisation des namespaces pour pouvoir s'en sortir et quand tu commence à faire du code qui marche que quand tu as de très bons développeurs c'est que ton code va être cassé à un moment ou à un autre (j'ai des tas d'exemple d’excellents développeurs qui ont fait des erreurs - qui sont parties en prod - incroyables).

    D'un point de vu du travail, c'est bien plus compliqué de segmenter sa réflexion avec un (削除) gros (削除ここまで) énorme document, on est parasité par tout le reste, quand on découvre, on a tendance à craindre les effets de bord qu'on va créer donc on va se perdre à essayer de comprendre des parties inutiles...

    Pour ce qui est de ton repérage dans emacs : tu es obligé d'utilisé une manière de te repérer en une seule dimension (les lignes de ton fichier) alors que tu pourrais avoir un repérage en 2 dimensions (les numéros de lignes et les noms de fichiers). Tu ne peux pas te dire que les lignes autour de 3000 s'occupe de tel algo, parce que le refacto des lignes entre 1000 et 1200 ont complètement déplacé tes lignes.

    Au niveau test c'est aussi vachement moins sympa d'avoir un énorme fichier.

    Sincèrement ça marche probablement très bien parce que tu as pris l'habitude, mais je ne doute pas que c'est un frein énorme à la contribution extérieur et le fait que la question soit revienne régulièrement sur le tapis me semble être un indicateur de cet état de fait (tu as des gens qui se sont suffisamment intéressé à ton travail pour plongé dans ton code, mais ils ont rencontré des difficultés).

    Je vais le dire autrement, il me semble que G'Mic est un super terrain de jeu pour les algorithme en tout genre sur le traitement d'image (c'est ce qui ressort des tes journaux, dépêches et commentaires), ce serait AMHA génial d'avoir quelque chose de suffisamment modulaire pour qu'ajouter un algo consiste à créer un fichier qui va bien puis à ajouter ce fichier dans la liste des autres fichiers. Ça permettrait :

    • de diminuer fortement la complexité pour quelqu'un qui a une idée et qui voudrait la tester (il pourrait suivre un tuto sur la manière d'ajouter son algo)
    • de pouvoir plus facilement tester chaque algo
    • de pouvoir choisir de ne pas intégrer tous les algo ou d'avoir des paramétrages des algo au moment de la compilation sans pour autant rendre la maintenance immonde avec des milliers de #ifdef

    Sincèrement si les gens découpes leur fichier, ce n'est pas une question de mode, de tique bizarre, ça n'est pas arrivé avec la dernière techno que tu n'aime pas, c'est pas lié à un buzzword qui n'aurait pas de sens, etc

    Tiens au fait, ça ne te donne pas des temps de compilation à crever de vieillesse devant son écran de redevoir compiler le tiers de ton logiciel à chaque modification ? Même quand tu expérimente ton algo ?

    Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)