Discussion :

[SlashEne]

Bonjour,

Je suis actuellement un stagière dans une petite boite d'editeur logiciel et malgrès ma jeune expérience dans le domaine professionnel, j'ai toujours été poussé a écrire un code bien conçu et propre (application de design pattern et séparation des couches).
Poussé à le faire par des profs, par des livres, par des forums, par des site comme joel on software.

Après avoir developper pendant 3 ans comme un porc (code très sale) je m'applique à faire du bon code depuis maintenant 2 ans et je suis persuadé que cela me rend les idées plus clair, me simplifie tout ce qui peut paraitre compliqué, me fait aimer encore plus le developpement, et me permet d'être plus 4 à 5 fois plus rapide qu'avant.

Cependant voila que depuis que je commence ma vie professionnelle je tombe sans arret sur du code pourri.
Il n'est pas rare que je dois reprendre une partie d'un code d'une application (que je fini par reécrire entierement) qui a 1 seul classe avec 3000 lignes de code a l'interieur.
Il n'est pas rare n'ont plus que je doive reprendre du code HTML pourri ne respectant aucune norme (pas de guillement pour les attribut, balise en majuscule etc...).
Il n'est pas rare que je tombe sur des base de donnée d'une application avec 400 table et 300 procédure stocké écrite à la main avec des nom du genre "Table1", "Table2".

Je me demande vraiment pourquoi des développeurs qui sont par définition des pro (dans le sens qu'ils vive du developpement), puisse sortir un code aussi pourri.

J'aimerai savoir si il est vraiment courant de voir ca ?
Est ce que vous pensez que c'est vraiment dangereux pour une entreprise ?
Est ce que si dorénavant je trouve un stage (ou un emploi) dans une tel entreprise avec de tel développeurs il faudrait mieu que j'aille voir ailleurs ?

[eclesia]

Je me demande vraiment pourquoi des développeurs qui sont par définition des pro (dans le sens qu'ils vive du developpement), puisse sortir un code aussi pourri.

J'aimerai savoir si il est vraiment courant de voir ca ?
Est ce que vous pensez que c'est vraiment dangereux pour une entreprise ?
Est ce que si dorénavant je trouve un stage (ou un emploi) dans une tel entreprise avec de tel développeurs il faudrait mieu que j'aille voir ailleurs ?

J'ai rencontré ca en stage, une application VB (un plugin pour une application cartographique). Bien sur c'est un module payant fait par une boite relativement connu dans le domaine, et qui est toujours vendus au jour d'aujourd'hui ...

C'est pour dire que Oui c'est courant, et le coté obligation de resultat des sociétés n'arrange pas les choses.

C'est aussi une facon d'assurer la vente des noouvelles versions et d'assurer que le client ai besoin de la boite

[TheCaribouX]

C'est pour dire que Oui c'est courant, et le coté obligation de resultat des sociétés n'arrange pas les choses.

Je maintiens aussi. J'ai également commencé un stage; alors au début les intentions de mon superviseur étaient louables, on va appliquer les design pattern, rendre le code le plus réutilisable possible... et au final 2 semaines apres, 'est "le marketing aimerait un prototype rapide".... donc un programme fait "à la va vite" .. alors j'me bats pour le structurer le mieux possible, et le faire le plus vite possible..est-ce compatible...

[_vince_]

Je me demande vraiment pourquoi des développeurs qui sont par définition des pro (dans le sens qu'ils vive du developpement), puisse sortir un code aussi pourri.

Bienvenue dans le monde reel.

Les developpeurs doivent ecrirent un logiciel qui repondent aux besoins des utilisateurs/clients et le plus vite possible. C'est deja un defi en soi.

On ne demande pas aux developpeurs d'ecrire un code de qualite. Ca prend plus de temps et le client ne le voit pas puisque l'utilisateur ne voit pas le code. Pourquoi une societe devrait livrer un code de qualite si ca coute plus cher et que ca ne rapporte rien ?

Il y a plusieurs types de developpeurs. Il y a les debutants qui apprennent le langage et la P.O.O en meme temps qu'ils codent. Et il y a les developpeurs plus aguerris qui codent mieux que les debutants. Tu dis toi meme qu'il t'a fallu trois ans pour ameliorer ton code...
Et aussi, il y a les passionnes qui veulent faire un code de qualite et ceux qui font ca pour en vivre (comme tu dis) et qui baclent leur travail. A mon avis, ces derniers constituent la majorite. Je ne pense pas que ce soit specifique aux developpeurs. Et ensuite, il y a des projets ou il n'y a apparemment pas d'architecte logiciel, personne pour inspecter le code des debutants...

Ensuite une fois que le code passe en phase de maintenance, les developpeurs corrigent ou inserent des palliatifs qui rendent le code encore plus moche et incomprehensible. Au fur et a mesure des developpeurs differents, le code devient impossible a maintenir. Tu as envie de tout jeter et de tout recommencer a zero...

Je parle d'apres ma petite experience en integration/validation logicielle ou j'ai fait la recette de plusieurs logiciels. Et effectivement, j'ai moi aussi ete surpris par la non-qualite de certaines parties de code.

Le seul danger est d'exploser les budgets de maintenance s'il y a beaucoup trop de bugs.

Je dirais aussi que dans les ecoles, on apprend un langage mais on ne nous apprend pas a coder proprement. C'est pour ca que les debutants ne sont pas au courant des bonnes pratiques. Et a mon avis, il faut plusieurs annees avant de maitriser un langage objet, et si on se documente et on si on se remet en cause souvent. Ceci explique peut etre cela...

[SlashEne]

Les developpeurs doivent ecrirent un logiciel qui repondent aux besoins des utilisateurs/clients et le plus vite possible. C'est deja un defi en soi.

On ne demande pas aux developpeurs d'ecrire un code de qualite. Ca prend plus de temps et le client ne le voit pas puisque l'utilisateur ne voit pas le code. Pourquoi une societe devrait livrer un code de qualite si ca coute plus cher et que ca ne rapporte rien ?

Je ne suis pas totalement d'accord sur l'utilité d'avoir un code propre essentiellement pour la maintenance. Si je me remettais a programmer comme je le faisais avant même sans parler de maintenance je suis persuadé que je serais 4 à 5 fois moins productif (j'espere pouvoir dire 10 fois moins dans quelques année (reference à Steve McConnel)).

Mais il est vrai qu'une personne non formé pendant ses études ou lors de projets personnelles à produire du code propre perdrait un temps fou à le faire lors de projet professionnel. M'enfin le developpement c'est le choix d'une formation permanente et un chef de projet qui néglige la formation d'une équipe de développement me semble plutôt dangereux non ?

[_vince_]

Je ne suis pas totalement d'accord sur l'utilité d'avoir un code propre essentiellement pour la maintenance.

Le code est écrit une fois mais maintenu pendant des années. En général, la phase de maintenance est plus longue que la phase de developpement. D'ou l'interet d'avoir un code propre des le début.

Steve McConnel

On a les memes references Malheureusement, tout le monde ne connait pas les bonnes pratiques.

Mais il est vrai qu'une personne non formé pendant ses études ou lors de projets personnelles à produire du code propre perdrait un temps fou à le faire lors de projet professionnel. M'enfin le developpement c'est le choix d'une formation permanente et un chef de projet qui néglige la formation d'une équipe de développement me semble plutôt dangereux non ?

Je ne pense pas que ca prenne beaucoup plus de temps de coder proprement. A mon avis, c'est inné. Il y a ceux qui sont fait pour coder proprement, et les autres qui baclent. Les perfectionnistes se font rares...

Je vais prendre un example qui peut paraitre un détail insignifiant mais qui pour moi est révélateur. Par exemple, quand tu vois un entier, qui physiquement ne peut etre que positif, stocké dans un entier signé, tu te demandes pourquoi le codeur ne la pas stocké dans un entier non signé. La raison est que ca va plus vite d'écrire "int" que "unsigned int". Ensuite, celui qui passe derriere se demande pourquoi c'est baclé.

La plupart des métiers necessitent une formation permanente. Je ne suis pas chef de projet. Mais a mon avis, vérifier la qualité du code n'est malheureusement pas la priorité du chef de projet. J'espere que des chefs de projet pourront me contredirent.

[SlashEne]

La plupart des métiers necessitent une formation permanente. Je ne suis pas chef de projet. Mais a mon avis, vérifier la qualité du code n'est malheureusement pas la priorité du chef de projet. J'espere que des chefs de projet pourront me contredirent.

Toutes mes expériences professionnelles actuelles (dans le cadre de stage), je n'ai en effet pas trouvé 1 seul chef de projet demander un code propre.
Même à plus bas niveau, mon maître de stage code comme ma grand mère .
Dans la même mesure je n'ai évidemment pas trouvé 1 seul chef de projet sachant ce que signifie "extreme programming" ou "methode agiles"...

Je suis tombé sur un article de Joel Spolsky
Cette article montre 12 étapes a avoir pour faire un meilleur code.

Un score de 12 est parfait. 11 est tolérable. Mais avec 10 ou moins, vous avez de sérieux problèmes. Le fait est que la plupart des firmes qui font des logiciels ont un score de 2 ou 3. Et ils ont sérieusement besoin d'aide, parce que des sociétés telles que Microsoft tournent à 12 en permanence.

Apparemment cela signifie bien que beaucoups d'entreprise font des logiciels crado.
(j'admet que je trouve que ce test porte plutot sur la gestion general du projet du point de vue du developpeur, plutot que sur la qualité d'un code).
Meme moi avec toute la volonté que j'ai de faire un code propre, et si j'avais le pouvoir de diriger un projet de developpement suivant les bonnes pratiques agile et de qualité de code je n'arriverai pas à faire plus de 3 ou 4 a ce test. Comment un chef de projet ne connaissant pas ce que c'est les méthodes agiles peut même ésperer arriver a 2 ???

Cependant les sociétés ou je suis et ai été, fonctionnent actuellement bien.
Bien sur je pense qu'il y a un énorme écart de compétence entre les chef de projet et les programmeur de chez microsoft et ceux que j'ai vu jusqu'a maintenant.

Je ne peux cependant pas croire 1 seule seconde que les methodes agiles, et les bonnes pratiques soit du pipo.
Je ressens les faiblesses dans les entreprises ou j'ai été lorsque l'on doit mettre à la poubelle un code illisible, ou que l'on a l'habitude de depasser les previsions.
J'ai deja entendu mon maître de stage me dire de faire un diagramme de grant pour mes previsions sur le temps que je passerais sur le projet qu'il m'a confié, et puis m'avouer en toute franchise "les prévisions et estimations ne sont jamais respécté".
Pourquoi me demander de les faire si elles ne sont pas réspecter ???
Pourtant les méthodes agiles sont consciente de cela et proposent des solutions non ?
Je suis même persuadé que le vrai développeur pro (le 10x), pourrait faire une estimation fiable pour un projet de 6 mois.homme (voir sur 1 an.homme) juste parce qu'il connait les bonnes pratiques de conceptions. (ok c'est un petit projet mais même sur un si petit projet, j'ai vu des estimations dérapées du simple au double).

Les programmeurs et chef de projet auquels j'ai eu à faire ont pourtant de l'expérience alors pourquoi continuer à faire sale ??
J'en suis revenu à lire
Analogie de la construction d'un fort pour les enfants de Steve McConnel
et j'ai trouvé pourquoi des developpeurs experimentés continue à écrire sale :

If people like the software that the team produced, and the software is successful, then that reduces the incentive to try to do better next time

Tout est bien qui fini bien !

[Franck SORIANO]

C'est un vaste débat...

J'aimerai savoir si il est vraiment courant de voir ca ?

Je dirais très très courant. Même chez les plus motivés pour faire du code de qualité. On commence par essayer de faire du code propre. Et puis quand la deadline approche, ben tout ce qui compte c'est que ça marche avant la deadline...

Est ce que vous pensez que c'est vraiment dangereux pour une entreprise ?

Dangereux : Oui et non. Ca explose les coûts de maintenance. Le problème c'est que l'entreprise (disont le management) n'a généralement pas consience du temps perdu à cause d'un mauvais code.

Est ce que si dorénavant je trouve un stage (ou un emploi) dans une tel entreprise avec de tel développeurs il faudrait mieu que j'aille voir ailleurs ?

C'est à toi de voir. Mais si chaque fois tu vas voir ailleurs, ben tu risques d'avoir du mal à trouver quoi que ce soit. Sans compter que les boîtes qui cherchent à coder très proprement risques aussi d'être très exigentes au moment du recrutement. Elles risquent de ne pas vouloir prendre un débutant sans expériences...

Je me demande vraiment pourquoi des développeurs qui sont par définition des pro (dans le sens qu'ils vive du developpement), puisse sortir un code aussi pourri.

Comme tu le dis toi-même, un pro c'est quelqu'un qui est payé pour faire ce qu'il fait. Ca ne veut pas dire qu'il est compétant et consiencieux...

Maintenant le problème est beaucoup plus complexe que ça. Je t'invite à réfléchir à la question suivantes : Qu'est-ce qu'on bon code ?
- Très souvent, dès qu'on regarde le code de quelqu'un d'autre, on trouve que c'est pourri, juste parce que ce n'est pas fait tel qu'on l'aurrait fait sois-même. Souvent, c'est même qu'une question mode.
- Est-ce que respecter une méthode de développement ou un modèle à la lettre garanti-t-il de faire du bon code ? Chaque méthodes, chaque modèle a ses avantages et inconvénients. Elles sont définies sous formes théorique, par rapport à des cas d'écoles. Mais dans la vrai vie, on ne se trouve pas dans un cas d'école. Il faut adapter, choisir le meilleur de chaque modèle pour définir SON architecture applicative...
- Les méthodes ou modèles choisis font-elle l'unanimité. Seront-elles toujours bien perçues dans quelques années ?
Il y a quelques décénies, on ne parlait que du cycle en V. Aujourd'hui on ne fait que le critiquer.
On a parlé des méthodes RAD. On les critiques tout autant.
Tu parles de "L'extreme programming" combient de chef de projet (parfaitement compétent et expérimenté) ne considèrent pas XP comme une méthode sérieuse...

Et si on se place du côté de la qualité logiciel, c'est encore pire. Il existe bon nombre de critères de qualité qui généralement sont contradictoires...

Bref, tout ça pour dire que n'importe quel code peut paraitre être du bon code un jour, et complètement pourri le lendemain.

Le problème de l'information, c'est que justement c'est loin d'être une science exacte. Il n'y a jamais de bonnes et mauvaises solutions, c'est toujours un choix de ce qui semble être le moins mauvais.

Je dirais aussi que dans les ecoles, on apprend un langage mais on ne nous apprend pas a coder proprement.

Ca dépend des écoles. Il y en a de tout type. Celles qui enseigne des langages, celles qui apprennent à concevoir et gérer un projet informatique mais pas à coder... Moi je dirais que le plus gros problème, c'est que la majorité des développeurs (surtout en web) se sont auto-formés tout seuls dans leur coin et n'ont pas fréquenté la moindre école d'informatique du tout.
Ou alors, ils ont été formés il y a très longtemps et ont refusé d'évoluer ensuite.

Je ne pense pas que ca prenne beaucoup plus de temps de coder proprement. A mon avis, c'est inné. Il y a ceux qui sont fait pour coder proprement, et les autres qui baclent. Les perfectionnistes se font rares...

Je suis d'accord sur le fait que coder proprement ne prend pas plus de temps. Par contre ce n'est pas inné, ça s'apprend et ça prend du temps.
Et je dirais également que les perfectionnistes (disons surtout les puristes)sont tout aussi dangereux que ceux qui baclent leur code. Ils vous prennent la tête sur des détails sans intérêts, font perdre du temps par ce qu'ils ne savent pas s'écarter d'un modèle théorique pour passer à la pratique.
Bref, ils récitent un modèle par coeur sans en comprendre réellement l'esprit.

J'ai deja entendu mon maître de stage me dire de faire un diagramme de grant pour mes previsions sur le temps que je passerais sur le projet qu'il m'a confié, et puis m'avouer en toute franchise "les prévisions et estimations ne sont jamais respécté".
Pourquoi me demander de les faire si elles ne sont pas réspecter ???

Ben oui, par définition un planning c'est écrire ce qu'on ne fera pas .
Plus sérieusement, ça permet de ce donner une référence, de mesurer les dérapages du projet, de s'assurer qu'on possède la capacité à produire le reste à faire et d'initier les actions correctives lorsqu'on voit que ça dérape.
En théorie on devrait respecter le planning. Mais dans la pratique c'est quasi infaisable. Donc on pose des jalons, et on s'efforce de suivre le projet et replannifier régulièrement pour respecter ces jalons...

[el_slapper]

Assez d'accord avec Franck Soriano : un code sale, c'est le code d'un autre(ou de soi-même quelques années auparavant).

Et puis les gens qui passent d'un langage à un autre font souvent du dégât. Des experts assembleurs, qui font de l'assembleur "propre", quand ils passent au Cobol, font du Cobol caca et illisible. Des cobolistes "propres" qui passent à Java............etc........ Je suis en plein dedans.

Celà dit, la pression du temps pousse parfois à être inventif et à appliquer des architectures de code plus novatrices et lisibles. Ca m'est arrivé. Mais c'est rare. Un code passe 70% de son temps en maintenance, et le mainteneur a en général pour hantise de tout casser. Donc il fait sa maintenance a minima, et on se retrouve avec du code mort partout. Et quand c'est du code avec 25 ans d'âge, des maintenances plusieurs fois par mois, que le code de base ressemblait à de l'assembleur(avec des GOTO partout et des labels sur 3 caractères), que la principale évolution ressemble à du RPG(avec tous les ordres alignés sur la même colonne, sans indentation), mais qu'en fait c'est du Cobol(truffé d'ordres aussi cabalistiques qu'inutiles tels que les SKIP et les EJECT), ben il faut 2 semaines pour rétro-engineerer 3 000 misérables lignes.

qu'on foutra à la poubelle pour faire quelque chose de propre(enfin!) à la place, mais quelque chose me dit que dans quelques années.....

[Garulfo]

[...]En général, la phase de maintenance est plus longue que la phase de developpement. D'ou l'interet d'avoir un code propre des le début.[...]

Elle est surtout plus couteuse: 70% des efforts en moyenne.

[SlashEne]

Je n'ai jamais eu a maintenir un programme jusqu'à maintenant, je ne pensais pas que la maintenance était si importante que ca !

[SlashEne]

Donc on pose des jalons, et on s'efforce de suivre le projet et replannifier régulièrement pour respecter ces jalons...

Si je ne me trompe pas, ca m'a tout l'air d'une méthode agile.

[Garulfo]

Je n'ai jamais eu a maintenir un programme jusqu'à maintenant, je ne pensais pas que la maintenance était si importante que ca !

Le 70% que j'avance est une moyenne sur des projets industriels. C'est des chiffres avancées par Barry Boehm. Il faut garder à l'esprit que c'est une moyenne. Un jeu qui a une durée de vie de 2/3 ans en général n'aura pas le même coût qu'un système de gestion des feuilles de paie dans une banque qui en a 20 ! De plus, un bug dans un jeu, c'est chiant, mais pas aussi terrible qu'un bug dans un système de réservations de billets d'avions. Mais oui ! la maintenance coute un prix de fou en ressources. Ensuite il faut garder à l'esprit aussi que la majorité des couts sont due à une analyse des besoins déficientes, puis à une conception qui n'a pas atteint ces objectifs. C'est là où la propreté d'un code est fondamental. Quand tu dois modifier un besoin car il a été mal capturé lors de la phase d'élicitation, il faut être capable de retraçer la conception puis le code qui a été implémenté pour répondre au premier besoin et le changer pour le deuxième besoin. C'est là où les couts sont complètement astronomiques.

[Franck SORIANO]

Si je ne me trompe pas, ca m'a tout l'air d'une méthode agile.

Non ça c'est le b-a-ba de la gestion de projet. On définit des échéances et on fait en sorte de les respecter. Tout le monde sait que ce sont les échéances qui font avancer un projet. Sans échéances, ben pourquoi se presser, on a le temps de perdre du temps...

Le but des méthodes agiles, c'est plutôt de répondre à un autre problème :
- Le cahier des charges et les spécifications sont faits à un instant t.
- Il faut un certain temps pour faire le développement.
- Les besoins risquent fort d'avoir changé entre leur expression initiale et la livraison de la solution.
Le but des méthodes agiles c'est de s'adapter rapidement a cette évolution des besoins pour que le produit ne soit pas déjà obsolète au moment de la livraison.

Pour le reste, ben oui la maintenance est beaucoup plus importante que ce que s'imagine un débutant. C'est la principale préoccupation d'un professionnel et c'est la seule raison qui nécessite d'écrire un code propre et bien conçu. Sans elle, du moment que tu livres à la bonne date, tu te fous complètement de la façon dont l'appli fonctionne à l'intérieur, tout ce qui compte c'est que ça marche.

On cherche à faire du code propre, structuré et compréhensible pour qu'il soit maintenable.
Il ne faut pas oublier que la maintenance comprend trois domaines :
- La maintenance currative : C'est ce à quoi on pense quand on dit maintenance. Ca consiste à réparer quand ça casse. A corriger les bugs...
- La maintenance évolutive : C'est un petit peu moins évident. Ca consiste simplement à faire évoluer le produit pour qu'il continue à fonctionner suite aux évolutions de son environnement (nouvelle règle de gestion à implémenter dans le SI, nouvelle version du SGBD...)
- La maintenance préventive : C'est encore moins évident, mais ça consiste à prendre des mesures avant que ça ne casse, pour éviter que ça ne casse de façon catasprophique. Par exemple, c'est surveiller un serveur, se rendre compte que les performances se dégradent fortement et agir avant que toute la prod ne soit plantée et les clients en rade...

Ensuite, la durée de vie d'un logiciel c'est facilement 10, 20, 30 ans... Donc sur la durée, la maintenance dépasse nécessairement le développement initial.

[HanLee]

Je vais prendre un example qui peut paraitre un détail insignifiant mais qui pour moi est révélateur. Par exemple, quand tu vois un entier, qui physiquement ne peut etre que positif, stocké dans un entier signé, tu te demandes pourquoi le codeur ne la pas stocké dans un entier non signé. La raison est que ca va plus vite d'écrire "int" que "unsigned int". Ensuite, celui qui passe derriere se demande pourquoi c'est baclé.

Juste pour revenir sur ça, le coup de l'unsigned int plutôt que l'int c'est pas forcément mieux.

Parfois ça m'a joué des tours. En OCaml, les "unsigned int" n'existent pas, que des int, ça n'empêche pas qu'il est en plus facile d'avoir un code correct qu'en C/C++/Java.

Le problème avec l'unsigned int, c'est que les entiers naturels, c'est que ça se comporte pas très bien avec les soustractions, c'est pas un groupe quoi.

Il arrive que tu joues avec les indices toujours positifs d'un tableau, dans des conditions qui peuvent être plus ou moins compliquées. Tu auras envie de simplifier des inéquations, équations, faire passer des indices de l'autre côté, et BOUM.

Tu comprends rien, mathématiquement, c'est correct, mais c'est tout simplement parce que les valeurs négatives n'existent pas...

[Franck SORIANO]

Le problème avec l'unsigned int, c'est que les entiers naturels, c'est que ça se comporte pas très bien avec les soustractions, c'est pas un groupe quoi.

Je ne suis pas convaincu. Un nombre négatif, c'est en réalité un nombre positif spécialement choisi pour que lorsque tu l'additionne à un autre nombre, ça fasse un overflow dont le résultat sera le résultat de la soustraction.
Nombre signé ou non signé c'est exactement la même chose. C'est les calculs sont les mêmes, c'est juste une information pour dire au compilateur comment il doit interpréter le résultat du calcul.

Je dirais plutôt que les gens utilisent des nombres signés parce qu'on leur a appris à programmer comme ça. Que mathématiquement, un entier ca peut être positif ou négatif donc on retient : entier = int. (ou entier = integer en pascal). Aller faire retenir à un débutant que entier ça peut être :
smallint, byte, shortint, word, integer, longint, cardinal, comp, int64...

Il y même des développeurs qui ne savent pas que les types non signés existent.

[souviron34]

Je ne suis pas convaincu. Un nombre négatif, c'est en réalité un nombre positif spécialement choisi pour que lorsque tu l'additionne à un autre nombre, ça fasse un overflow dont le résultat sera le résultat de la soustraction.
Nombre signé ou non signé c'est exactement la même chose. C'est les calculs sont les mêmes, c'est juste une information pour dire au compilateur comment il doit interpréter le résultat du calcul.

Je dirais plutôt que les gens utilisent des nombres signés parce qu'on leur a appris à programmer comme ça. Que mathématiquement, un entier ca peut être positif ou négatif donc on retient : entier = int. (ou entier = integer en pascal). Aller faire retenir à un débutant que entier ça peut être :
smallint, byte, shortint, word, integer, longint, cardinal, comp, int64...

Il y même des développeurs qui ne savent pas que les types non signés existent.

100% d'accord (et avec ton post precedent d'ailleurs ).

J'ai tres tres tres longtemps fait partie du groupe que tu cites a la fin et je ne vois d'ailleurs toujours pas l'interet.... (je n'ai commence a les utiliser qu'il y a .. 7 mois (en 25 ans de carriere), et encore parce qu'on m'y oblige dans des revues de code).... Et l'informatqiue est deja suffisammment complexe sans en rajouter....


(tres souvent dans des algos tu manipules des nombres positifs et justement ta condition d'arret c'est que cela devienne negatif...).

Et comme tu dis, en maths, on fait pas de diff...

[Garulfo]

L'argument
« tu utilises un entier qui n'est jamais négatif »
pour dire
« il faut utiliser alors un entier non signé »
peut se retourner en
« tu utilises un entier non signé alors que tu ne dépasses jamais la moitié de la valeur. Pourquoi ne pas utiliser un entier signé ? »

Si tu ne te sers que des entiers entre 1 et 100... tu pourrais même utiliser un byte à la place. Mais bon est-ce vraiment si pertinent? Je ne le pense pas.

[_vince_]

J'ai lance l'exemple des entiers signes / non signes mais je ne pensais pas lancer une polemique. Je pourrais aussi prendre l'exemple des noms de variable qui ne respectent pas ce qu'ils sont sense representer.

Mon idee est de simplement dire que lorsqu'on debug le code de quelqu'un d'autre, on cherche a rentrer dans sa tete et dans sa logique de programmation pour comprendre son intention de depart. C'est pour ca que tous ces petits details sont importants pour celui qui va investiguer les causes des bugs... et qui n'est forcement celui qui a ecrit le code.

[el_slapper]

(.../...)C'est pour ca que tous ces petits details sont importants pour celui qui va investiguer les causes des bugs... et qui n'est forcement celui qui a ecrit le code.

même si c'est celui qui a écrit le code. Quand tu reviens sur un code à toi 2 ans plus tard, tu t'arraches souvent les cheveux, en te disant qu'il y avait moyen de faire tellement mieux.....

EDIT : mise en forme