Discussion :

[pcdwarf]

le code est fait pour répondre a un besoin, certes, mais le code reflète aussi la pensée de son créateur.
Quel que soit le domaine, il y a toujours eu des amoureux des belles mécaniques bien structurées et des bricolos qui ne s'intéressent qu'au fait que ça marche le plus tôt possible.

Il en faut pour tout les gouts et toutes les situations. Je ne vois pas pourquoi il y aurait des règles.

[baos!]

J'aime bien le code "hackaton"

J'ai fait cet exercice il y a qq mois (en utilisant Java et les BigInteger, donc, pas limité à fibonnacci(164)), en utilisant aucune des méthodes décrites.

Premier algo, c'est celui qu'on fait naturellement, "à la main". On connait fibo(0) et fibo(1), puis, via une simple boucle for, on calcule fibo(2), fibo(3) ... jusqu'à fibo(n) recherché. Ici, on calcule chaque valeur entre 1 et N une seule fois; et comme, à chaque calcule, seules les 2 dernières valeurs sont utiles; je n'utilise qu'un tableau de 3 éléments. A chaque étape, le dernier élément calculé devient le n-1, l'ancien n-1 devient n-2 et le résultat du calcul passe dans l'ancien n-2 (ça fait une fonction de calcul d'indice relatif entre le fibo et la tableau un peu complexe, mais c'est très économique.

Le second algo part sur la remarque que :
fibo(n) = fibo(n-1)*fibo(1) + fibo(n-2)*fibo(0) = fibo(n-2)*fibo(1) + fibo(n-3)*fibo(1) + fibo(n-2)*fibo(0) = fibo(n-2)*fibo(2) + fibo(n-3)*fibo(1)
On voit facilement, par récursivité, que :

fibo(2*n) = fibo(n)² + fibo(n-1)²
fibo(2*n + 1) = fibo(n) * (fibo(n+1) + fibo(n-1))

Du coup, en codant simplement ce système récursif avec un mécanisme de "Mémoisation" (une simple Map), on ne calcule qu'environ log2(n) éléments.

Pour info,
fibo(1440) = 39148665084314713611487939879536073000884287539729085016573824046902113615010632646259788823155802905194474577
2829337376406678858402406939880042845977014235081189477072987319401028174973366140751380465125202666913528379206343180700
4225506814702922160621247026028619389629299722842113162285992338142080
calculé en presque 6 millisecondes pour le premier algo et 2 millisecondes pour le second.

[ericlm128]

Je trouve le code du 'Développeur 3' le plus simple et lisible en commentant uniquement le fonctionnement.

Après ça dépend du besoin :
- peut être faut il gérer une exception pour 'n < 0'
- Peut être faut il optimiser le code ça dépend des appels possibles

[ChristianRoberge]

Il y a un type de programmeur qui a été oublier. Je l'appelle l'illusionniste. À première vue son code semble bien documenté et semble suivre les "règles" de l'art. Mais quand on prend le temps de bien analyser ce qui est fait réellement, on s'aperçoit que la documentation est insipide et ne fait que décrire des banalité, que son code n'utilise pas les algorithmes approprié pour résoudre adéquatement les problèmes et le plus grave, toutes les endroits critiques qui exigeaient un commentaire sont carrément absent pour que personne autre l'auteur puisse comprendre le problème.
Cela semble irréel, mais cette personne que j'ai connu, a travaillé 3 ans dans la même compagnie que moi et il a eu les félicitations de la part de la direction pour son respect des directives et la quantité de code produit durant pratiquement toutes ses années. Fort de cette notoriété, il s'est trouvé un très bon poste dans une autre boîte! De notre coté, son code a été retiré ou récrit après son départ parce qu'il avait trop de lacune. Du grand art!

[kilroyFR]

Pour moi le meilleur code est celui qui :
1/ fais le boulot
2/ est maintenable par n'importe qui (meme celui qui ne connait pas les trucs et astuces d'un langage)

Trop souvent les nouveaux developpeurs se perdent dans les syntaxes d'un langage ou essaient de placer les dernieres syntaxes (qui permettent d'ecrire en 2 lignes de codes ce qu'on faisait avant en 3). Resultat : tout le monde ne pouvant pas toujours etre au fait des dernieres evolutions, la maintenance en est plus penible (peut meme en degouter certains). J'ai lu du code ecrit en C/C++ ou tout etait condensé pour optmiser le nb d'operations a un point ou c'etait indechiffrable. Idem pour du code C# Linq/lambda expressions (alors que de betes instructions conditionnelles auraient ete compréhensibles de tous).

[el_slapper]

Il y a un type de programmeur qui a été oublier. Je l'appelle l'illusionniste. À première vue son code semble bien documenté et semble suivre les "règles" de l'art. Mais quand on prend le temps de bien analyser ce qui est fait réellement, on s'aperçoit que la documentation est insipide et ne fait que décrire des banalité, que son code n'utilise pas les algorithmes approprié pour résoudre adéquatement les problèmes et le plus grave, toutes les endroits critiques qui exigeaient un commentaire sont carrément absent pour que personne autre l'auteur puisse comprendre le problème.
Cela semble irréel, mais cette personne que j'ai connu, a travaillé 3 ans dans la même compagnie que moi et il a eu les félicitations de la part de la direction pour son respect des directives et la quantité de code produit durant pratiquement toutes ses années. Fort de cette notoriété, il s'est trouvé un très bon poste dans une autre boîte! De notre coté, son code a été retiré ou récrit après son départ parce qu'il avait trop de lacune. Du grand art!

Je n'ai vu ça qu'une seule et unique fois. Mais c'était impressionnant. L'ancienne m'avait prévenu(et avait prévenu la direction aussi) : le code semblait "aléatoire". Je l'ouvre, surprise, c'est mignon, bien indenté, avec des noms de variables nickel, une découpe en morceaux logiques et semblant bien découpés... Sauf qu'une fois plongé dans l'algorithmique proprement dite, ça n'avait plus aucun sens. Les commentaires permettaient de savoir qu'on avait une entrée et une sortie, mais pas ce qu'on en faisait. Les données subissaient des opérations arbitraires, sans queue ni tête. Toujours joliment, avec des noms de variable impeccables - mais qui très vite ne correspondaient plus à la réalité.

[e-ric]

@kilroyFR
A nuancer, j'acquiesce en partie cet avis, le n'importe qui prête à tout et n'importe quoi. Préciser développeur professionnel serait à mon sens plus justifié. Je ne ferai pas le boulot d'un médecin, alors pourquoi un quidam foutrait ses pattes dans le code. Quant à la connaissance des trucs et astuces, pareil, on est quand même censés en connaître une partie, ce n'est pas toujours contournable sauf à se contenter d'un code scolaire. Mais il vrai que l'abus en toute chose est mauvais, le code doit être cohérent avec le problème à résoudre.

En outre, la formation continue (là je rêve) devrait théoriquement pallier ces lacunes, mais encore faudrait-il que les entreprises jouent le jeu.

@el slapper
Visiblement, la forme prévaut sur le fond, c'est une tendance actuelle.
Tant qu'il y a des pompiers pour que cela tourne, cela ne changera pas. On a déjà tenté de m'imposer des normes de codage inutiles et encombrantes, je me suis amusé à pousser un exemple au paroxysme, c'est toujours amusant, bête mais amusant. C'est parfois la seule façon de se faire entendre en tant que développeur, c'est bien connu, on est trop cons, nous les développeurs.

Cdlt

[el_slapper]

(.../...)@el slapper
Visiblement, la forme prévaut sur le fond, c'est une tendance actuelle.
Tant qu'il y a des pompiers pour que cela tourne, cela ne changera pas. On a déjà tenté de m'imposer des normes de codage inutiles et encombrantes, je me suis amusé à pousser un exemple au paroxysme, c'est toujours amusant, bête mais amusant. C'est parfois la seule façon de se faire entendre en tant que développeur, c'est bien connu, on est trop cons, nous les développeurs.(.../...)

La forme, ça compte aussi. Je ne sais pas quelle est ton expérience, mais j'ai maintenu - et même refondu, du code qui avait 36 ans d'âge(72-08). Les normes de codage encombrantes, certaines sont stupides, certes. Mais quand tu as 1500 programmes à analyser(pour mettre en place des tests automatique de batches), et que TOUS ont la même superstructure :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
PERFORM 10000-DEBUT
PERFORM 20000-TRAITEMENT UNTIL CONDITION-DE-FIN
PERFORM 30000-FIN
STOP RUN.

Et avec en plus des normes d'appellations des sous-paragraphes, qui fait que les traitements d'erreur sont toujours en 90000, les lectures de base en 70000, etc.... Ben je peux te dire que le mec qui, 20 ans auparavant, a fait chier ses programmeurs pour avoir ça partout, il vient de te sauver la vie en divisant par deux ton temps d'analyse. Et pas qu'à toi.

Après, ça ne veut pas dire que le programme marche bien. C'est évidemment très insuffisant pour assurer le succès d'un projet. Mais ça fait gagner en productivité de manière impressionnante. Mon expérience à moi, c'est qu'un codage moins futé, mais plus standard, est à favoriser. Même si on se trimballe 20 lignes de plus. Parce que le mainteneur sera chez lui dans ses pantoufles au premier coup d'œil. Et pourra ignorer la forme - qu'il connait par cœur - pour se concentrer sur le fond.

[e-ric]

Salut,

Il est vrai que des normes peuvent aider, cela devrait même être leur fondement, mais il faut qu'elles soient pertinentes et qu'elles autorisent parfois à sortir du cadre.

J'ai une expérience mitigée des normes, les personnes qui les édictent n'ont pas toujours la capacité à le faire et recopient parfois bêtement ce qui se passe ailleurs, j'ai déjà vu des cas. Je donne un exemple que je trouve caricatural, dans Delphi, quasiment tous les fichiers de code sont des unités, eh bien, il y a un malin qui a eu l'idée géniale de les préfixer par la lettre U (U pour unité), le contenu informatifs d'une telle convention laisse à désirer car cela n'est pas différenciant. Et quantité d'équipes ont repris à l'unisson une telle convention, pour dire qu'elles adoptaient une norme de codage. C'est une notation mettant en évidence les fichiers qui ne sont pas des unités qu'il faudrait plutôt mettre en place. Mais à côté de cela, cela ne gêne personne de ne pas protéger les blocs de code qui le méritent ou de comparer deux nombres en virgule flottante directement.

Cela explique ma méfiance pour les normes, notamment quand elles insistent trop sur la syntaxe.

Par exemple, la notation hongroise, belle calamité, M$ en sait quelque chose bien qu'il en soit le promoteur, on nomme une variable avec un préfixe dénotant un type précis. Puis quelques mois plus tard on change le type de la variable sans bien sûr la renommer, on introduit une irrégularité qui fera le "bonheur" du développeur futur faisant trop confiance à la norme, surtout si c'est un prestataires débarqué sur le projet car il y a une urgence. Bonjour le gain de temps.

El Slapper, tu as en grande partie raison (tu parles par expérience) mais à condition que les développeurs jouent le jeu avec un minimum de sérieux et d'intelligence.

Cdlt

[Invité]

il y a quelques années, quand j'étais développeur, j'avais rédigé les règles et nomenclatures de codage avec un collègue sur un gros projet.
Quelle surprise de découvrir quelques semaines plus tard après la livraison de ce document que la seule personne de l'équipe à s'asseoir allègrement sur ces règles étaient justement mon collègue qui avait co-rédigées celles-ci ! (du niveau : variable1, variable2...)

[DonQuiche]

J'ai une expérience mitigée des normes, les personnes qui les édictent n'ont pas toujours la capacité à le faire et recopient parfois bêtement ce qui se passe ailleurs, j'ai déjà vu des cas. Je donne un exemple que je trouve caricatural, dans Delphi, quasiment tous les fichiers de code sont des unités, eh bien, il y a un malin qui a eu l'idée géniale de les préfixer par la lettre U (U pour unité), le contenu informatifs d'une telle convention laisse à désirer car cela n'est pas différenciant. Et quantité d'équipes ont repris à l'unisson une telle convention, pour dire qu'elles adoptaient une norme de codage. C'est une notation mettant en évidence les fichiers qui ne sont pas des unités qu'il faudrait plutôt mettre en place. Mais à côté de cela, cela ne gêne personne de ne pas protéger les blocs de code qui le méritent ou de comparer deux nombres en virgule flottante directement.

Cela explique ma méfiance pour les normes, notamment quand elles insistent trop sur la syntaxe.

Outre les mauvaises normes, j'ai surtout une aversion pour la surnomarliasation. Si la convention occupe plus de quelques lignes, ça sent le poisson.

[Artemus24]

Salut à tous.

L'intérêt d'une méthodologie, c'est de faire en sorte que tous les membres d'une équipe développe de la même façon.
Elle ne doit pas être contraignante, mais doit faciliter sa mise en place.
Quand tu te poses trop de questions sur son application, c'est qu'il y a un problème.
Combien de fois aussi, on continue d'appliquer une règle qui ne sert plus à rien.

Ayant fait beaucoup de cobol, les normes du développement ont un sens.
Mais passer à un autre langage, je ne voie plus trop l'intérêt de continuer à les appliquer. Par exemple, en cobol, on préfixe les champs :
--> cste- : pour les constantes.
--> date- : pour les dates.
--> tete- : pour les en-têtes des états.
--> line- : pour la ligne courante.
...
C'est pratique pour le cobol, mais sans intérêt ailleurs. Pourquoi ? Car il n'existe pas de type en Cobol. On a les computational et c'est tout.

@+