Un langage sans "if" - Page 5

Avec un environnement de développement moderne tu peux en un clic (ou un raccourci clavier) aller à la définition d'une méthode ou d'une classe, et si le développeur n'a pas fait trop de zèle il n'y a pas 50 fichiers à parcourir, juste deux ou trois. C'est sûr que ça reste plus long que si la réponse était directement sous tes yeux, mais de toutes façons tu ne pourras pas avoir tous les chemins de code dans un seul fichier alors autant adopter une séparation claire. Où plutôt si, tu peux avoir tous les chemins de code dans un seul fichier en faisant exactement ce que tu fais et en se retrouvant avec des fichiers de 5000 lignes. Du coup au lieu de naviguer vers d'autres fichiers, tu fais des recherches au sein d'un même fichier pour essayer de localiser la partie qui t'intéresse au milieu d'un pâté de trucs sans rapport. Je ne trouve pas que ce soit tellement plus efficace, au contraire.

(sinon pour ./120 c'est une erreur de design, encore un problème différent mais ça ne justifie toujours pas cette horreur ^^)

Zeph (./121) :
Avec un environnement de développement moderne tu peux en un clic (ou un raccourci clavier) aller à la définition d'une méthode ou d'une classe, et si le développeur n'a pas fait trop de zèle il n'y a pas 50 fichiers à parcourir, juste deux ou trois. C'est sûr que ça reste plus long que si la réponse était directement sous tes yeux, mais de toutes façons tu ne pourras pas avoir tous les chemins de code dans un seul fichier alors autant adopter une séparation claire. Où plutôt si, tu peux avoir tous les chemins de code dans un seul fichier en faisant exactement ce que tu fais et en se retrouvant avec des fichiers de 5000 lignes. Du coup au lieu de naviguer vers d'autres fichiers, tu fais des recherches au sein d'un même fichier pour essayer de localiser la partie qui t'intéresse au milieu d'un pâté de trucs sans rapport. Je ne trouve pas que ce soit tellement plus efficace, au contraire.

Si je regarde vite fait les sources d'un projet tiers pour voir ce qu'il fait, ou pour patcher un problème pour mon paquetage de ce projet, je n'ai aucune envie d'importer le projet dans KDevelop et d'attendre qu'il me calcule le cache nécessaire pour exactement ce genre de navigation (ce qui peut prendre quelques minutes pour un gros projet, surtout sur mon PC qui commence à dater), je regarde directement les fichiers avec F3 dans Krusader (voire sur l'interface web du SCM) et donc du coup, si, c'est très agaçant de devoir changer de fichier sans arrêt.

(sinon pour ./120 c'est une erreur de design, encore un problème différent mais ça ne justifie toujours pas cette horreur ^^)

Ce n'est pas une erreur, mais au contraire un design puissant qui permet des features uniques, et en particulier de faire ce qu'attend l'utilisateur (qui n'a pas été préalablement indoctriné par d'autres EDIs moins bien conçus), à savoir de compiler ce qu'il voit dans l'EDI, pas ce qu'il a enregistré auparavant.

Bon, je crois que c'est une fois de plus pas la peine de discuter pendant 107 ans, je trouve tes choix très mauvais, mais comme il n'y a fort heureusement à peu près aucune chance pour qu'on travaille ensemble un jour c'est pas bien grave

Kevin Kofler (./122) :
surtout sur mon PC qui commence à dater

1) C'est TOI qui refuses de mettre ses composants à jour sous de "faux"/"mauvais" prétextes (que ça pollue alors que les mêmes composants dans un panneau solaires tu trouves ça noble)
2) Dans deux semaines les soldes commencent, profites-en
3) Si tu comptes développer des softs plus complexes qu'un hello world alors il faudra songer à changer ton Oric(*) pour une machine mieux adaptée...


(*) A titre d'exemple

4) De la part de quelqu'un qui a reproché aux autres pendant des années d'utiliser des machins obsolètes, c'est assez gonflé

moi je crayonne kevin pour le coup, rien ne m’énerve plus qu'une foret de fichiers et de classes

l'argument de l’obsolescence des machines n'en est pas un, rejected.

un programme spécifique ne devrais pas être nécessaire pour comprendre du code

je code tout les jours avec kate, et cela me suffit largement, certes je ne développe pas d'os ou de projet de 200000 lignes, mais la clarté de la présentation d'un projet ne vas pas forcément de pair avec le nombre de fichiers et de classes, rajouter des couches et des couches est tout sauf clair, et chercher comme le dit kevin qq chose, le trouver mais en fait non il appelle machin, qui appelle truc qui appelle foo puis finalement bar avant d'en fait rappeler machin c'est totalement débile et 99% du temps inutile

la vrai complexité du code c'est de l'écrire simple

robinHood (./126) :
moi je crayonne kevin pour le coup, rien ne m'énerve plus qu'une foret de fichiers et de classes

Ce n'est pas parce qu'avoir trop de fichiers est mauvais qu'il faut s'obstiner à tout mettre dans le même. 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. On devrait au moins ne pas avoir de code de l'un des ensembles entrelacé avec celui d'un autre. Il y a plusieurs raisons à ça, parmi elles : réutilisation du code, changement d'un élément simplement en respectant l'interface et aussi développement simplifié (on trouve plus rapidement une fonction déjà existante quand elle se trouve à un endroit logique, ça évite de l'écrire plusieurs fois (comme on en trouve dans le code dont Kevin Kofler a donné un lien (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)).

Kevin Kofler (./122) :
Ce n'est pas une erreur, mais au contraire un design puissant qui permet des features uniques, et en particulier de faire ce qu'attend l'utilisateur (qui n'a pas été préalablement indoctriné par d'autres EDIs moins bien conçus), à savoir de compiler ce qu'il voit dans l'EDI, pas ce qu'il a enregistré auparavant.

C'est au contraire une erreur grave de conception (en lisant le code, on voit surtout qu'il n'y a tout simplement aucun travail de conception). On pourrait fournir exactement les mêmes fonctionnalités avec du code beaucoup plus propre et avoir ainsi beaucoup plus de facilités pour faire évoluer le programme vers des fonctionnalités auxquelles tu n'as pas pensé lorsque tu as établi ce design limité.

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é...

vince (./124) :
3) Si tu comptes développer des softs plus complexes qu'un hello world alors il faudra songer à changer ton Oric(*) pour une machine mieux adaptée...

GT

robinHood -> curieusement, tu n'as pas une réputation de codeur très propre, est-ce que ça a un rapport avec le fait que tu sois d'accord aevc Kevin ?

Perso je dirais que cela depend beaucoup de la machien sur laquelle on dev (Je ne parle pas des Orics ).

J'ai essayé plusieurs fois de compiler un prog C de 100 lignes sur un Pentium dual core a 1.66 Ghz et ben un source de 30000 lignes assembleur est plus vite assemblé sur mon atari a 100 Mhz O_o !!

Donc je dirais que cela dépend du langage et de la machine (et péripheriques utilisés (Support de stockage) et après cela depend aussi de choix perso.



GT Plutot pour le gros fichier

T1 mais en plus les 5000 lignes de Kevin, c'est 5000 lignes avec quasiment aucun espace entre les blocs.
Du code sans espaces (lignes blanches), c'est tout sauf lisible... (L'indentation avait l'air pas mal en revanche)
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.
En fait, j'ai l'impression que c'est typiquement du code qui gagnerait à être plus objet.

Pour moi du code lisible, c'est surtout* du code qui en fait beaucoup avec peu de lignes effectives de code. Là j'aurais tendance à dire que c'est tout l'inverse. (Je considère en gros une ligne effective comme un point virgule en c#. En c++ y'a aussi la virgule alors je ne le prends pas en exemple )

* 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 ) et qu'on en retire l'explication de ce que fait la fonction, sinon ça compte pas.
(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 )

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.

(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.

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 dans ce cas (voire plus ).

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.

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 ) 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 )

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

Kevin Kofler (./133) :
(Et oui, je sais que les #define donnent du code plus grand, mais on n'est pas à l'octet près sur PC.)

Je note !

Kevin Kofler (./133) :
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.

Il y en a encore, mais je ne vais pas te fournir le patch, tu comprendras que j'ai d'autres choses à faire

./130 non conventionnel serais plutôt le terme, pas non propre, la propreté va de pair avec l'expérience

enfin, non conventionnel pour les règles de code actuelles, pas précédentes

chacun trouve sa lumière qq part, pour ma part c'est dans la manière de coder "à l'ancienne" :- )

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. 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. On devrait au moins ne pas avoir de code de l'un des ensembles entrelacé avec celui d'un autre. Il y a plusieurs raisons à ça, parmi elles : réutilisation du code, changement d'un élément simplement en respectant l'interface et aussi développement simplifié (on trouve plus rapidement une fonction déjà existante quand elle se trouve à un endroit logique, ça évite de l'écrire plusieurs fois (comme on en trouve dans le code dont Kevin Kofler a donné un lien (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)).

bien sur, dès que le projet est assez conséquent et touche à des chose bien définies, non semblable, tout doit être séparé

par exemple dans ce vieux code d'une de mes lib graphique, tout est découpé proprement, son, graphique, touches, ...

mais pour d'autre projets plus réduits (et non moins importants) par exemple celui ci tout est en un seul fichier, certes pas tellement commenté mais très propre tout de même, selon mes critères

bien sur l'objet apporte de la sécurité, la certitude que tout soit bien libéré comme il le faut etc ... mais comme dis plus haut l'expérience amène une certaine rigueur évitant des erreurs grossières,

il faut faire la part des choses entre taille du code, propreté d'écriture, et pertinence des choix, choix dictés encore une fois surtout par l'expérience, il n'y à pas de bonne méthode générale, il y en à par contre par problèmes à régler

RHJPP (./127) :
C'est au contraire une erreur grave de conception (en lisant le code, on voit surtout qu'il n'y a tout simplement aucun travail de conception). On pourrait fournir exactement les mêmes fonctionnalités avec du code beaucoup plus propre et avoir ainsi beaucoup plus de facilités pour faire évoluer le programme vers des fonctionnalités auxquelles tu n'as pas pensé lorsque tu as établi ce design limité.

l'expérience permet de se passer de conception préalable, du moins en apparence, pour des choses simple on peu coder direct mais le papier + crayon est bien généralement incontournable, la réflexion avant l'implémentation est reine

des fois je vois du code ou le type à du passer plus de temps à commenter (pour des choses débiles généralement) qu'à vraiment coder voir concevoir, encore une fois il faut faire la part des choses

ensuite, concernant ton argument sur l'évolution, c'est un mauvais argument selon moi, quant tu développe qq chose, il faut penser bien sur à son évolution, mais dans le bon sens, un code écrit pour qq chose ne doit pas l'être pour autre chose, sinon cela est du hack, bien sur les projets et leur finalités évolues, que se soit durant la conception ou bien plus certainement par la suite, mais ton code n'à généralement pas été écrit dans ce nouveau but, par chance (ou intelligence de codage) des fois ca marche, mais des fois non, le temps c'est de l'argent, et le temps de conception est limité, au bout d'un moment il faut faire des choix, leurs pertinence est en rapport de l'expérience du dev (encore une fois ^^⁾ mais on ne peu et doit pas cracher dans la soupe par la suite si cela ne règle pas des question non posé dès le début, quant je doit concevoir qq chose pour un client je demande toujours les évolutions futures aux quelles ils aspirent, des fois le temps de conception sera doublé, et il faut alors faire des choix, mais des fois non, c'est le même temps de dev.

robinHood (./136) :
un code écrit pour qq chose ne doit pas l'être pour autre chose, sinon cela est du hack

Non, ça s'appelle de la généralisation. Quand tu fais tes fonctions qui gèrent de façon révolutionnaire ta liste chaînée d'images, ce serait dommage de ne jamais pouvoir les réutiliser plus tard telles quelles sans modification, ça te ferait pourtant gagner plein de temps. Ce n'est qu'un exemple évident, mais on se rend compte que la plupart du code peut être découpé en librairies réutilisables.

robinHood (./136) :
le temps de conception est limité

Oui, c'est pourquoi il faut éviter d'écrire plusieurs fois les mêmes choses et après chercher les différentes occurrences pour les remplacer par des macros comme ça semble avoir été fait dans le code que Kevin Kofler nous a montré. Et ce n'est pas terminé car il y a encore des répétitions. Mais il y a aussi le temps de débogage qui est limité. Devoir corriger plusieurs fois les mêmes choses ne fait pas gagner de temps. De plus, comme ces lignes équivalentes ont été écrites plusieurs fois, elles peuvent être affectées de bogues différents. Et même si les bogues sont les mêmes, il faudra les trouver plusieurs fois et les corriger plusieurs fois (plus ou moins bien à chaque fois), car n'étant pas au même endroit, les codes équivalents s'exécutent à des moments différents. On peut trouver un bogue un jour dans un code équivalent à un autre que l'on avait déjà corrigé des mois auparavant.

Mais bien sûr, il ne faut pas être extrémiste. Un code de seulement quelques centaines de lignes peut bien rester dans son fichier s'il est seul. Et si le code est jetable après son utilisation car bien trop spécifique, alors soit, on fait ce qu'on veut. On peut aussi préférer faire autrement et mettre tout dans un même fichier pour simplifier certaines choses tout en gardant une séparation claire entre les parties et qu'elles soient réutilisables... par exemple, PrettyPrint est fait sur ce principe avec un fichier principal coupé en parties indépendantes et réutilisables. Ce fichier contient 8995 lignes de code.

robinHood (./136) :
je demande toujours les évolutions futures aux quelles ils aspirent

Ok, comme ça ils ont la responsabilité de ce qu'ils obtiennent, si tant est qu'ils aient bien compris les implications. Aussi, sans qu'ils sachent déjà quelles seront les évolutions, il faudrait leur demander s'il est possible que des évolutions soient nécessaires ou souhaitées un jour.

(et ils te répondront toujours "oui" s'ils sont un minimum malins, ou alors ils te répondront "non" mais te demanderont quand même une évolution un mois plus tard )

robinHood (./136) :
l'expérience permet de se passer de conception préalable, du moins en apparence, pour des choses simple on peu coder direct mais le papier + crayon est bien généralement incontournable, la réflexion avant l'implémentation est reine

S'il y a une chose que je n'utilise pas quand je code, c'est du papier!

RHJPP (./137) :
Oui, c'est pourquoi il faut éviter d'écrire plusieurs fois les mêmes choses et après chercher les différentes occurrences pour les remplacer par des macros comme ça semble avoir été fait dans le code que Kevin Kofler nous a montré.

Euh non, dès que je vois que j'ai besoin du même code 2 ou 3 fois, j'en fais une fonction ou une macro, et après j'utilise cette fonction ou macro. Je n'ai pas écrit ce même code 10 fois.

ils peuvent répondre ce qu'ils veulent, je suis aussi la pour conseiller et voir les implications/complications futures de tel ou tel choix, quoi qu'il arrive je serrais payé au temps de dev (enfin, au temps estimé !)

Kevin Kofler (./139) :
S'il y a une chose que je n'utilise pas quand je code, c'est du papier!

pas quant tu code, mais avant !
enfin des fois tout de même, un jolie schémas sur papier est pertinent et aide beaucoup lors du développement

triple post, désolé

RHJPP (./137) :
Non, ça s'appelle de la généralisation. Quand tu fais tes fonctions qui gèrent de façon révolutionnaire ta liste chaînée d'images, ce serait dommage de ne jamais pouvoir les réutiliser plus tard telles quelles sans modification, ça te ferait pourtant gagner plein de temps. Ce n'est qu'un exemple évident, mais on se rend compte que la plupart du code peut être découpé en librairies réutilisables.

dans ce cas la c'est un second projet ! ce découpage est a faire ou non aussi suivant ton expérience, et la pertinence de la "réutilisabilité" possible

bien souvent, avant, je développais pour une chose particulière, avant de le re développer de manière générique par la suite, l'utilisation de la première version du code m'ayant montré les limites et possibilités

ensuite, en faire une librairie complète ou une simple macro, est un choix à faire suivant la taille du code et sa criticité

enfin, nous tournons en rond, notre métier est basé sur ce système de couche, de réutilisation, de propreté etc ... c'est une évidence, qui vient avec le temps :- )

pour ma part, la divulgation sur github du principal de mon travail actuel, me force à ne pas penser qu'à moi, qu'à mes besoins, et m'oblige à faire encore plus propre et complet, et ca c'est bien !

Kevin Kofler (./133) :
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.

Je relève qu'il n'y a AUCUNE référence à des tests (fonctionnels ou même unitaires) avant de commiter...

Kevin Kofler (./139) :
S'il y a une chose que je n'utilise pas quand je code, c'est du papier!

Et donc, la conception/spécifications, tu n'en fais jamais ?

UML, vince, UML !

vince (./143) :
Je relève qu'il n'y a AUCUNE référence à des tests (fonctionnels ou même unitaires) avant de commiter...

Si ça compile, ça passe dans updates-testing et c'est aux utilisateurs de tester la mise à jour.

Kevin Kofler (./139) :
S'il y a une chose que je n'utilise pas quand je code, c'est du papier!

Et donc, la conception/spécifications, tu n'en fais jamais ?

Je conçois l'architecture globale dans ma tête, et les détails se cristallisent au fur et à mesure que je code.

Je précise que oui, j'ai des connaissances en UML, mais je n'utilise ça que si on m'y oblige.

Kevin Kofler (./146) :
Si ça compile, ça passe dans updates-testing et c'est aux utilisateurs de tester la mise à jour.

... (no comment)

Bah écoute, dans pratiquement tous les cas, mes correctifs marchent du premier coup, et si vraiment il y a un problème avec une mise à jour, on peut facilement en sortir une autre, c'est à ça que sert updates-testing. Seulement les mises à jour qui marchent passent dans les mises à jour stables.

KK, on peut avoir la liste des projets de sources publiques sur lesquelles tu bosses ?

Zerosquare (./147) :

Kevin Kofler (./146) :
Si ça compile, ça passe dans updates-testing et c'est aux utilisateurs de tester la mise à jour.

... (no comment)

Ca peut paraitre étrange, mais update-testing est fait spécialement pour être utilisé par des geeks qui vont tester les fixs et remonter les problèmes, c'est pas comme si son travail était directement releasé dans Debian stable par exemple.