Programmer proprement, comme ça :

char* p;
for(int a=0;a<9999999999;a++)// 999... beurk !
{
p=new char[300];
// reallocation en boucle et pas de delete ( ouille ! !)
plouf: // Label, BEURK ! !
if ( a==10) break; // beurk break !
}
while(1)
{
scanf("%d",p);
if ( *p==6) {printf("salut\n");printf("bonjour\n");*p=5;} // prog en ligne...
printf("mouarf %d"); // pas de %d utilisé.
if ( *p==3) goto plouf; // goto BEURK ! !
}
; // il a rien a foutre la lui, mais il fait pas planter !
// n´arrive jamais la

ça c´est de la prog pur dégueu !

C pour ça que dieu inventa les commentaires dans le code!
Si t´en met pas, NORMAL que tu t´y retrouve plus!
Et bien sûr que tout le mond efait son propre code!
Mais en conaissant certains algos célèbres, tu peux plus facilement résoudre certaisn problèmes précis.

Evanescence Posté le 17 juillet 2003 à 12:39:58
@Passage :
programmer correctement, c´est écrire un code élégant, facilement compréhensible, mais néanmoins optimisé. A savoir que s´il s´exécute en 10 secondes alors que tu pouvais le faire en 6/100 sec c´est qu´il est mal fichu.
C´est programmer de façon suffisemment générale pour implémenter d´un seul coup la résolution de plusieurs cas d´un coup. C´est utiliser des propriétés logiques ou mathématiques pour améliorer la lisibilité et diminuer la complexité de l´algo.
C´est éviter les complexités exponentielles. C´est ne pas hésiter à écrire un programme long pour faire quelque chose de simple si ça permet de gagner quelques centièmes de secondes.
C´est ne pas hésiter à décomposer totalement ton code pour en faire des dizaines de petites fonctions qui exécutent quelque chose de simple plutôt que de faire une grosse fonction de timbré qui fait quelque chose de compliqué.
C´est ne pas hésiter à recommencer de zéro l´écriture d´un programme si celui-ci est incohérent par certains points.

En un mot, c´est analyser un peu le pb avant, pendant et après l´écriture du code.

=> Urg....
Voeux pieux me semble t il . . .

D´une maniere un peu disgracieuse je pourrais te repondre : Analyse un peu le probleme " Qu´est ce que programmer correctement ? "

Resumons les 2 idées que tu donnes:
Optimisation du code.
Maintenance ( lisibilité, simplicité ) .

Personnelement si j´ai pas eprouvé le besoin de quoi que cela soit, je ne le fais pas.
Optimisation du code : Rien a faire tant que cela n´est pas critique. Se prendre la tete a optimiser alors que cela n´est pas critique dans le dev que tu fais c´est une perte de temps.

Maintenance : Rien a faire si aucune evolution n´est prevue ( projet one shoot ) .

Reecriture sans hesiter : Ceci me semble carement du plus grand style de timbré. 300000 lignes a me recoltiner pasque une partie de programme est incoherente ne me semble pas toujours justifié, j´prefere dans bon nombre de cas lever l´incoherence plutot que d´avoir a tout refaire.

=>"C´est éviter les complexités exponentielles. C´est ne pas hésiter à écrire un programme long pour faire quelque chose de simple si ça permet de gagner quelques centièmes de secondes."
En 2 phrases on peut voir blanc et noir. Je m´explique : Pas de truc trop complexes OK. Mais d´un autre coté allez y mettez en route la mega grosse artillerie et les 30000 ligne de code pour gagner 1 seconde... euh quelque chose m´echappe.

=>C´est ne pas hésiter à décomposer totalement ton code pour en faire des dizaines de petites fonctions qui exécutent quelque chose de simple plutôt que de faire une grosse fonction de timbré qui fait quelque chose de compliqué.
Pour la fonction de timbré, d´accord mais attention a ne pas tomber dans l´exces inverse : Le milliard de fonctions . . .

Bon pour resumer le fond de ma pensé vous oubliez tous le " but du jeu". On programme pas pour la beauté de l´art mais pour que :
1/ Ca marche
2/ Pour realiser en un minimum de temps les buts fixés. Il existe realité economique que bon nombre de programmeur oublient.

Et ca si t´arrive a le faire ben c´est deja pas mal.

Evanescence Posté le 15 juillet 2003 à 21:50:38
Non, parce que je sais programmer correctement ; )
=> T´as ton permis de programmer ?

Allez, je te réponds comme toi, c´est marrant :P

< <D´une maniere un peu disgracieuse je pourrais te repondre : Analyse un peu le probleme " Qu´est ce que programmer correctement ? " > >
Parce que tu fais un programme pour répondre à cette question toi ? ...

< <Resumons les 2 idées que tu donnes:
Optimisation du code.
Maintenance ( lisibilité, simplicité ) .

Personnelement si j´ai pas eprouvé le besoin de quoi que cela soit, je ne le fais pas.
Optimisation du code : Rien a faire tant que cela n´est pas critique. Se prendre la tete a optimiser alors que cela n´est pas critique dans le dev que tu fais c´est une perte de temps. > >
Ben, libre à toi de faire des fonctions qui ont une complexité doublement exponentielle, si ça t´amuse. moi j´appelle ça de la perte de temps. le client n´a pas vraiment besoin d´attendre 3 minutes, si la même chose peut être faite en 3 secondes.

< <Maintenance : Rien a faire si aucune evolution n´est prevue ( projet one shoot ) . > >
Oops... Et le bug là, meeerde... je l´avais pas remarqué... Et vu que j´ai programmé ça sans penser à la maintenance, j´ai pleins de brin partout si je veux débugguer... crotte aleurs...

< <Reecriture sans hesiter : Ceci me semble carement du plus grand style de timbré. 300000 lignes a me recoltiner pasque une partie de programme est incoherente ne me semble pas toujours justifié, j´prefere dans bon nombre de cas lever l´incoherence plutot que d´avoir a tout refaire. > >
Si l´incohérence peut-être levée, d´accord. Maintenant, je pense que je ne roulerais pas dans ta voiture sans essieu. ; p C´est ce qu´on appelle analyser le pb AVANT de programmer.

< <=>"C´est éviter les complexités exponentielles. C´est ne pas hésiter à écrire un programme long pour faire quelque chose de simple si ça permet de gagner quelques centièmes de secondes."
En 2 phrases on peut voir blanc et noir. Je m´explique : Pas de truc trop complexes OK. Mais d´un autre coté allez y mettez en route la mega grosse artillerie et les 30000 ligne de code pour gagner 1 seconde... euh quelque chose m´echappe. > >
Alors je t´explique :
[...]
for(int i=0;i<n;i++)
for(int j=0;j<pow(i,2);j++)
[...]
Ca c´est affreusement complexe.
En revance des dizaines de if imbriqués c´est pas complexe.
En clair : ce qui fait la complexité de l´algorithme ce n´est pas la longueur du code, mais le nombre de cycles d´exécution disons. ( le terme n´est pas exact, mais soyons simples).

< <=>C´est ne pas hésiter à décomposer totalement ton code pour en faire des dizaines de petites fonctions qui exécutent quelque chose de simple plutôt que de faire une grosse fonction de timbré qui fait quelque chose de compliqué.
Pour la fonction de timbré, d´accord mais attention a ne pas tomber dans l´exces inverse : Le milliard de fonctions . . . > >
Ai-je parlé de milliards de fonctions ? non. Tu sais je pourrais chercher la petite bête aussi, mais je ne le fais pas.

< <Bon pour resumer le fond de ma pensé vous oubliez tous le " but du jeu". On programme pas pour la beauté de l´art mais pour que :
1/ Ca marche > >
Oui et non. Si le code fonctionne c´est bien, s´il fonctionne et qu´il est élégant c´est mieux.

< <2/ Pour realiser en un minimum de temps les buts fixés. Il existe realité economique que bon nombre de programmeur oublient. > >
Tiens... Maintenant tu optimises...?? Je croyais que tu t´en foutais ?

< <Et ca si t´arrive a le faire ben c´est deja pas mal.

Evanescence Posté le 15 juillet 2003 à 21:50:38
Non, parce que je sais programmer correctement ; )
=> T´as ton permis de programmer ? > >
J´ai surtout le diplôme qui va avec. En revanche, toi, soit tu étais un mauvais élève, soit t´es autodidacte depuis 3 ans. :P

1/ Il me faut pas faire un programme pour repondre a un probleme. Il faut bien analyser toutes les données de ton probleme.

2/Il faut mettre en balance les condition suivantes :
Prenddre 3 minutes pour faire un code qui prends 10 secondes a s´executer.
Prendre 3 jour pour faire un code qui prends 1 seconde a s´executer.
Si la vitesse de deroulement n´est pas primordiale je choisi les 3 minutes.

3/ Maintenance n´est pas equivalent a phse de debuggage. Dans la Maintenance tu place l´evolution future du produit. Un projet OneShoot c´est juste un programme que t´ecris 1 fois que tu balance dans la nature et qui meurt. Rien a faire de reprendre le code dans 6 mois. le truc est OneShoot. Concoit,Ecrit, Test, livre et FINI. Le tout, dans la foulée.

4/ Reecriture sans hesiter. Bon alors tu peu passer 6 mois sur ta conception, si le projet evolue ( et c´est toujours le cas ) , t´auras TOUJOURS une zone pourrie dans ton code. Toujours une zone ou te dis cela aurait pu etre mieux, cela devrait etre changé si j´en ai le temps. Et meme sans parler implementation, juste conception, une conception parfaite n´existe pas. Il faut toujours reprendre une partie lors de l´implementation pasque le gars est humain et il a PAS penser a tout. En fait une bonne conception c´est plutot le truc souple, qui va s´adapter au fil du temps. On a pas explicité quelque chose mais la porte est ouverte pour le faire.

Peut etre que ma voiture a des coussins d´air et pas besoin de roues.

5/ les 10 if imbrique. Tu les fait si tu veux, mais en terme de lisibilité ben tu vois j´ai comme un gros doute. Complexité de l´algo mathematique ou de comprehension.

6/ Le milliard de fonction. C´est bien sur une petite exageration, mais souvent dans des projets il faut s´avoir s´arreter lors du decoupage et il m´est deja arrivé de tomber sur des code ou pour trouver ou un compteur est incrementé faut se taper 5 heures de lecture. Ce cas arrive plus souvent que l´on ne pense, pasque le gentil developpeur part de bonnes intentions et finalement crache une usine a gaz.

7/ Faire que cela marche c´est deja l´objectif 1. L´elegant n´est qu´un objectif annexe dans certains cas, mais qui coute du temps de dev. Je dirais qu´il faut faire elegant ( enfin chacun a sa definition d´elegant ) sans pourtant prendre trop de temps ( Pas CPU mais dev).

8/ La realité economique : C´est t´a 3 mois pour torcher un programme. Tu dois le faire en 3 mois, cela va surement t´en couter un peu plus ( les delai sont toujours un peu short ) . Ce qu´il faut mettre en balance c´est le cout de dev et le resultat. Pas la peine de faire 6 mois de spec pour un truc qui sera vendu pour 3 mois de travail.

9/ Le permis de programmer est une bonne blague que je ressort a chaque fois que je rentre dans une code pourris a souhait. Cela veut dire betement que dans la vie tu tombera sur des codes que tu estimera crade, que il n´y a rien pour l´en empecher.

10/ Ben perso, je devais pas etre un trop mauvais eleve ( la partie technique etait plutot mon fort, au contrario de la partie generale). Mais faut pas rever. L´ecole c´est des voeux pieux, rien de plus. C´est plus la theorie de la pratique. Apres 10 ans de dev ( eh oui ) tu mettra de l´eau dans ton vin. A la question " Programmer correctement" je pense que tu repondra : Cela n´existe pas. Il y a des manieres de programmer que TU preferes, d´autres que tu deteste mais le vrai truc c´est de faire avec et d´arriver a te " depatouiller" quelque soit le ´cochon´ ( je le dit avec affection) qu´a programmé avant toi. Tu seras toujours le ´cochon´ d´un autre. . .

PS: Je ne programme pas correctement.

< <1/ Il me faut pas faire un programme pour repondre a un probleme. Il faut bien analyser toutes les données de ton probleme. > >
Jamais dit le contraire. J´arrête pas de le dire même : analyser avant de programmer.

< <2/Il faut mettre en balance les condition suivantes :
Prenddre 3 minutes pour faire un code qui prends 10 secondes a s´executer.
Prendre 3 jour pour faire un code qui prends 1 seconde a s´executer.
Si la vitesse de deroulement n´est pas primordiale je choisi les 3 minutes. > >
Bon, ben je pense que tes clients iront voir ailleurs, parce que là où tu as bossé 3 jours, eux ils vont s´en servir en permanence de ton prog, donc au bout d´un moment ça fait beaucoup de 3 minutes. Et en plus, c´est bien exagéré tout ça, parce qu´on met pas 3 jours pour optimiser un code.

< <3/ Maintenance n´est pas equivalent a phse de debuggage. Dans la Maintenance tu place l´evolution future du produit. Un projet OneShoot c´est juste un programme que t´ecris 1 fois que tu balance dans la nature et qui meurt. Rien a faire de reprendre le code dans 6 mois. le truc est OneShoot. Concoit,Ecrit, Test, livre et FINI. Le tout, dans la foulée. > >
Et bien j´espère que tu fait la preuve de tes programmes, sinon ça doit pas être joyeux à la sortie.

< <4/ Reecriture sans hesiter. Bon alors tu peu passer 6 mois sur ta conception, si le projet evolue ( et c´est toujours le cas ) , t´auras TOUJOURS une zone pourrie dans ton code. Toujours une zone ou te dis cela aurait pu etre mieux, cela devrait etre changé si j´en ai le temps. Et meme sans parler implementation, juste conception, une conception parfaite n´existe pas. Il faut toujours reprendre une partie lors de l´implementation pasque le gars est humain et il a PAS penser a tout. En fait une bonne conception c´est plutot le truc souple, qui va s´adapter au fil du temps. On a pas explicité quelque chose mais la porte est ouverte pour le faire. > >
Une conception peut être parfaite au contraire. Etant donné que c´est un humain qui conçoit un logiciel, et par conséquent sa logique. Il suffit que l´ensemble soit cohérent avec la logique que cet humain s´est fixé. A partir de là on a pas vraiment besoin de chercher à rendre le programme souple car il l´est naturellement.

< <Peut etre que ma voiture a des coussins d´air et pas besoin de roues. > >
Peut-être que je fais un élevage de perce-oreilles...

< <5/ les 10 if imbrique. Tu les fait si tu veux, mais en terme de lisibilité ben tu vois j´ai comme un gros doute. Complexité de l´algo mathematique ou de comprehension. > >
Complexité de l´algorithme tout court. Tu sais le fameux problème P=NP, tu connais ? C´est de cela que je parle. Maintenant, concernant les if imbriqués, je suis d´accord que c´est un exemple un peu tiré par les cheveux, pourtant ce genre de programme a un nom : système expert. Mais si tu veux, on se fait ça avec une succession de sommes pondérées passées sous une fonction de seuil, comme une sigmoide ou autre, le tout dynamisé par un petit algo de rétropropagation du gradient, et là tu obtiens un réseau neuro-mimétique qui est beaucoup plus évolutif que le système expert, mais moins radical disons.

< <6/ Le milliard de fonction. C´est bien sur une petite exageration, mais souvent dans des projets il faut s´avoir s´arreter lors du decoupage et il m´est deja arrivé de tomber sur des code ou pour trouver ou un compteur est incrementé faut se taper 5 heures de lecture. Ce cas arrive plus souvent que l´on ne pense, pasque le gentil developpeur part de bonnes intentions et finalement crache une usine a gaz. > >
Et bien, c´est en effet possible, mais maintenant, il faut savoir ( pour reprendre ce qu´on disait il y a quelques jours) que trafiquer un compteur ou bien utiliser une variable juste pour faire un truc qu´on peut faire sans cette variable, c´est peut-être aussi une mauvaise idée.

< <7/ Faire que cela marche c´est deja l´objectif 1. L´elegant n´est qu´un objectif annexe dans certains cas, mais qui coute du temps de dev. Je dirais qu´il faut faire elegant ( enfin chacun a sa definition d´elegant ) sans pourtant prendre trop de temps ( Pas CPU mais dev). > >
Tout dépend aussi de l´importance avec laquelle tu considères ton programme. S´il n´est qu´un petit " jeu" débile, pas la peine d´être réellement élégant, s´il est un outil qui évoluera dans le temps, auquel tu tiens et que tu veux le programmer du mieux que tu peux, tu vas être élégant. Si c´est un tutorial, tu risque même d´être plus qu´élégant.

< <8/ La realité economique : C´est t´a 3 mois pour torcher un programme. Tu dois le faire en 3 mois, cela va surement t´en couter un peu plus ( les delai sont toujours un peu short ) . Ce qu´il faut mettre en balance c´est le cout de dev et le resultat. Pas la peine de faire 6 mois de spec pour un truc qui sera vendu pour 3 mois de travail. > >
Evidence mon cher, mais je ne pense pas que la majorité des personnes de ce forum s´intéressent vraiment à COCOMO.

< <9/ Le permis de programmer est une bonne blague que je ressort a chaque fois que je rentre dans une code pourris a souhait. Cela veut dire betement que dans la vie tu tombera sur des codes que tu estimera crade, que il n´y a rien pour l´en empecher. > >
J´en ai déjà fait l´expérience. C´est marrant d´ailleurs parce que c´est très souvent que je trouve le code crade. Etant donné que je m´efforce toujours de programmer n´importe comment, j´ai... disons un haut sens critique concernant tout ceci.

< <10/ Ben perso, je devais pas etre un trop mauvais eleve ( la partie technique etait plutot mon fort, au contrario de la partie generale). Mais faut pas rever. L´ecole c´est des voeux pieux, rien de plus. C´est plus la theorie de la pratique. Apres 10 ans de dev ( eh oui ) tu mettra de l´eau dans ton vin. A la question " Programmer correctement" je pense que tu repondra : Cela n´existe pas. Il y a des manieres de programmer que TU preferes, d´autres que tu deteste mais le vrai truc c´est de faire avec et d´arriver a te " depatouiller" quelque soit le ´cochon´ ( je le dit avec affection) qu´a programmé avant toi. Tu seras toujours le ´cochon´ d´un autre. . . > >
Je suis assez d´accord, mais je pense qu´après 17 ans de dev ( et oui...) tu auras aussi une autre opinion, car tu auras non seulement sû te dire " y´a une façon de programmer que j´aime bien", mais en plus tu pourra dire " je sais que c´est une bonne façon de programmer".

< <PS: Je ne programme pas correctement.>>
Moi si.

1/ Analyser le probleme et la question posée : " Qu´est ce que bien programmer".

2/ Relis mieux ce que j´ai ecrit.

{
2/Il faut mettre en balance les condition suivantes :
Prenddre 3 minutes pour faire un code qui prends 10 secondes a s´executer.
Prendre 3 jour pour faire un code qui prends 1 seconde a s´executer.
Si la vitesse de deroulement n´est pas primordiale je choisi les 3 minutes.
}
A/ Il ne s´agit pas de prendre 3 minutes pour optimiser ton code mais pour l´ecrire.
B/ La condition est toujours " La vitesse de deroulement" n´est pas primordiale" est presente.
Je sais pas comment te dire : " J´ai delimité les condition du probleme au mieux, mais il semble que dans la reponse tu elimine une des condition".

3/ Relis ta reponse faite en 7/
C´est un truc qui n´evolue pas, que tu fourni une fois sans espoir de maintenance ou d´avenant. Le truc tu le dev, le livre et t´en entends plus parler.

4/ Ben alors t´es un genie !

5/ Qui aime utiliser des grand mot pour en fiche plein la vue.

6/ C´est peut etre aussi une evolution a apporter.

7/ Oui l´elegant peut etre un de tes objectif a prendre en compte. Il peut, il n´est pas forcement. Tandis que faire que cela marche l´est toujours ( a moins que . ..)

8/ Methode Cocomo s´en tanponne, d´ailleur y a t il un pequin qui l´utilise reelement ? Le truc pour moi c´est juste de comprendre que le temps passé devant un ordinateur ( ou une feuille ) a un coup. Ce que tu produira rapportera. Faut juste equilibrer. Et donc pour certains projet, faire du " crade" pour equilibrer.

9/ Finalement que le code soit crade lors d´une reprise, je finis par m´en moquer. La ou je peste c´est qu´il ne soit pas " uniforme".

10/ Pourquoi est ce donc la bonne facon de programmer ?

PS :
17 ans de dev est t´es toujours developpeur ? Tu connais le principe de Peters ? Bon c´est juste une petite pique sans plus. Au passage change donc ton age dans ton profil.

PS : T´as un ego gros comme un 370.

Mon âge est exact.

En ce qui concerne l´histoire de l´optimisation oubliée si la durée d´exécution n´est pas primordiale, et histoire de faire aussi exagéré que toi, imagines :
2 programmes, l´un qui s´exécute en 3 semaines, et l´autres en 3 secondes, le 1er coûte 3 francs et le second 30.000 francs. Je crois qu´on choisira le second quand même. ; )

4/ si je suis un génie, non. Tout le monde pourrait faire la même chose, s´il s´en donnait la peine. Même les petits gamins qui rodent ici en clamant " je veux apprendre à programmer". J´ai bien commencé à 5 ans moi.

5/ j´utilise des grands mots comme tu dis pour te démontrer qu´une succession de if imbriqués c´est moins complexe qu´un algo de complexité 2^n. C´est plutôt simple à comprendre pourtant. Je ne parle pas de la lisibilité, je parle de complexité des algorithmes... Mais bon, apparemment, tu refuses de comprendre ( ou bien tu fais semblant).
Quant à en fiche plein la vue, on voit que tu me connais bien mal. ( normal)

10/ C´est une bonne façon, parce que je suis une même logique tout au long d´un programme, et que je suis capable d´expliquer cette logique. c´est uniforme si tu veux...

7,8,9/ relis ce que tu as écris en 1 : 1/ Analyser le probleme et la question posée : " Qu´est ce que bien programmer".
Je crois que tu fais un hors sujet. Tu peux repasser ton bac philo ; )

ps: . .. il me semblait pourtant que les chefs cuisiniers étaient aussi cuisiniers...

ps: j´ai un égo gros comme un 370, non. mon égo n´a rien à voir dans cette discussion.
Tu me demande ce que c´est que BIEN programmer, je te dis ce que c´est. Et toi tu sembles me répondre : " non, c´est pas faire un code élégant, propre, et efficace ( =optimisé) mais c´est programmer à la va comme je te pousse en ajoutant 300 variables de contrôles inutiles et si possible en faisant un code bien crado même s´il prend 3 jours à s´exécuter."

Tu as ton permis de programmer ?

1/ Disparu -note au " passage" qu´il nous faut donc analyser ce que " bien programmer" veut dire. On en est au requirement. - n´en parlons donc plus - euuuuh, enfin si parlons en c´est le but du topic.

2/ Le temps d´excution n´etant primordial, desolé, tu prendra pas la rools a 300 000 francs mais la deux chevaux a 3 francs. Tu evolue dans un monde avec un realité ECONOMIQUE. Oublie la lors de tes developpement, et c´est le carton assuré.

3/ - Disparu, n´en parlons plus -

4/ Ben alors faudrait m´expliquer a moi. Voila 10 ans que je traine dans diverse boites et je suis desolé : J´ai pas encore vu un mec capable de TOUT prevoir dans sa conception. Faudrait que tu me donne le nom de ta boite histoire que j´aille y faire une ( re-)mise a niveau !

5/ Je comprends mieux ton propos. Alors dans l´absolue oui, tu a raison.

// a des fin de logique j´vais continuer dans l´ordre. Ce que tu applique en programmation, je l´applique aussi dans les discussions, ordre et rigueur. ; )

6/ - A disparu n´en parlons plus -

7, 8, 9/ La bac philo... La vache j´etais pas tres bon. Mea culpa " Qu´est ce que programmer correctement". Tu va voir que finalement j´vais m´en tirer pas trop mal. Mais ces point rentre dans le cadre de " Programmer correctement".

10/ J´aime bien. Meme si cette logique au fil de son deroulement s´avere erronée ?

Reponse au PS:
Si tu parle du programmeur et du chef de projet et autres, tu dois pas etre decu du voyage. Regarde un peu tes chef de projets. Savent ils programmer ? Mouarf, mouarf, mouarf. On est tous plié de rire.

Qu´est ce que bien programmer peut etre:
" Ne pas faire un code propre, elegant et efficace". Le probleme c´est de savoir dans quel cas tu peux te permettre ( ou tu dois expressement commettre ) de telles " horreurs". ( Tout depends les buts et les moyens dont tu disposes... )

Mon permis, c´est Bac+5 passé comme je te disais il y a 10 ans, avant cela un petit BTS informatique indus, 1 année de spe . C´est pas grand chose, c´est qu´un titre honorifique. Les etudes ne sont que la theorie pas la pratique.
Ca fait 9 ans que je me le suis retiré pour exces de confiance et chaque jour je le repasse. ( histoire de pas avoir trop les chevilles qui enflent ) .

--- Mais qu´est ce que t´en a faire que ton programme s´execute en 3 jours, si le client ne veut le lancer qu´une fois par an et qu´en plus il a le temps d´attendre le resultat pendant 2 mois ? Qu´est ce que peut t´apporter d´avoir optimiser ( depensé de l´argent finalement pour RIEN ) un code dont la criticité n´est PAS le temps d´execution ? Tu crois qu´il va te le payer 300 000 francs ?

Bilan: L´idée que je veux te faire passer c´est de lever la tete du guidon !
Y a des imperatif ECONOMIQUE ( que bien nombre de programmeur oublient -bis-) a suivre qui remettrons ( et plus d´une fois ) tes criteres de " programmer correctement". Soit tu continue a fond dans le programmer correctement" et tu prendra une claque sur les objectifs soit tu mets un peu d´eau dans ton vin et tu accomplis ( haut la main ) les objectifs du projet.

Cher JeanYvesYves :
Me semble deja en avoir discuté avec toi.
Tu donnes un example qui certe n´est pas issue d´une main experimenté.
Mais il me semble que dans certains cas ( pas celui la ) break et goto peuvent etre elegant.

( Nan, mais je suis fou d´encore ecrire cela , j´ai deja pris une baffe une fois ) . Etant tete de mule ( eh voui ) , je persiste !

Par contre, une remarque que j´attendais de la par du correcteur du source ( toi donc ) : " Mommer clairement vos variable ( et etiquette ) ".
La vache : a, p, plouf !
J´ai vu un programme ou les variable etait
i, ii, iii, j,jj, tabi[], tabii[] => Arf, dantesque.

Dans les constantes t´as oublié le 300, le 10 le 6, le 5, et le numero complementaire le 3

Tu l´a peché ou cet exemple la ?

Avec 2 posts comme ca j´vais pas me faire que des amis ici . .. brrrrr...

C´est clair que tu vas te faire des amis...
Tu poses la question " qu´est ce que programmer correctement", je te réponds clairement, et tu me dis non, c´est pas ça programmer correctement.
Et ensuite, tu expliques ton cas en parlant non plus de programmation mais de budget.

En clair, t´es très ennuyeux comme mec. Sur ce, tu continueras ce fabuleux débat inutile tout seul.

Mais quand même être à Bac +5 et toujours en rester au niveau de " moi j´aime chercher des poux en étant à côté de la plaque"....

lol

pondu sur le tas cet exemple ! CT poru rigoler !
Wé C vrai aussi qu´appeler des variables i, ii, et iii c´est monstrueux, lol !

Quant a break et goto, hum, moi perso je prefere éviter ! ( par contre dans un switch, break se fait bien)
le plus grave est l´alloc sans delete

pkoi tu preferes eviter break ?
moi je dis que break et continue sont 2 fonctions qui ont leur place ( et peut etre meme privilégiée) dans les algorithme, et ca permet d´éviter les goto.