Discussion :

[LadyWasky]

lol, je pourrais pas dire, je suis pas trop l'actualité des sondes spatiales.

Sinon, il est évident que la moindre fonction a tout de même son importance, mais ce que je voulais surtout dire c'est qu'il est beaucoup plus aisé de re-programmer une unique fonction que de re-programmer toute une application pour la faire "coller" à un nouveau design totalement différent.

C'est clair !

[barjy]

Salut à tous...

Bien que nouveau (sur le forum, pas dans la programmation), je ne peux qu'être étonné :

- des chtis étudiant qui avalent tout ce qu'on leur dit et le répète sur ce forum,
- des moins débutants à qui il faut absolument passer par l'UML avant d'attaquer un projet, ne serait-ce que de quelques "dizaines de milliers de lignes",
- de la façon dont on ne répond pas à l'auteur de ce message,
- ...

Donc, oui, je penses que "nous" (développeur "spontanés") sommes une exception... par contre l'amalgame en "développeur spontané" et "gens qui codent comme des procs" est un peu trop facile...

Certes, à votre décharge, on vous bourre le mou pendant toutes vos études sur des concepts qui, au final, dans quelques années, seront totalement dépassée...

En gros, vous imaginé le "codeur spontané" comme celui qui n'arrive pas à s'intégrer dans un projet! Pire! Vous imaginez le "codeur spontané" comme celui qui ne pourra aucunement mener un projet à bien...

Et pourtant!

Vous avez simplement du mal à accepter que tout le monde ne travail pas de la même façon et que certaines personnes sont capables d'imaginer / mettre en place des architectures complexes sans devoir les écrire sur papier...

Au final, c'est une certaine forme de rejet (de jalousie) de cette minorité de personnes qui ont l'informatique dans les tripes...

Ps : en me relisant, h'ajoute cela : "programmer de façon spontanée" ne veux pas dire ne pas avoir de réunion de suivis, de définition d'objectifs, "de se mettre d'accord avec les autres"

[davcha]

certaines personnes sont capables d'imaginer / mettre en place des architectures complexes sans devoir les écrire sur papier...

A partir du moment, où tu les imagines, c'est que tu as fait un plan dans ta tête, et que ce n'est donc plus le "spontané" dont on a pu parlé récemment dans ce sujet.

Y'a une différence entre "ne pas faire de plan du tout" et "ne pas noter le plan quelque part, car on est persuadé d'être capable de le retenir (à tort ou à raison)".

A mon avis, c'est plus une histoire de sémantique qu'autre chose ici : qu'est-ce qu'on entend exactement par "spontané".

Pour moi, il me semblait que c'était quelque chose de l'ordre de : "programmer sans avoir établi de plan, donc sans savoir où on va".

[LadyWasky]

A partir du moment, où tu les imagines, c'est que tu as fait un plan dans ta tête, et que ce n'est donc plus le "spontané" dont on a pu parlé récemment dans ce sujet.

Y'a une différence entre "ne pas faire de plan du tout" et "ne pas noter le plan quelque part, car on est persuadé d'être capable de le retenir (à tort ou à raison)".

A mon avis, c'est plus une histoire de sémantique qu'autre chose ici : qu'est-ce qu'on entend exactement par "spontané".

Pour moi, il me semblait que c'était quelque chose de l'ordre de : "programmer sans avoir établi de plan, donc sans savoir où on va".

hmm, qu'est ce qui peut définir la spontaneité en matière de développement ?
Examinons trois profils si vous le voulez bien

1) L'artiste (Virtuose pour certains, fou pour d'autres) :
A l'instar de l'artiste-Peintre qui crée sa toile sans avoir fait de croquis avant, certains d'entre nous sont capables d'imaginer l'oeuvre finale jusqu'au dernier coup de pinceau avec toutes les étapes intermédiaires globales nécessaires (là le ciel avec telle brosse, l'eau avec tel reflet) avant même d'avoir commencés, puis ensuite capables, à main levée de réaliser l'oeuvre. On sent bien qu'il y a une méthodologie particulière qui consiste à traiter la toile par zones elles mêmes subdivisées en sous-zones etc, un peut comme si nous construisions, par programmation, l'arborescence d'un disque dur.
Ceraines autres personnent sont aussi capables d'écrire un roman d'une traite, en commençant par la conclusion et en terminant par le chapitre du milieu, sans même avoir posé sur une feuille les différentes caractéristiques de leur oeuvre : protagonistes, antagonistes, lieux, rencontres, adjuvants, etc...
Ici on touche au personnage qui à "ça" dans le sang, pas forcément le génie (faut être modeste), mais celui qui a une facilité et une aisance telle qu'il peut se le permettre. Quand on l'a, c'est dans les tripes, il faut que ça sorte de suite pour être exprimé... Et le résultat, contre toute attente est là, sans coup férir, les ratés sont franchement rares.

Je pense que la spontanéité est là, et qu'il faut considérer et accepter ce genre de "programmation spontanée".

Par contre, l'artiste qui oublie de noter ses "recettes de cuisines", ses découvertes aura du mal à être compris si quelqu'un passe derrière pour restaurer sa toile et progressera peu dans son art.

Certains documentent, on fini par les intégrer dans l'équipe tels qu'ils sont,
d'autres non, ceux là on fini par les mettre dans un coin pour qu'ils puissent s'éclater comme des petits fous sur des projets peu importants et sans envergure. En général ces derniers finissent par se sentir frustrés du peu de challenge qu'on leur offre...

2) Celui qui ne sait pas encore s'y prendre, l'apprenti à qui on a oublier de dire qu'une méthode pouvait aider ou bien l'obtus (le boulet ? ) qui ne veut rien savoir de ceux qui ont acquis l'expérience en croyant qu'il va y arriver tout seul comme un grand :
La "programmation spontanée" du débutant est identique à celle du peintre qui ne maitrise pas les techniques de pinceaux, couteaux, brosses, crayon, fusain, mélange de couleurs et se retrouve rapidement à buter sur un problême technique, au mieux à devoir prendre un temps de réflexion pour aller plus loin, au pire à faire le mauvais choix et à pondre une "croute" comme résultat final

Le problême en programmation, c'est que rien ne distingue, jusqu'au résultat final, le boulet de l'artiste. Il y en a un qui fait de l'ombre, l'autre se fait fusiller à vu par ceux de la troisième catégorie décrits ci-après qui le traitent de fou...

Personellement, je trouve que la spontanéité n'a pas sa place à ce niveau, c'est à dire dans l'illusion ou l'errance.

3) Les techniciens, "les gens du métier" :
Et puis il y a celui qui connais ses limites, se sent plus ou moins à l'aise dans la maîtrise certaines techniques qui, s'il ne sait pas encore comment il va les appliquer saura qu'il faut utiliser telle ou telle technique plutôt qu'une autre aux vu des circonstance et des problêmes à résoudre
Ce dernier, déjà échaudé par la méthode précédente, examinera le problême initial sous formes de croquis, validera ses essais, etc... Bref, forgera son/ses algorithmes sur le papier pour se donner une idée claire du processus de création qu'il choisira : celui-là est un technicien, pas un artiste (rien de péjoratif hein ? ).
C'est souvent laborieux mais le résultat est souvent là.
Par contre, une démarche trop rigide peut nuire à l'innovation.
Il est donc bon, si vous faites partie de ceux-ci, de se réserver des moments "aventureux" et d'exploration de l'inconnu : c'est le coté recherche...
Le problême c'est que certains "gens du métier" n'acceptent pas (ou ne veulent pas accepter) les qualités de l'artiste et considèrent leur méthode comme absolue et unique, parce que celle de l'artiste, "elle n'est pas carrée"... Grave...
(A méditer : "On est toujours le con de celui qui se trouve de l'autre coté du mur et qu'il l'a construit" )

Conclusion :
Honnètement, qu'en pensez-vous ? Je me trompe de beaucoup ?
La "spontanéité" engendre t-elle la médiocrité ? Non, il ne faut pas exagérer.
Je suis certain que dans une équipe, un artiste et un technicien en binôme apprendront énormément l'un de l'autre, l'un temporisant les ardeurs de l'autres par exemple, l'autre trouvant une source d'inspiration dans des problêmes qui lui sont difficilement surmontables. Le résultat sera au delà de toute espérance.

Un peu différent mais pas tant que ça :
Il y en a qui on besoin de suivre des cours pour apprendre une langue étrangère et faire des exercices, réviser leur grammaire, d'autres non, un moi en immersion et c'est acquis...
Qu'est-ce qu'un langage de programmation si ce n'est une forme de communication ?

Je me considère come un artiste qui documente. (Où ça un algorithme ? )
Cotés facilités, si j'ai une mémoire désastreuse pour retenir quoi que ce soit , quand ça parle d'info, m'expliquer un concept, une idée, une fois suffit pour que je comprenne, sache l'utiliser, quoi en faire et le retenir par coeur et durabblement (je ne peux absolument pas vous expliquer comment je fais, c'est comme ça )
Par exemple, a l'époque du Basic, pascal, c, forth, fortran, ada, etc : il me fallait une semaine pour maîtriser un langage de programmation, pas plus.
Maintenant, avec les différentes bibliothèques, les API, etc... bien faché et motivé, j'en ai pour un mois pour maîtriser la bête et en faire à peu près ce que je veux... ou ce qu'on me demande d'en faire. je pense que c'est pas mal

Et vous ? vous faites partie de quelle catégorie ?
Que pensez vous des autres ?

[5:35pm]

eh les gars, faudrait franchement arreter de s'enflammer

la programmation spontannee, je veux bien, c'est meme ma methode.
Mais le coup de "l'artiste de la programmation qui "voit" son oeuvre dans les moindre details avant d'avoir ecrit sa premiere ligne de code", la je dis stop.

programmer spontanemment necessite ogligatoirement de revenir sur le code, afin d'affiner, adapter...
La cle de la programmation spontannee, c'est l'ecriture d'un code flexible, et marche generalement en programmation oriente objet. il n'est pas complique de dessiner les grandes lignes d'une application, d'attribuer des roles aux classes, de savoir quelles methodes on a besoin.
Oui, la programmation spontanne ca marche (sauf les grands projets en grosse equipe), mais non, on ne peut pas tout prevoir.
avec cette methode, on connais globalement les besoin de l'appli, mais on ne prevois en rien les details de l'implementation, la programmation spontannee, pour reprendre la metaphore du peintre, c'est dessiner une esquisse, les grandes lignes, juger quel place accorder a chaque element de la scene, puis preciser les details, puis affiner, paufinner...

il y en a des developpeur plus doue, c'est certain, mais faut pas exagerer.

[5:35pm]

eh les gars, faudrait franchement arreter de s'enflammer

la programmation spontannee, je veux bien, c'est meme ma methode.
Mais le coup de "l'artiste de la programmation qui "voit" son oeuvre dans les moindre details avant d'avoir ecrit sa premiere ligne de code", la je dis stop.

programmer spontanemment necessite ogligatoirement de revenir sur le code, afin d'affiner, adapter...
La cle de la programmation spontannee, c'est l'ecriture d'un code flexible, et marche generalement en programmation oriente objet. il n'est pas complique de dessiner les grandes lignes d'une application, d'attribuer des roles aux classes, de savoir quelles methodes on a besoin.
Oui, la programmation spontanne ca marche (sauf les grands projets en grosse equipe), mais non, on ne peut pas tout prevoir.
avec cette methode, on connais globalement les besoin de l'appli, mais on ne prevois en rien les details de l'implementation, la programmation spontannee, pour reprendre la metaphore du peintre, c'est dessiner une esquisse, les grandes lignes, juger quel place accorder a chaque element de la scene, puis preciser les details, puis affiner, paufinner...

il y en a des developpeur plus doue, c'est certain, mais faut pas exagerer.

[barjy]

A partir du moment, où tu les imagines, c'est que tu as fait un plan dans ta tête, et que ce n'est donc plus le "spontané" dont on a pu parlé récemment dans ce sujet.[...]

Certes, cependant, la réaction de nombreuses personnes concernait le manque de formalisme...

On est d'accord qu'il faille commenter son code, faire de la doc (encore que si le code est correctement commenté, la doc se générère "toute seule")... et savoir où l'on va!

[barjy]

programmer spontanemment necessite ogligatoirement de revenir sur le code, afin d'affiner, adapter...

et ? un artiste, puisque tu y fait référece, ne récommence pas "n" fois le même tableau, tout du moins la même partie du tableau avant d'arriver au résultat idéal ? le résultat qui le fait vibrrer ?

il y en a des developpeur plus doue, c'est certain, mais faut pas exagerer.

ha? c'est excessivement réducteur ce que tu dit! c'est comme dire qu'i y a des peintre plus doués que d'autres, mais qu'il ne faut pas exagérer...

(et oui, pourquoi ne pas comparer l'informatique à un art plutôt qu'à une science? Léonard de Vinci était à la fois un grand scientifique et un grand artiste...)

[barjy]

Ici on touche au personnage qui à "ça" dans le sang, pas forcément le génie (faut être modeste), mais celui qui a une facilité et une aisance telle qu'il peut se le permettre. Quand on l'a, c'est dans les tripes, il faut que ça sorte de suite pour être exprimé... Et le résultat, contre toute attente est là, sans coup férir, les ratés sont franchement rares.

Je suis certain que dans une équipe, un artiste et un technicien en binôme apprendront énormément l'un de l'autre, l'un temporisant les ardeurs de l'autres par exemple, l'autre trouvant une source d'inspiration dans des problêmes qui lui sont difficilement surmontables. Le résultat sera au delà de toute espérance.

Tiens donc, çe serais en échangeant des idées entres gens différents que l'on ferait avancer l'humanité ? Celà se saurait ma bonne dame...
(29ème degrés)

Et vous ? vous faites partie de quelle catégorie ?
Que pensez vous des autres ?

"Artiste qui documente" aussi

Les autres ? Cela fait bien longtemps que j'ai appris à les aimer, à les comprendre, à faire preuve d'empathie, à oeuvrer avec eux pour pouvoir toujours tirer la substantifique moelle de chacune des personnalités que j'ai rencontrées lors de mes voyages, conférences, ...
Et ceci dans un seul but : faire en sorte que tout le monde en sorte grandit par l'expérience partagées...

Ha, on parlait d'informatique là ?

[davcha]

On est d'accord qu'il faille commenter son code, faire de la doc (encore que si le code est correctement commenté, la doc se générère "toute seule")... et savoir où l'on va!

Ben bizarrement, je commente relativement peu mon code, en définitive.
J'ai pas dit que je le commentais pas du tout hein ; notemment j'ai tendance à bien davantage le commenter quand le code est destiné à un autre programmeur, ou quand il s'agit d'un tutorial (là je commente encore plus).

Mais dans la mesure du possible, j'essaie de faire un code "auto-descriptif", si tu veux. Ce qui est faisable pour peu que tu ne fasses pas de choses trop compliquées en une seule fois.

Sinon, pour les catégories de waskol, je pense faire partie des 3 catégories en fait (bon la 2e faut pas le dire trop fort :p).
Je fais partie des techniciens quand je suis face à un problème que j'ai déjà vu mille fois,
des artistes quand j'ai besoin de me montrer un peu aventureux,
et des boulets ( ) quand j'apprends à utiliser convenablement quelque chose de nouveau.

[zecreator]

Hello,

Pour moi, il me semble logique de passer par l'étape "papier" avant de se lancer dans le développement proprement dit.

Concevoir un storyboard, un cahier des charges, les diagrammes UML, la modélisation des bases, est tout aussi important car le développement en sera grandement simplifié. "Penser" pour "bien faire".

Bien entendu, ce type de réalisation peut être mise en place si les délais de production sous souples et si l'équipe de développement est bien supervisée (chefs de projets bonjour!).

Les grands comptes ont les réels moyens (temps et humain) de mettre en place ces tâches.

Pour les plus petites structures, c'est difficile, surtout quand il n'y a qu'un seul développeur sous la main (qui fait également office de technicien et d'installateur d'imprimante).

Ce qui est mon cas ! Ceci dit, manquer de temps pour faire de la documentation, des plans et des diagrammes ne me pose pas de réels problèmes. Je m'en passe puisque je n'ai pas le choix. Il a fallut que j'adapte ma méthode de développement de façon à fournir des applications correctes répondant au maximum à la demande.

Aujourd'hui avec l'expérience, je peux dire sans prétention que je suis capable de développer une application en concevant le plan technique au fûr et à mesure de mon code. Je commente juste ce qu'il faut pour me souvenir de "pourquoi j'ai fais ça ?". No souci.

[MicaelFelix]

Pour ceux qui associent à la "programmation spontanée" et le "pisseur de code"... faut pas exagérer non plus...

C'est pas parce que quelqu'un est capable de comprendre un problème en programmation et de le mettre en code rapidement sans passer par un algorithme que c'est forcément un "mauvais programmeur"... c'est vrai que quand tu programmes facilement et rapidement, tu vois la (ou les) solutions et tu commences à coder donc forcément les commentaires y prennent un coup. Moi personnellement ce qui m'arrive c'est de coder en premier, puis ensuite rajouter des commentaires là où il y en a besoin pour que je ne sois pas perdu le mois suivant au cas où le code devrait être révisé.

Et puis c'est assez primaire de cataloguer les programmeurs qui codent rapidement... c'est pas parce que tu es doué de le faire rapidement que tu vas négliger le nom des variables pour rendre la structure du code incompréhensible!

Il m'est déjà arrivé de continuer à débugger un programme l'ordinateur éteint, on l'allume et c'est bien ça.

Idem pour moi, je peux trouver des solutions en me reposant, il suffit d'y penser et ça se construit tout seul souvent

Je préfère qu'un programmeur s'y retrouve dans n'importe quel code (normalisation, structuration, dictionnaire de données etc...) plutôt que reconnaitre un programmeur en ouvrant un code.

Je suis d'accord mais le respect de l'organisation du code est une partie importante vu qu'elle va te faire perdre quelques secondes lors de l'écriture du code, mais t'en faire gagner des minutes voir des heures lors de la relecture si il y a besoin de la changer! Le principe de l'informatique c'est bien l'évolution et si tu négliges la lisibilité tu négliges aussi la maintenance (faut pas oublier que si ton programmeur se casse les autres qui font essayer de continuer ce que faisait ce programmeur sont dans la M#### si tu vois ce que je veux dire ).

Moi je code seul, j'ai pas d'équipe, je travaille sur des petits projets, je fais de la programmation "spontanée" pour mes algorithmes complexes (car le papier c'est bien beau mais c'est assez énervant!! vive la programmation) mais cela n'empêche pas que je m'organise pour pouvoir avoir un code RÉUTILISABLE. Parce que c'est quand même le but... sinon au revoir les mises à jour et à la poubelle le produit!

Il m'arrive souvent de commencer une application, qui reste en souffrance pour diverses raisons et que je reprends après plusieurs jours(mois) avec la satisfaction de comprendre ce que j'ai voulu réaliser grâce aux nombreux commentaires que je dispense à profusion.

Idem pour moi, je ne néglige plus les commentaires (même si j'en fais très peu), mais surtout les noms des fonctions, modules & variables! Car c'est quand même ça qui reste le "corps" du code.

[Hephaistos007]

Le principe de l'informatique c'est bien l'évolution et si tu négliges la lisibilité tu négliges aussi la maintenance (faut pas oublier que si ton programmeur se casse les autres qui font essayer de continuer ce que faisait ce programmeur sont dans la M#### si tu vois ce que je veux dire ).

C'est justement cela que la programmation spontanée est incapable de guarantir. Tu viens de t'auto suicider

Moi je code seul, j'ai pas d'équipe, je travaille sur des petits projets

Comme déjà dis sur ce topic, le débat concerne d'avantage des grands projets. A de petite échelles, même les pires méthodes aboutissent : "Tu peux toujours tailler ta haie avec un coupe-ongle". A de large échelles, c'est une autre histoire...

[MicaelFelix]

C'est justement cela que la programmation spontanée est incapable de guarantir. Tu viens de t'auto suicider

Je ne me suicide pas, et toi tu ne lis rien...
Je me cite moi même:

Et puis c'est assez primaire de cataloguer les programmeurs qui codent rapidement... c'est pas parce que tu es doué de le faire rapidement que tu vas négliger le nom des variables pour rendre la structure du code incompréhensible!

De plus c'est pas parce que tu fais un bout de programmation spontanée que tu n'as pas étudié le problème en question avant... les idées doivent bien partir de quelque part.

[zecreator]

MicaelFelix a dit : "faut pas oublier que si ton programmeur se casse les autres qui font essayer de continuer ce que faisait ce programmeur sont dans la M#### si tu vois ce que je veux dire)"

Il me semble que ce soit l'état d'esprit de beaucoup d'informticien. Partir en laissant un minimum d'infos (peut-être dans l'espoir de se voir offir une petite mission en independance par son ancienne boite, que sais-je ?).

"Excuse-nous de te rappeler vieux, mes les gars ne s'en sortent pas avec ton truc ?i. Tu peux nous filer un coup d'main, tu nous dis ton prix !"

J'ai même vu des techniciens de maintenance changer volontairement les mots de passe des serveurs la veille de leur départ.

La programmation spontanée a aussi cet avantage

[MicaelFelix]

C'est avantageux mais ça dépend pour qui
Et là encore tu viens de cataloguer ceux qui programment spontanément comme de mauvais codeurs... comme je le disais avant tu peux très bien coder vite tout en faisant attention à rester lisible et très compréhensible.

[Hephaistos007]

comme je le disais avant tu peux très bien coder vite tout en faisant attention à rester lisible et très compréhensible.

Oui, mais tu n'obtiendras jamais autant de lisibilité de de compréhensibilité qu'avec les formalismes préconisés dans les phases précédents la production du code. C'est là toute la substance de ce débat.

[MicaelFelix]

Je sais pas mais franchement, là par exemple je tapais ça juste un peu avant de lire ton message, et sans aucun algo au préalable (avec des petits tests de temps en temps pour voir si je suis dans la bonne voie):

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
SourceXML est une chaîne = fChargeTexte ("E:\xmlLaguage.xml")

//Création du document XML
XMLDocument("DocXML", SourceXML)
SI ErreurDétectée ALORS
	//pasauformat
	RETOUR
FIN

//Chaines qui vont servir au stockage temporaire de certaines données provenant du XML (Utilisées pour l'actualisation des données de la DB)
contenu_field,contenu_part,contenu_text sont des chaînes = ""

XMLPremier("DocXML")

TANTQUE XMLTrouve("DocXML")
	SELON XMLTypeElement ("DocXML")
		CAS XMLBalise :  Trace("XMLBalise de nom: "+XMLNomElément("DocXML")+" et de donnée: "+XMLDonnée ("DocXML"))
		CAS XMLAttribut : Trace("XMLAttribut de nom: "+XMLNomElément("DocXML"))
	FIN
	
	//Traitement
	SELON XMLNomElément("DocXML")
		
		CAS "version" //Doit rejeter si le numéro de version n'est pas au minimum celui du fichier XML
			SI ChaîneCompare(XMLDonnée ("DocXML"),ExeInfo(exeVersion,ComplèteRep(fRepExe())+"Birds Evolution Pro.exe"))>0 ALORS 
				Erreur("Err: This file require more than your current version!")
				RETOUR
			FIN
			
		CAS "language" //Doit rejeter si le langage renvoyé par le fichier XML n n'est pas le même que le logiciel utilisé couramment
			SI PAS ChaîneCompare(TraductionSimple("UserLanguage"),XMLDonnée ("DocXML"))=0 ALORS
				Erreur("Err: Wrong XML database returned ("+XMLDonnée ("DocXML")+" instead of "+TraductionSimple("UserLanguage")+")")
				RETOUR
			FIN
			
		CAS "field","part","text" //Cas Standard de stockage de nouvelles données
			{"contenu_"+XMLNomElément("DocXML")}=XMLDonnée ("DocXML")
			
		CAS "translation" //Cas de mise à jour des données
			//Vérification des données
			SI PAS contenu_field="" ET PAS contenu_part="" ET PAS contenu_text="" ALORS
				HLitRecherche(TraductionLogiciel,NomChamp,contenu_field)
				SI HTrouve(TraductionLogiciel) ALORS
					TraductionLogiciel.NomChamp=contenu_field
					TraductionLogiciel.Partie=contenu_part
					TraductionLogiciel.Texte=contenu_text
					HModifie(TraductionLogiciel)
				FIN
			FIN
			//Suppression des données temporaires
			contenu_field=""
			contenu_part=""
			contenu_text=""
	FIN
	
	
	XMLSuivant("DocXML")
	SI PAS XMLTrouve("DocXML") ALORS XMLFils("DocXML")
FIN

C'est du code Windev, donc proche de l'algo, mais j'ai aucune difficulté à faire la même chose avec les autres langages de programmation! Et si tu me dis que je pisse sur le code avec ma programmation spontanée, ben là franchement je comprends plus rien à ton monde!

[Nip]

C'est vrai que 20 lignes de codes sont tout a fait representatives d'un projet de taille grande ou moyenne (ou meme petit, parce que a part sur ma TI92, ca fait un bail que j'ai pas ecris un programme de 20 lignes). Je peux m'y retrouver dans 100 lignes voire 1000 lignes (quoique au bout d'un moment ca me les brise severe) mais des centaines de milliers de lignes c'est quand meme une autre histoire.

De toute maniere je n'ai pas l'impression que tu veuilles comprendre ou comprenne, ce que Hephaistos007 t'explique.

[MicaelFelix]

Moi je donnais juste mon avis parce qu'au départ sur ce sujet y'a pas marqué "réservé pour les professionnels qui codent au minimum 1000 lignes de code par petite partie de programme"
Je disais juste que même si tu programmes directement sans faire une analyse de 1h au papier sur chaque petite partie de ton logiciel (comme j'ai montré sur mon message précédent, c'était en aucun cas pour montrer "regardez je suis un génie j'ai tapé 20 lignes de codes") t'es pas forcément un "pisseur de code" comme vous dites

"que tu veuilles comprendre ou comprenne"
Après si tu me traites d'imbécile en disant que je comprends rien c'est ton problème!