132Fermer134
Kevin KoflerLe 31/12/2012 à 13:45
robinHood (./126) :
moi je crayonne kevin pour le coup, rien ne m’énerve plus qu'une foret de fichiers et de classes

Je suis content de ne pas être le seul!
RHJPP (./127) :
Ce n'est pas parce qu'avoir trop de fichiers est mauvais qu'il faut s'obstiner à tout mettre dans le même.

Ce n'est pas le cas, ce n'est que le fichier principal, KTIGCC a d'autres fichiers source. (En revanche, pour les petits programmes simples en C classique, j'aime bien le "tout en un .c".)
Et pas besoin de faire de la programmation orientée objet pour ça, des ensembles indépendants de méthodes, de types, de classes ou de ce que tu veux devraient se trouver dans des fichiers ou dossiers différents.

Mais s'ils ne sont pas indépendants?
en fait, ce sont des lignes répétées plusieurs fois noyées dans le reste, car il n'y a pas de méthodes qui font des tâches simples dans ce code

Il y a des #define tout au début pour ça, si tu trouves encore des duplications, envoie-moi un patch qui en fait des macros supplémentaires. tongue

(Et oui, je sais que les #define donnent du code plus grand, mais on n'est pas à l'octet près sur PC.)
Brunni (./128) :
Tes excuses sont mauvaises Kevin (mais je pense que tu le sais), si tu veux apporter une contribution à un projet la moindre des choses ce serait de le récupérer localement, déjà, puis de t'assurer que tu peux le compiler histoire de tester ta modif, ce qui te prendra de toute façon une bonne heure, alors l'indexation à côté...

La manière dont je travaille en général, c'est, je détarre les sources, je fais une copie, je fais mes modifications dans la copie, je fais un diff -Nur, je rajoute le patch au fichier .spec, je committe et pushe le tout dans le git de Fedora et je l'envoie au système de compilation Koji. Si ça ne compile pas, Koji me renvoie une erreur et je corrige le problème. Si ça compile, j'envoie le patch au projet upstream.
GoldenCrystal (./132) :
T1 mais en plus les 5000 lignes de Kevin, c'est 5000 lignes avec quasiment aucun espace entre les blocs. sick

Je déteste l'abus de lignes blanches, ça rend le code plus long à lire (il faut défiler plus) et ça augmente artificiellement le nombre de lignes (déjà suffisamment élevé). Et en plus, si on met des lignes blanches partout, on ne voit plus les endroits où il en faut vraiment, sauf si en en met 2 à la suite sick dans ce cas (voire plus sick sick sick).
Et ça m'éclate car quand j'écris des fonctions qui font plus de deux scrollbars de long je ne suis pas très fier de moi, mais là j'ai l'impression que ça ne dérange pas trop l'auteur. cheeky

Je déteste les limitations artificielles. Une fonction a la longueur nécessaire pour faire son travail, je ne vais pas la couper artificiellement juste pour tenir en un maximum de taille arbitraire qui n'a aucune justification technique.
* pour que ce soit vraiment lisible faut qu'on puisse lire le code d'une fonction comme un paragraphe de texte (avec interprétation des idées du langage de programmation utilisé bien sûr cheeky) et qu'on en retire l'explication de ce que fait la fonction, sinon ça compte pas.

Pour moi, c'est bien le cas de mon code.
(On sait tous écrire du code avec des variables de une lettre, des tables de mapping cryptiques et des noms de fonctions indéchiffrables. Mais ce n'est pas ce qu'on peut considérer comme lisible tongue)

Regarde le code de obj2ti si tu veux ça. grin (C'est une des raisons pour lesquelles on l'a viré.) Je n'écris pas du code comme ça, moi!