Discussion :

[TheVandals]

Je ne crois pas que les commentaire font parti d'un code propre, puisque un code propre n'a pas besoin de commentaire.

On peux remplacer les commentaire par des test unitaire ou fonctionnel qui explique le fonctionnement de la methode. Mais la aussi le code doit être propre (ne jamais oublier de refactorisé les tests).

Le problème avec les commentaire c'est qu'on ne sait jamais s'ils spont a jour ou pas. Tandis que les tests eux doivent toujours etre à ajour sinon le build ne fonctionne pas.

Je crois que un code propre doit respecter les principe suivants :
- SRP (single responsability principle)
- DRY (don't repeat yourself)
- OCP (open close principle)
- les variables et methodes bien nommés
- Tests unitaires/fonctionnels pour décrire le comportement avec des nom tres détailler pour chacun des test sous la forme when... expect...
- bien formaté
- utilisé les bon nom de patron dans le nom de la classe (ne pas nommer une class QuelquechoseBuilder lorqu'il s'agis d'une factory)

[koala01]

Je ne crois pas que les commentaire font parti d'un code propre, puisque un code propre n'a pas besoin de commentaire.

On peux remplacer les commentaire par des test unitaire ou fonctionnel qui explique le fonctionnement de la methode. Mais la aussi le code doit être propre (ne jamais oublier de refactorisé les tests).

Le problème avec les commentaire c'est qu'on ne sait jamais s'ils spont a jour ou pas. Tandis que les tests eux doivent toujours etre à ajour sinon le build ne fonctionne pas.

Je crois que un code propre doit respecter les principe suivants :
- SRP (single responsability principle)
- DRY (don't repeat yourself)
- OCP (open close principle)
- les variables et methodes bien nommés
- Tests unitaires/fonctionnels pour décrire le comportement avec des nom tres détailler pour chacun des test sous la forme when... expect...
- bien formaté
- utilisé les bon nom de patron dans le nom de la classe (ne pas nommer une class QuelquechoseBuilder lorqu'il s'agis d'une factory)

Pour ce qui est des commentaires et des TU, as-tu remarqué qu'il y a pres de dix pages pendant lesquelles de nombreuses personnes (dont moi) ont débattu et justifié le fait que les TU et autres documents de conception ne font pas tout et ne peuvent en aucun cas suffire à estimer que le code est suffisant (entre autre dés le moment où le code créé sur base de ces différents documents et tests sort des murs dans lesquels il a été développé)

Bien sur, il ne s'agit pas de dénigrer d'une quelconque manière les différents documents ni les TU...

Mais, encore une fois, de manière générale, il arrive que tu doive reprendre du code pour lequel tu ne dispose ni des documents de conception originels ni des TU pour vérifier que tu n'a pas fait de conneries en modifiant le code.

Le tout sans compter sur le temps perdu que peut représenter le fait de revalider l'ensemble du code suite à une modification mineure, par rapport au fait qu'avec un commentaire utile et cohérent, la modification mineure n'aurait même pas été envisagée

[TheVandals]

Mais, encore une fois, de manière générale, il arrive que tu doive reprendre du code pour lequel tu ne dispose ni des documents de conception originels ni des TU pour vérifier que tu n'a pas fait de conneries en modifiant le code.

Dans ce cas, il suffit de faire d'ajouter des tests avant de faire la modification pour bien comprendre le comportement. Ensuite on peux modifier le code et les test (dans l'ordre que l'on veux selon si on developpe TDD 'Test Driven Development' ou non). De cette manière on s'asure du nouveau comportement de la modif et que le bug ne reviendras pas dans une prochaine version. En plus, les tests serons la pour la prochaine modif.

Le tout sans compter sur le temps perdu que peut représenter le fait de revalider l'ensemble du code suite à une modification mineure, par rapport au fait qu'avec un commentaire utile et cohérent, la modification mineure n'aurait même pas été envisagée

Le temps d'execution de la totalité ou d'une partie des tests n'est pas tellement long. Il faut juste se donner des mecanismes pour produire des builds rapidement en executant qu'une partie des tests. Et avoir un build de nuit ou de weekend qui execute tous les tests pour s'assuré que rien n'a été brisé par une modif.

La différence entre developper avec ou sans les tests c'est comme payer comptant ou au credit. Comptant : on paye une fois et c'est fini. Crédit : sa ne parait pas tout de suite mais au final sa reviens avec les interets.

[TheVandals]

Et pour les modifications rapide, il faut être prudent et ne pas tomber dans le piege du squirrel burger :

[koala01]

Tu nous emmène à relancer un débat qui a déjà pris plus de dix pages sur cette discussion...

Je te proposerais réellement de relire ces pages.

Car, ce qu'il faut absolument prendre en compte lorsque l'on parle de manière générale, c'est que tu n'es pas forcément bien au chaud dans un des bureaux de la société qui a conçu l'appllication ou la bibliothèque à l'origine, qu'une fois que l'application ou la bibliothèque à été validée à coups de TU, il y a malgré tout encore toute une série de raisons qui font que les tests d'intégration ou autres peuvent foirer, et que, de toutes manières.

De plus la granularité des tests unitaires à effectuer fait que pour valider une modification dans une seule fonction, tu peux être amené à devoir effectuer une batterie de tests qui peut aller d'un seul et unique test à une centaine.

En outre, le build lui-même peut prendre parfois plusieurs heures (quand il ne doit pas tourner toute la nuit)... Ca mène à un prix par modification pour le moins élevé, ne serait-ce qu'en temps de compilation.

Et, encore une fois, il ne s'agit absolument pas de dénigrer les TU d'une quelconque manière, mais il s'agit de se rendre compte qu'ils ne peuvent "simplement" pas être la solution miracle à tous les maux, pour toutes les raisons exposées dans les pages précédentes, et qu'il est même possible de se trouver dans une situation dans laquelle il t'est purement et simplement impossible d'y avoir recours, du moins, dans un délais raisonnable.

En effet cela nécessite de disposer des specs et autres documents de conception qui ne sont pas forcément disponibles (ou parce que le temps qui serait nécessaire pour arriver à te familiariser suffisamment avec l'ensemble du projet est sans commune mesure avec l'urgence d'apporter la solution ou avec le temps que l'on peut raisonnablement juger nécessaire à la modification à apporter).

[hegros]

Pas très sympa...
Je note que tu es capable de lancer un menhir, comme de comprendre ce que fait un code sans commentaire, du premier coup d'oeil.

Quand ce n'est pas écrit et découpé comme un sale cochon une fonction oue une classe sur 34567 lignes alors oui on devine assez rapidemment les intentions de code.

L'humain moyen, lui, ne peut gérer qu'un petit nombre d'informations à la fois.

Ma réponse ci-dessus avec un découpage de cochon et se retrouver avec des modules de 9876543210 lignes de code source

Et si le code permet de savoir "comment", un commentaire qui explique le "pourquoi" est rarement inutile.

Il y a plutôt de rare cas où ils s'avérent très utiles. Mais dans le soupçon du doute donne nous ton meilleur exemple de commentaire dont on ne pourrait pas se passer.

Mon intervention précédente ne voulait pas dire que les commentaires sont inutiles,mais qu'un bon commentaire n'est pas évident à rédiger.

la dessus nous sommes d'accord

[Furikawari]

Mouais...
Plus aucune personnalité reconnue du monde de la programmation ne dit de programmer avec la notation hongroise, au contraire, il faut l'éviter comme la peste.
Pourquoi devoir renommer une variable si on a changé son type (passage d'une liste à un vecteur parce que plus adapté) ?

Et les commentaires, c'est la même chose, trop de commentaires tuent le commentaire. Le commentaire doit être présent de manière parcimonieuse pour qu'il ait un impact. Autrement, la fonction doit pouvoir se suffire à elle-même.

(je prends ce fil en route et comme je uis bien élevé je commence du début, du coup je réponds à une des premières pages )

Faux, faux et archi faux !!!

Le problème de la notation hongroise est que celle que la majorité des gens connaissent (celles promues dans les ouvrages de programmation système windows) n'est pas la notation hongroise telle qu'lle avait été conçue initialement.
Effectivement, utiliser cette notation pour spécifier le type de la variable est quelque peu aberrant. Mais la notation hongroise originale n'avait rien à voir avec le typage, elle portait sur la fonction même de la variable. J'avais lu une anecdote disant qu'elle avait été créé initialement par les développeurs d'excel à cause des changements de coordonnées, la notation permettait de spécifier quel type de coordonnées contenait la variable, et non le type de la variable elle même.
Y'a eu plusieurs bloggers relatant cette histoire, j'avoue que j'ai la flemme de chercher et je laisse les plus motivés d'entre vous retrouver les liens.

Edit: En fait Souviron avait très bien répondu à ce problème avec les liens auquel je pensais

[Bakura]

Dites... ça n'a pas grand chose à voir (enfin si, un peu) mais... est-ce que vous vous êtes déjà arrêté deux ou trois minutes devant du code (que ça soit le votre ou celui d'un autre, mais généralement le vôtre car sa correspond à votre propre convention du code propre et "joli"), et vous dire : "putain, ça c'est du code qui a la classe !".

Parfois ça m'inquiète un peu de m'extasier devant certains codes . Sinon pour apporter ma pierre, je pense qu'on a tous une vision différente de ce qu'est un code propre, et puis notre subjectivité envers la "beauté" que nous inspire le code y est pour beaucoup aussi.

Mais ocmme beaucoup, indentations, noms de variables correctes, séparation sur plusieurs lignes, fonctions qui font pas 30000 lignes... Je suis ne première année dans une école d'ingé d'info, beaucoup de gens ont commencé la prog cette année, et quand je vois leur code, j'ai peur .

[el_slapper]

Dites... ça n'a pas grand chose à voir (enfin si, un peu) mais... est-ce que vous vous êtes déjà arrêté deux ou trois minutes devant du code (que ça soit le votre ou celui d'un autre, mais généralement le vôtre car sa correspond à votre propre convention du code propre et "joli"), et vous dire : "putain, ça c'est du code qui a la classe !".

Parfois ça m'inquiète un peu de m'extasier devant certains codes . Sinon pour apporter ma pierre, je pense qu'on a tous une vision différente de ce qu'est un code propre, et puis notre subjectivité envers la "beauté" que nous inspire le code y est pour beaucoup aussi.

Mais ocmme beaucoup, indentations, noms de variables correctes, séparation sur plusieurs lignes, fonctions qui font pas 30000 lignes... Je suis ne première année dans une école d'ingé d'info, beaucoup de gens ont commencé la prog cette année, et quand je vois leur code, j'ai peur .

T'inquiètes, y'a aussi des gens qui ont 30 ans de maison et qui commettent des crimes contre la propreté codistique.....

[Merfolk]

Yo,
je ne sais pas si ça a déjà été dit comme réflexion :


je pense qu'il est difficile de définir un code propre
par contre on peut beaucoup plus facilement définir un code sale.

il faut donc définir un code sale...et un code propre c'est l'inverse


ex code sale :
- pas indenté (sisi ça existe des gens qui n'indentent pas, et ils sont payés plus que vous )
- noms de variables pas clairs
- 0 commentaire
- des pavés de code en commentaire
- gros pavés de codes
- 50 ifs imbriqués ...
- mauvaise conception de classe etc.
- 6 copié collé dans le même fichier
- paths en dur
- aucune gestion de retour de fonction etc
- la compliquite de code (tout diviser en 10 000 classes & fichiers et faire du jeu de piste, ce n'est pas génial non plus)

[Bakura]

- la compliquite de code (tout diviser en 10 000 classes & fichiers et faire du jeu de piste, ce n'est pas génial non plus)

Ca c'est particulièrement chiant sur les codes exemples de certaines bibliothèques. Ils utilisent des objets définis dans un fichier, dans ce même fichier d'autres classes définies dans d'autres fichiers... pour enfin trouver l'utilisation de la feature dont le tuto parle .

[Furikawari]

Franchement je comprends pas ce débat. Il n'y a pas de critère quantitatif (fonctions pas trop longues, ni trop ni trop peu de classes (super critère de design soit dit en passant... comme si le nombre de classes dans l'absolu était un critère), juste ce qu'il faut en commentaires, etc.), et de toute façon dans bien des cas on trouvera des exceptions justifiées. Et c'est probablement pour ça que 80% de ce fil concernent les commentaires...

[Nebulix]

Quand ce n'est pas écrit et découpé comme un sale cochon une fonction oue une classe sur 34567 lignes alors oui on devine assez rapidemment les intentions de code.




Ma réponse ci-dessus avec un découpage de cochon et se retrouver avec des modules de 9876543210 lignes de code source

Ma remarque
L'humain moyen, lui, ne peut gérer qu'un petit nombre d'informations à la fois.
était suivie de la précision
En informatique quelques dizaines de lignes de code.
qui a disparu lors de l'édition de la citation.
Ce procédé se passe effectivement de commentaire...

[hegros]

Ma remarque
L'humain moyen, lui, ne peut gérer qu'un petit nombre d'informations à la fois.
était suivie de la précision
En informatique quelques dizaines de lignes de code.
qui a disparu lors de l'édition de la citation.
Ce procédé se passe effectivement de commentaire...

Encore un autre de mauvaise foi qui pense avoir la science infuse.

Tu es du genre quelques dizaines de lignes de code et du tartinage de commentaire effectivement sans commentaire...

[Immobilis]

Plus ou moins la 24 eme minute de cette vidéo: http://video.google.fr/videoplay?doc...&q=linux&hl=fr

A+

[hegros]

Plus ou moins la 24 eme minute de cette vidéo: http://video.google.fr/videoplay?doc...&q=linux&hl=fr

A+

24minute : 'si le code est bon vous pouvez le lire sans commentaire'

[Félix Guillemot]

Bonjour à tous, amis et confrères développeurs,

Je prends ce débat en cours de route, et il m'intéresse beaucoup, donc je m'exprime à mon tour.

Du beau code ? Au sens littéral, on pourrait penser à une certaine forme d'esthétisme, et pourquoi pas après tout, la programmation est un art n’est-ce pas ? Il n’y bien que les crétins qui pensent que le développeur est l’ouvrier en bleu de travail de l’informatique et qui sont sortis de leur école d’ingé avec la seule idée en tête d’être chef de projet ou les services achats qui achètent le code au kilo en Inde ou au Maroc en croyant gagner de l’argent. Je déteste ces gens qui ont des euros à la place des yeux et qui sont tellement éloignés de notre boulot, arg…c’est plus fort que moi, je ne peux pas m’en empêcher…
Ça fait 25 ans que je programme, je me suis passionné pour cette discipline à 11 ans et je n’en démords pas, je trouve ça génial, créatif, nourrissant intellectuellement. Ok, je m’égard un tantinet mais oui, je trouve qu’il y a du code moche et du code beau, et en général, le code moche ou brouillon est l’expression un raisonnement à son image.
Et là, je précise, il ne s’agit plus d’esthétisme…
Celui qui a fait de la prestation de maintenance et qui a dû corriger du code écrit avec des moufles sait de quoi je parle…
On ne fait pas du beau code pour exposer au grand palais en tant qu’artiste peintre, non, on fait du beau code parce que la qualité de ce code garantit un « développement informatique durable ».
Et oui, je suis du genre à régler la longueur des tabulations dans l’éditeur pour bien indenter, à me forcer à écrire IntToStr et non inttostr.
Je suis de ceux qui pensent qu’il faut coder les commentaires et non l’inverse parce que « Ce qui se conçoit bien s’énonce clairement et les mots pour le dire viennent aisément »Boileau, L’art poétique, Chant I.

Je vous invite à regarder la vidéo sur developpez.com :

http://delphi.developpez.tv/delphi2008/#session2

Et à lire la critique de Laurent Dardenne :

http://conception.developpez.com/liv...L9782746222465

Bon code à tous !

[Immobilis]

la programmation est un art n’est-ce pas ?

Heu, on peut le voir comme ça, mais c'est aussi une industrie. En production, les développements doivent être industrialisés pour respecter des normes et un niveau de qualité (tests, documentation, ...).

Il n’y bien que les crétins qui pensent que le développeur est l’ouvrier en bleu de travail de l’informatique et qui sont sortis de leur école d’ingé avec la seule idée en tête d’être chef de projet ou les services achats qui achètent le code au kilo en Inde ou au Maroc en croyant gagner de l’argent.

C'est un peu caricatural. Tu peux dire que tu n'es pas d'accord, mais pas que les autres sont des crétins...

A+

[chaplin]

Yo,
je ne sais pas si ça a déjà été dit comme réflexion :


je pense qu'il est difficile de définir un code propre
par contre on peut beaucoup plus facilement définir un code sale.

il faut donc définir un code sale...et un code propre c'est l'inverse


ex code sale :
- pas indenté (sisi ça existe des gens qui n'indentent pas, et ils sont payés plus que vous )
- noms de variables pas clairs
- 0 commentaire
- des pavés de code en commentaire
- gros pavés de codes
- 50 ifs imbriqués ...
- mauvaise conception de classe etc.
- 6 copié collé dans le même fichier
- paths en dur
- aucune gestion de retour de fonction etc
- la compliquite de code (tout diviser en 10 000 classes & fichiers et faire du jeu de piste, ce n'est pas génial non plus)

Anecdote: un stagiaire m'avait demandé de lui porté secours sur un programme dans un langage (qui m'était étrangé). Je lui avais suggéré d'utiliser le(s) stabylo(s), il avait relevé 8-9 niveaux d'imbrications de if. Ses profs lui avaient répondu qu'on ne programme plus ainsi, plus précisement que c'était une ancienne pratique.

Le copier coller de code sans compter des bouts de code mis en commentaire, c'est pénible.

[Félix Guillemot]

C'est un peu caricatural. Tu peux dire que tu n'es pas d'accord, mais pas que les autres sont des crétins...

Ce n'est pas du tout "caricatural" malheureusement, c'est la triste réalité du marché de la prestation informatique que je connais par coeur : les services achat ont des grilles et le développeur est consigné dans une case en bas de l'échelle, en dessous du chef de projet. Chef de projet c'est un métier différent, mais pas plus complexe que celui du développeur. De même qu'on trouve "louche" qu'un type soit développeur au delà d'un certain âge, comme si c'était forcément parcequ'il n'a pas "su" évoluer et non par choix !
L'acheteur a donc une idée préconçue du développeur et tire les prix vers le bas. au final, les SSII seront obligées de fournir des ressources aux CV maquillés ou en correspondance avec les prix et la prestation sera en rapport bien sûr, ce qui ne fera que conforter l'avis du directeur informatique et du service achat.
Je trouve que tout cela est crétin et générateur de gâchis. Ma phase est peut être un peu rapidement tournée, mais je maintiens mon idée de fond et pense qu'il faut revaloriser le métier de développeur. Le code "propre" peut bien sûr y contribuer.
Combien ai-ju vu débarquer de jeunes coqs condescendants pensant que "chef de projet" était le poste "convenable" du service informatique.
C'est comme ça qu'on se retrouve avec des chefs de projets incapables de faire une revue de code puisqu'ils n'ont eux même aucun savoir-faire et que l'on retrouve des monceaux de code "sale".
Je pense qu'un chef de projet en développement doit connaître le métier de développeur, c'est un minimum...
Pour finir, je pense qu'il faut qu'on arrête d'OutSourcer à tout va pensant que le code s'achète au kilo parcequ'il est fait par des crétins, et c'est malheureusement ce que pensent beaucoup de... allez j'arrête avec ce mot, mon but n'est pas de faire de la provoc, mais tant mieux si mes propos font réagir...
Si on ne peut pas défendre le développeur sur developpez.com, où le peut-on ?