Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Discussion :
Pour avoir un code propre il faut le bon éditeur qui va avec, qui permet de faciliter les indentations, les tabulations, les différenciations des couleurs, etc...
Ce qui facilite énormément les corrections et la lecture du code. En plus il ne faut pas oublier les commentaires, qui sont indispensables pour se remémorer une partie du code ou pour faciliter la compréhension d'un autre lecteur.
Il est vrai que le choix des outils apporte une facilité certaine pour arriver à un code "bien présenté"... Mais ce n'est pas *forcément* indispensable...Envoyé par sonorc
si tu prend l'habitude de présenter ton code correctement, tu fera de toutes manières en sorte qu'il le soit, même si tu viens à utiliser un outil qui n'est pas "forcément" prévu pour te faciliter cette tâche
De plus, la belle présentation du code n'est qu'un des facteurs qui font que l'on puisse parler de code propre
Je sais que l'on dit que le bon ouvrier n'a que de bons outils, mais, même avec de bons outils, un mauvais ouvrier ne fera pas *forcément* du bon boulot
mmmh, les développeurs Indiens sont tout aussi forts que nous, et cracher dessus ne me parait ni respectueux ni productif. Mis dans des conditions équivalentes, ils font du boulot équivalent.
Par contre, croire qu'il suffit de leur envoyer une vague spec mal traduite pour qu'il produisent la même qualité qu'un developpeur local, qui sera à même de poser des questions de vive voix sur toutes les subtilités cachées de la spec en question, c'est un poil naïf, il me semble. Le PDG de mon ancienne boite(une très grosse SSII, implantée à Annecy, merci de ne pas deviner en toutes lettres) estimait au doigt mouillé qu'un bon outsourcing triplait les couts de spécifications(et les délais allaient avec). Ben oui : quand on est obligé de répondre à l'avance à toutes les questions, c'est beaucoup plus long.....
Totalement d'accord avec ça, je n'ai pas bossé directement avec l'Inde, mais des collègues ayant eu affaire à leur production m'ont tenu exactement le même genre de discours. Le nom de ma SSII commencent par les 2 même lettres
Attention, je pense que vous vous méprenez sur mes propos, en les relisant, je veux bien reconnaître qu'ils peuvent prêter à confusion, bien que ça va quand même loin de me prêter de telles pensées...
je n'ai JAMAIS dit que les développeurs indiens étaient des crétins ou qu'ils étaient moins fort que nous. J'ai notamment collaboré avec Shiv Kumar dans l'équipe Indy et lus des tutoriaux d'experts Indiens pour savoir qu'ils sont très bons, ou du moins pas moins bons que nous. ça serait du pur racisme de ma part et c'est hors sujet !
Ce que j'ai voulu dire, c'est que le développeur, d'où qu'ils vienne est considéré comme une petite main, c'est l'ouvrier en bleu de travail de l'informatique.
La France reste encore formatée d'une façon archaîque, et dans les services informatiques des grands comptes, le développeur est en bas de l'échelle, le moins payé, et voila. Ceux qui ne soint pas d'accord n'ont qu'à aller se rendre compte par eux même, sur le terrain. En Angleterre, c'est différent, on peut comprendre qu'un expert développeur sur une techno coûte 1000€/J parce qu'il travaille 3 fois plus vite qu'un non expert et que le travail est mieux fait, plus durable, et donc moins couteux au final.
Pour en revenir à mon propos de départ, on pense dans les entreprises que le développeur est un petit pisseur de lignes, et on n'a pas d'estime pour lui, donc quitte à payer des développeurs, autant les payer 10 fois moins cher puisque de toute façon leur travail n'est pas stratégique pour l'entreprise.
Comme vous l'expliquez justement, les coûts sont déplacés dans l'encadrement et la rédaction de spécifications de plus en plus détaillées pour remplacer la proximité et la réflexion liée au fonctionnel que doit avoir le développeur.
Mais cela, c'est valable même sans parler de OutSourcing, on finit par rédiger des specs techniques où il n'y a plus qu'à faire du copier-coller. La requête SQL est dans les specs !
La stratégie des développements informatiques et leur financement est dirigée par des gens dont ce n'est pas le métier, qui ne savent pas ce que c'est que du code propre ou sale pour en revenir au débat d'origine.
Tout cela doit évoluer et bouger, c'est pour ça que j'ai écrit un livre qui traite de ce sujet et m'exprime dans ces forums.
Je crois qu'on va se comprendre.....
ça me rapelle un projet pharaonique(une migration de COBOL vers SAP), ou j'avais été appelé pour des tâches d'homologation, et ou ils avaient fait des choix techniques aberrants, avec 12 programmeurs, 3 homologateurs, plein d'experts, un DP, un CP, un CP adoint et une assistante d'encadrement.
Quand j'ai vu les specs, je me suis dit "en 6-8 mois, tout seul, en COBOL, je le fait, leur projet......faut juste garder les experts et me remplacer en tant qu'homologateur". Puis j'ai été "redeployé" ailleurs, pour mon plus grand bien, et le projet s'est planté.
J'ai déjà vu ça, en 2001, ça n'est pas récent, comme tendance. La spec, c'était "mettre telle valeur dans telle autre". La seule difficulté, c'est que je ne connaissais pas Cobol, à l'époque.
Exact. sur la même mission de 2001, tout frais sorti d'une formation industrielle, j'ai été sidéré de voir que les estimations de charges ne prenaient pas en compte le fait que nous(il n'y avait que des débutants, question de dispo) allions progresser, et donc faire de mieux en mieux..... Naiveté totale de ma part : un expert aurait eu droit au même nombre de jours
Mais c'est aussi un code que l'on aurait plaisir à faire évoluer en le respectant et en conservant son ame. Un code où la cohérence serait forte et où l'information ne serait pas duppliqué.
J'ai lu tous les posts mais comme il y en as pas mal , je me suis peutêtre un peu perdu dans l'amas
j'ai l'impression en vous lisant que pour avoir un code propre , il faut faire de l'anti optimisation ...
etre clair dans son code pour la plupart d'entre vous semblerai dire :
éviter de répéter le même code plusieurs fois dans le programme.
faire des procédures les plus courtes possibles quitte a découper une "action" en plusieurs sous actions dans des procédures diffèrentes.
le point sur lequel je serai assez d'accord avec vous mais auquel j'ai un mal de chien a me tenir, c'est les commentaires.
pour avoir un code parfaitement optimisé, il faudrai n'avoir en vb par exemple que ces procédures ci :
le main sub ou les form load pour initier le programme et les forms
ensuite uniquement une procédure par évenement.
toute écriture de procédure "de confort" devrait être totalement bannie.
mais voila , une mise a jour d'une fonction , impliquerai immédiatement des heures et des heures voir des jours et plus encore pour la plus petite modification alors que si on as 50 fois la même routine dans le programme et qu'on la remplace par une procédure , on ne devra modifier que le code de cette procédure la et rien d'autre.
il est évident que "ma" version de codage n'aurai pas du tout votre assentiment, mais ne nous demandons plus pourquoi par exemple , les programmes quenous avons écrit il y a 10 ans sur des P3 , tourne tjs sur des p3 aussi vite que nos dernières versions le font sur des dual core voir des quadracore ...
je travaille dans un pays ou il n est pas déja absolument sur de decouvrir que le pc sur lequel mon soft tournera sera au moins un p3, si j' applique les specifications normales d'un code propre et facile a maintenir ( petite procédure spécialisée dans une action comptant le moins de ligne possible) je peut vous garantir que la plus part de mes soft serai inutilisables.
je me prépare a créer un soft pour une entreprise , qui va m'obliger à faire ce que j'ai dit plus haut :pas de procédure inutile que les procédures d'initialisations et les procédures evenements. je cherche même des techniques permettant de prémacher certaine opérations sur un autre pc de facon a ne plus avoir qu'à importer par exemple les modifications d'une base de données sous forme d'un fichier qui ne monopoliserai pas celui ou mon soft tournera une seule seconde de trop (son domaine est la sécurité de lieu divers). J'ai déja réalisé un certain nombre de test et je peut dire que par exemple dans le maximum de cas possible je devrai eviter toutes boucles. preferant répéter autant de fois que nécessaires le code en modifiant ce que la boucle aurai modifié. un truc de ouf , mais c'est le prix a payé pour ne pas avoir a modifier le parc ordinateur de la société.
le cout supplémentaire en heures de travail , est compensé par le cout enorme des ordinateurs dans mon pays. Et le fait que si plus tard mon soft doit tourner sur des pc plus puissant, il n'en sera que plus rapide encore.
(cet effort d'optimisation est exigé pour gèrer une possible mais très peu probable montée en charges maximal du système d'alerte).
Mais de toutes façon il s' agit d'un strict respect des recommandations de la "bible" du programmeur visual studio :"msdn"
alors comment gèrer ce type de code et l'aspect propre et facile a maintenir que vous pronez ?
Je comprend ton besoin d'assurer des performances correctes sur des configurations que l'on qualifie facilement de vieilles et de faibles dans nos contrées...
Cependant, je ne suis pas intimement persuadé que le fait de dérouler des boucles (si tant est qu'il soit possible de le faire) ou d'éviter deux appels de fonctions (même si, en réalité, tu en arrive à quatre ou dix fonctions plus basiques) soient réellement de nature à améliorer très fortement les performances...
Comprenons nous, je ne dis pas que c'est toujours inutile mais seulement que c'est très rarement utile
Il ne faut pas oublier que des langages aussi anciens que COBOL fournissent déjà la possibilité de créer des procédures et des boucles...
C'est à dire que ces facilités existaient déjà lorsque les ordinateurs dont on disposait étaient encore très loin d'avoir les capacité d'un P3, et que cela n'empêchait pas d'avoir des applications "relativement rapides" en tenant compte du matériel sur lequel elles fonctionnaient
(Pense que, pour Appolo 11, l'ensemble des "super ordinateurs" de la NASA n'avait la puissance que d'un ordinateur portable actuel
Bien sur, il ne faut pas se leurrer: Au niveau du processeur une boucle fonctionne fatalement sur une comparaison et un jump, l'appel d'une fonction doit commencer par placer des valeurs sur la pile, et cela lui demande, effectivement, quelques tours d'horloges de le faire.
Mais, avant de décider de se passer de ces facilités, il me semble important d'au moins s'assurer que le gain de performances obtenu à le faire en vaut réellement la peine
Et cette certitude ne peut, à mon sens, n'être acquise qu'en effectuant de mesures des deux possibilités envisagées
En effet, avant que le gain ne soit seulement perceptible par l'homme (disons d'un dixième de seconde), il faut épargner de nombreux cycles d'horloge d'un processeur... Même si celui-ci ne tourne "qu'à" 600Mhz
Par contre, j'estime que, si un test permet de n'entrer dans une boucle que 9 fois sur dix (par rapport à une version sans test), il est souvent plus intéressant de commencer par comparer les performances obtenues avec ces deux versions que de mettre en oeuvre les solutions dont tu parles
En un mot, je dirais que, avant de commencer à vouloir "grappiller" quelques cycles d'horloges en déroulant les boucles ou en supprimant une fonction qui serait appelée à de nombreux endroits, il est surement préférable de s'intéresser à toutes les optimisations que l'on peut apporter à l'algorithme
Un simple exemple: tu gagnera beaucoup plus en performances en utilisant un algorithme dichotomique (si tu peux l'utiliser) plutôt qu'un "simple" algorithme itératif, et tu gagnera d'autant plus en performances que le nombre de données à traiter est important
Bien sur, je ne parle ici que dans le cas général, et il est tout à fait possible de trouver des cas particuliers dans lesquels ceci ne s'appliquerait pas... Mais ces cas particuliers restent malgré tout l'exception
perso en étant un peu intégriste sur le sujet se serait:
pour la mise en forme:
- format unix
- pas plus de 80 caractères par lignes.
- pas plus de 2000 lignes par fichier.
- pas de tabulation
- pas d'espaces inutiles
- un indentation correcte
--> Ces paramètres réunis rendent assez indépendant de l'éditeur utilisé. (a condition de le paramétrer pour qu'il n'insère pas de tabulation inutile) et font que l'impression éventuelle du fichier
passe correctement à l'imprimante.
viens ensuite le contenu:
- Une en tête de fichier qui décrit globalement ce que contiens le fichier.
- Un ratio code / commentaire d'environ 50% (sans compter l'en tête)
- Les commentaires doivent être explicites
- le code doit être facilement compréhensible (nommage des variable, algorithmique simple des fonctions)
----> c'est a dire qu'ils décrivent fonctionnellement ce qui se passe et qu'ils ne paraphrasent pas le code.
malheureusement certains ne les suivent pas
Sur ces premiers critères, je suis globalement d'accord
Sur celui-ci par contre, je dirais que cela dépend encore énormément du langage...- pas d'espaces inutiles
En Cobol, par exemple, une mise en forme très courue est de créer une sorte de tableau ce qui donnerait quelque chose proche de
(note que, justement, en COBOL, nous sommes effectivement légalement limité à 80 caractères
Code COBOL : Sélectionner tout - Visualiser dans une fenêtre à part
2
3
4
5
6
701 personne. 02 nom PIC X(20) VALUE "DUPONT". 02 prenom PIC X(20) VALUE "Martin". 02 naissance. 03 annee PIC 9999 VALUE 1954. 03 mois PIC 99 VALUE 02. 03 jour PIC 99 VALUE 07.
Evidemment, la "verbosité" de Cobol incite surement à préférer ce genre de "mise en page"
Là dessus, je suis on ne peut plus d'accord- un indentation correcte
C'était effectivement le cas avec les imprimante de type "matricielles" (ou à tulipes), et les polices de caractères de chasse fixe...--> Ces paramètres réunis rendent assez indépendant de l'éditeur utilisé. (a condition de le paramétrer pour qu'il n'insère pas de tabulation inutile) et font que l'impression éventuelle du fichier
passe correctement à l'imprimante.
Maintenant, il est possible, du fait de la multiplication des polices et des tailles de caractères (ainsi que du fait de l'élargissement des écrans) d'être "plus coulent" dans la limite des 80 caractères (du moins, tant que tu ne code pas du Cobol
A condition que le langage l'autorise...- Une en tête de fichier qui décrit globalement ce que contiens le fichier.
C'est le cas de C et de C++, mais pas de langages comme C# ou java...
D'ici à ce que tu en vienne à décréter que, comme ce principe ne peut pas être respecté en C# ou en Java, il est impossible d'écrire un code propre dans ces langages, il n'y a qu'un pas... qui risque d'en énerver plus d'un
Bien que je fasse partie de ceux qui estiment qu'un code doit être commenté, je trouve ce ratio tout à fait excessif (imagine, cela t'amène à écrire une ligne de commentaire par ligne de code- Un ratio code / commentaire d'environ 50% (sans compter l'en tête))
Mais bon, je suis de ceux qui pensent que les commentaires doivent être suffisants (pour permettre de comprendre ce que le code n'explicite peut être pas) et minimaux (qui évitent de commenter quelque chose qui n'a pas lieu d'être), et qui sont tout à fait hostiles à l'idée d'imposer un ratio quelconque...
La raison principale de cette hostilité tient dans le fait que, le ratio risque soit d'inciter la personne à rajouter des commentaires inutiles, soit de l'inciter, ce qui serait encore pis, à restreindre ses commentaires, quitte à ne pas commenter quelque chose d'important, pour ne pas le dépasser...
Là dessus, par contre, je suis (aussi) tout à fait d'accord- Les commentaires doivent être explicites
- le code doit être facilement compréhensible (nommage des variable, algorithmique simple des fonctions)
----> c'est a dire qu'ils décrivent fonctionnellement ce qui se passe et qu'ils ne paraphrasent pas le code.
en fait je pense pour ma part que la raison que nous avions il y a 30 ans d utiliser ces fabuleuses boucles etait que nous avions 2 contraintes qui etait en totale inversion.
la première de ces contraintes etait certe la lenteur de nos ordi
la seconde etait la petitesse de nos mémoires
donc du coup on devait sans cesse penser a gèrer les 2 cotés du problème.
si on codait sans elle, nos fichiers prenait trop de place en mémoires et du coup le programme ne tenais pas dedans et on avait des out of mermory sans cesse
si on les utilisait on avait une certaine lenteur mais on pouvait mettre plus de chose dans le même programme
donc du coup on as généraliser un peu trop leur usage
et une fois une habitude prise ... dur dur de revenir en arrière.
quand a l'importance du gain fait en utilisant la répétition des lignes plutot que l'utilisation du for next , fait le test rien que sur de petite boucle avec juste par exemple le remplissage d'un tableau de données provenant d'un recordset en vb6
tu sera surement etonné de voir la diférence
au départ j'avait cédé sans trop m'en rendre compte a la mode de la boucle
mais après quelques test pour "m'amuser" , j'ai tellement été surpris que j'ai commencé a m'obliger a ne plus les utiliser dès que possible
un cycle ce n'est rien même sur un tres vieux pc, mais si on as des fonctions qui reviennent régulièrement et ben ca fait vite pas mal de cycles inutile et donc pas mal de temps perdu par l'ordinateur a juste implémenter une variable de controle
par contre un cas ou je n'ai pas trouvé de solution de substitution qui me parraisse convaincant c' est si la boucle est avec une des 2 variables (start ou end) qui ne soit pas connues au moment de la création du programme.
la rien a faire sauf a implanter un if goto entre chaque "interieur" de la boucle remplacee
mais je n aime pas trop cette solution
quand je parle d'espace inutile ce sont ceux que l'on peux trouver en bout de ligne ou sur des lignes vides pas ceux qui servent a aligner certaines parties du code ( je les considère comme faisant partie plus ou moins de l'indentation même si ce n'est pas exact).Sur ces premiers critères, je suis globalement d'accord
Sur celui-ci par contre, je dirais que cela dépend encore énormément du langage...
En Cobol, par exemple, une mise en forme très courue est de créer une sorte de tableau ce qui donnerait quelque chose proche de
(note que, justement, en COBOL, nous sommes effectivement légalement limité à 80 caractères
Code COBOL : Sélectionner tout - Visualiser dans une fenêtre à part
2
3
4
5
6
701 personne. 02 nom PIC X(20) VALUE "DUPONT". 02 prenom PIC X(20) VALUE "Martin". 02 naissance. 03 annee PIC 9999 VALUE 1954. 03 mois PIC 99 VALUE 02. 03 jour PIC 99 VALUE 07.
Evidemment, la "verbosité" de Cobol incite surement à préférer ce genre de "mise en page"
Là dessus, je suis on ne peut plus d'accord
oui, mais devoir imprimer des pattes de mouche illisible parce que les lignes de codes font entre 300 et 500 caractères ce n'est pas très glop.C'était effectivement le cas avec les imprimante de type "matricielles" (ou à tulipes), et les polices de caractères de chasse fixe...
Maintenant, il est possible, du fait de la multiplication des polices et des tailles de caractères (ainsi que du fait de l'élargissement des écrans) d'être "plus coulent" dans la limite des 80 caractères (du moins, tant que tu ne code pas du Cobol
et te retrouver quand tu imprime a devoir décoder les lignes parce que la mise ne forme te les aura coupé ce n'est pas glop non plus.
et la personne qui lira ton code n'a pas forcement d'écran 16/9 en full hd
Quand je parle d'en-tête du fichier dans ce cas là il s'agit de la partie haute et pas du header (.h, .ads, ...). je pense que c'est aussi possible en java et en c# en perl, ...
A condition que le langage l'autorise...
C'est le cas de C et de C++, mais pas de langages comme C# ou java...
D'ici à ce que tu en vienne à décréter que, comme ce principe ne peut pas être respecté en C# ou en Java, il est impossible d'écrire un code propre dans ces langages, il n'y a qu'un pas... qui risque d'en énerver plus d'un
A peu près, effectivement certaines lignes (genre affectation de variables n'ont pas besoin de trop de commentaires), mais expliquer ce que fait un algo dans son ensemble cela ne prend pas 2 lignes. ceci dit c'est une contrainte que je m'impose personnellement et que j'ai hérité de mon passage en embarqué, mes collègues sont un peu plus avare (en général ils sont aux alentours de 30%).Bien que je fasse partie de ceux qui estiment qu'un code doit être commenté, je trouve ce ratio tout à fait excessif (imagine, cela t'amène à écrire une ligne de commentaire par ligne de code
Ce n'est pas imposer c'est une recommandation. Après cela dépend de l'équipe de dev que tu as en face et de ses habitudes, parfois il faut imposer un minimum car j'en connais certains qui sont assez avares de commentaires et qui ne font pas un code lisible pour autant.Mais bon, je suis de ceux qui pensent que les commentaires doivent être suffisants (pour permettre de comprendre ce que le code n'explicite peut être pas) et minimaux (qui évitent de commenter quelque chose qui n'a pas lieu d'être), et qui sont tout à fait hostiles à l'idée d'imposer un ratio quelconque...
la, il faut se reposer sur le sérieux des gens. ceci dit comme un partie de la doc est généré via doxigen/javadoc,... on vois vite si les commentaires visible via ces outils ne sont pas sérieux, insuffisant ou n'explicite pas assez bien ce que fait une méthode/ un objetLa raison principale de cette hostilité tient dans le fait que, le ratio risque soit d'inciter la personne à rajouter des commentaires inutiles, soit de l'inciter, ce qui serait encore pis, à restreindre ses commentaires, quitte à ne pas commenter quelque chose d'important, pour ne pas le dépasser...
C'est surtout parce que le test (et une boucle n'est jamais qu'un saut effectué en fonction du résultat d'un test
Je ne connais malheureusement absolument pas VB6...quand a l'importance du gain fait en utilisant la répétition des lignes plutot que l'utilisation du for next , fait le test rien que sur de petite boucle avec juste par exemple le remplissage d'un tableau de données provenant d'un recordset en vb6
tu sera surement etonné de voir la diférence
au départ j'avait cédé sans trop m'en rendre compte a la mode de la boucle
mais après quelques test pour "m'amuser" , j'ai tellement été surpris que j'ai commencé a m'obliger a ne plus les utiliser dès que possible
Mais je suis loin de n'en avoir entendu que du bien
Au fait, es tu sur que ce n'est pas, simplement, parce que ton PC est monté en charge entre le moment du test avec la boucle "normale" et celui de la boucle déroulée...
Es-tu, par ailleurs, sur d'avoir testé un code tout à fait identique, à l'exception du déroulement de la boucle
Parce que, à ma connaissance, il existe une commande processeur pour gérer les boucles itératives, qui ne prend que quelques cycles d'horloge à l'exécution.
Je ne dis donc pas qu'une boucle nécessitant 40 000 000 d'itérations ne sera pas (dans le cadre d'un P3) près une seconde plus lente que la boucle déroulée, mais la différence ne devrait normalement pas être plus importante.
Et je présumes que tu ne te sera pas amusé à dérouler une boucle de 40.000.000 d'itérations
C'est pourquoi je préconise de veiller en priorité à optimiser l'algorithme...un cycle ce n'est rien même sur un tres vieux pc, mais si on as des fonctions qui reviennent régulièrement et ben ca fait vite pas mal de cycles inutile et donc pas mal de temps perdu par l'ordinateur a juste implémenter une variable de controle
Bien souvent, si tu arrive à éviter seulement un appel de fonction sur dix ou sur vingt, le gain en rapidité générale est très largement supérieur à ce que tu peux obtenir en créant des fonctions de dix pieds de long
Le if goto serait la pire des mauvaises idées...par contre un cas ou je n'ai pas trouvé de solution de substitution qui me parraisse convaincant c' est si la boucle est avec une des 2 variables (start ou end) qui ne soit pas connues au moment de la création du programme.
la rien a faire sauf a implanter un if goto entre chaque "interieur" de la boucle remplacee
mais je n aime pas trop cette solution
D'abord, parce que cela va te créer un "code spagetti" particulièrement indigeste
Ensuite, parce qu'un saut conditionnel prend du temps à l'exécution... et revient, finalement, au même que ce qui se fait lorsqu'on utilise les boucles "classiques".
Tu te retrouverais donc dans une situation où tu n'aurais que les inconvéniants, en ayant perdu tous les avantages
J'ai dit un peu coulent...oui, mais devoir imprimer des pattes de mouche illisible parce que les lignes de codes font entre 300 et 500 caractères ce n'est pas très glop.
et te retrouver quand tu imprime a devoir décoder les lignes parce que la mise ne forme te les aura coupé ce n'est pas glop non plus.
et la personne qui lira ton code n'a pas forcement d'écran 16/9 en full hd
Et non, je n'ai pas le plaisir d'avoir un écran 16/9 full HD...
Je n'en suis, actuellement qu'à un petit 17" 4/3 et une résolution de 1024/768
Mais il n'empêche qu'il reste tout à fait possible, avec cette résolution, d'obtenir une ligne de près de 120 caractères, sans "ascenceur horizontal" tout en restant parfaitement lisible... Et poutant, je suis bigleux
Comme je te l'ai dit, les commentaires doivent, de mon point de vue, être "suffisants et minimum", c'est à dire qu'il doivent apporter des précisions que le code (via le choix des noms de fonctions et de variables, principalement) ne peut pas apporter, mais qu'ils doivent rester aussi succincts que possible.A peu près, effectivement certaines lignes (genre affectation de variables n'ont pas besoin de trop de commentaires), mais expliquer ce que fait un algo dans son ensemble cela ne prend pas 2 lignes. ceci dit c'est une contrainte que je m'impose personnellement et que j'ai hérité de mon passage en embarqué, mes collègues sont un peu plus avare (en général ils sont aux alentours de 30%).
Je ne suis pas plus opposé au fait d'avoir dix lignes de commentaires pour expliquer une ligne de code que de n'avoir pas de commentaires du tout, si le code est compréhensible...
Par contre, les commentaires qui ne servent à rien m'horripilent au plus haut point
Ceci dit, j'admets bien volontiers que certains sont avares en commentaires
Le problème, c'est que, si tu travaille avec quelqu'un qui n'est pas sérieux, et que tu lui impose un ratio de commentaires, tout ce que tu risque d'obtenir, ce sont des commentaires inutiles et non sérieux... Même si tu as le ratio conseillé / imposéCe n'est pas imposer c'est une recommandation. Après cela dépend de l'équipe de dev que tu as en face et de ses habitudes, parfois il faut imposer un minimum car j'en connais certains qui sont assez avares de commentaires et qui ne font pas un code lisible pour autant.
la, il faut se reposer sur le sérieux des gens.
A ce moment là, je préfères encore me passer des commentaires (et pourtant j'en use et j'en abuse
A te lire, il y a une chose qui m'étonne beaucoup. Si tu as de telles contraintes de performances, pourquoi coder en utilisant un langage interprété, réputé pour sa lenteur et son absence de performances !J'ai lu tous les posts mais comme il y en as pas mal , je me suis peutêtre un peu perdu dans l'amas
j'ai l'impression en vous lisant que pour avoir un code propre , il faut faire de l'anti optimisation ...
etre clair dans son code pour la plupart d'entre vous semblerai dire :
éviter de répéter le même code plusieurs fois dans le programme.
faire des procédures les plus courtes possibles quitte a découper une "action" en plusieurs sous actions dans des procédures diffèrentes.
le point sur lequel je serai assez d'accord avec vous mais auquel j'ai un mal de chien a me tenir, c'est les commentaires.
pour avoir un code parfaitement optimisé, il faudrai n'avoir en vb par exemple que ces procédures ci :
le main sub ou les form load pour initier le programme et les forms
ensuite uniquement une procédure par évenement.
toute écriture de procédure "de confort" devrait être totalement bannie.
..
alors comment gèrer ce type de code et l'aspect propre et facile a maintenir que vous pronez ?
Même il y a 10 ans, on connaissait le rapport entre les différentes vitesses d'exécution des langages du moment : Assembleur = 1, C/C++ = 1.1, Pascal = 2, VB = 10 !
Depuis les langages ont évolués, les compilos se sont fortement améliorés, tous les langages compilés commencent à ce valoir côté performances et valent largement un code assembleur.
Il n'y a que VB qui a été abandonné par Microsoft et donc qui n'a pas progressé.
Développer les boucles, c'était une technique d'optimisation à la mode, du temps des 80486 et premiers Pentium. Le but était de tirer parti de l'architecture du processeur en pipeline en évitant les sauts car chaque saut réinitialisait le pipeline, ce qui pouvait diviser les perfs par 2 ou 3 sur les petites boucles.
Dans un langage de plus haut niveau, lorsqu'on fait une boucle, il y a le code qui est exécuté dans la boucle, mais aussi le code qui gère le compteur de la boucle. Si la boucle est petite (genre on remplit un tableau avec une constante), la gestion de la boucle coûte plus cher que le code à l'intérieur de la boucle. Mais là encore, on a rarement ce problème avec un compilo moderne qui sait gérer les boucles de façon efficace.
L'appel d'une méthode avec passage de paramètre, dans les langages modernes, l'appel se fait par registre, sans passer par la pile. Autant dire que l'effet sur les perfs est quasi négligeable.
En un mot, si tu veux avoir de bonnes perfs sans perdre en lisibilité : Change de langage ! (bon je sais, on a rarement le choix).
Après comme l'a dit koala01, les plus gros gains de perfs, on les obtient en utilisant des algorithmes performants et adaptés, en surveillant la combinatoire... L'implémentation et langage donneront des écarts de perf de 1 à 10. Un mauvais algorithme, donnera des écarts de perfs de 1 à ... l'infini.
Juste une petite remarque sur les performances et les commentaires : Dans un langage interprété qui ne fait pas une pré-compilation, (certains langages BASIC très anciens, tous les langages de scripts), les commentaires eux-mêmes dégradent les perfs !
Car pour l'interpréteur, une instruction est une ligne de texte qu'il faut analyser avant de se rendre compte qu'il s'agit d'un commentaire et qu'il n'y a rien à faire. Sans pré-compilation du source, cette analyse est faite à chaque exécution !
100% d'accord aec toi
Et très content de voir (enfin) apparaître ta dernière remarque..
Peu de gens comprennent ceci, et la "mode" (parmi quelques autres..) du "tout script" me semble aberrante...
Maintenant, je viens de relire hier une de mes routines de maths, et je m'aperçois qu'elle est longue (2000 lignes), mais que je ne saurais guère la découper plus : le problème est relativement simple, mais l'algo lui-même, comme souvent en maths appliquées, est relativement "une suite logique".. Et je me suis demandé en la regardant hier si tenter de la découper (si cela est possible) d'une part ne ralentirait pas trop (beaucoup de varaibles à ré-initialiser ou re-calculer ou passer en paramètres) et rendrait la lecture plus aisée, ou plus complexe au contraire (en étant obligé de sauter d'une fonction à l'autre....)..
Donc, ce que j'ai dit nettement plus haut dans le débat, au sujet du code "propre", certains cas sortent des "conventions" strictes, et nécessitent des "adaptations" plus ou moins laxistes...
oui mais bon 2000 lignes c'est long et quand tu arrive au bout tu ne te souviens pas forcement du début
le découpage en petites fonctions permet de rentre ton algo plus lisible a condition d'avoir un nommage bien choisi.
les fonctions de haut niveau te donne un vision global de l'algorithme alors que celles plus bas niveau font un tache précise pour laquelle elle sont destinée.
Je ne sais pas de quels langages de script tu parles mais pour pratiquement tous les modernes (Perl, Python, Ruby, PHP...) ce que tu pointes n'a que très peu d'impact vu qu'ils commencent par compiler leur forme écrite vers une forme intermédiaire (bytecode ou autre) qui n'inclut pas les commentaires. Il y a donc un petit coût à payer au démarrage d'un script, mais il est minime (généralement les commentaires sont intentionnellement faciles à reconnaître et donc ignorer pour le parseur) puis l'exécution elle-même ne pâti plus de la quantité de commentaire. Si le script ne tourne pas assez longtemps pour qu'on considère le coût initial des commentaires comme négligeable il s'agit soit d'un script one-shot dont la performance n'est pas un critère important, soit d'un script qui devrait être intégré dans un cadre qui le maintiendrait précompilé pour l'exécuter de nombreuses fois (l'exemple typique étant les applications web).
NB : Ce qui ne signifie pas que je sois particulièrement favorable à l'usage des langages de scripts en toutes circonstances. Ma préférence me porterait plutôt vers des langages fonctionnels compilés comme OCaml ou surtout Haskell qui permettent autant ou plus de concision que les langages de scripts modernes avec de bien meilleure garanties à la compilation et des performances bien plus proches des langages comme C ou Fortran.
--
Jedaï
Tu mentionnes le cas du langage interprété avec pré-compilation. Ce n'est pas toujours le cas.
Tu as Javascript, VBScript, SQL par exemple...
Et contrairement à ce que tu penses : PHP.
Si tu as un PHP standard (sans aucune extensions supplémentaires au delà du package de base), le script (donc la page Web) est parsé, analysé, exécuté à chaque appel de ta page ! Si tu as developpé ta page en full objet, comme on le ferait avec un langage compilé, ton script commence par une tartine d'includes de déclaration de toutes les classes que tu risques d'utiliser, qui de dépendences en dépendences finit par te donner un script qui contient le site complet ! Dans tout ça, tu vas exécuter peut-être une centaine de lignes !
Je sais de quoi je parle, j'ai un site en prod qui bouffe 60% de la charge CPU du serveur web uniquement dans le parsing des includes, avant d'avoir exécuté la première ligne de code.
J'ai obtenu, des gains de perfs de 15% uniquement en supprimant les commentaires dans un seul fichier php ! (bon il faut dire aussi que sur le fichier en question, je cherchais les lignes de code à exécuter, perdues au milieu des commentaires (genre 10 l de commentaire pour 1 l de code)).
Ca représente qu'en même des temps de 200 ms à 300 ms par page !
Evidemment, si ensuite tu met une config genre Zend Serveur derrière pour qu'il te compile les pages une fois pour toute, tu n'as plus ce problème (mesuré et vérifié également). Tu en as d'autres encore pire à la place (mais c'est une autre histoire)...
Je me demande si le problème ne se situe pas ailleurs que là où tu le vois. A l'époque où les microprocesseurs tournaient à 8Mhz, les programmeurs ne s'amusaient pas (plus ?) à dérouler les boucles sous prétexte qu'ils avaient besoin de performance. (Sauf exceptionnellement, par exemple quand quelqu'un voulait programmer une démo ultra rapide sur un Atari ST avec un langage qui n'était pas prévu pour cela comme le GFA BASIC
Donc sur un P3, tu ne devrais pas en avoir besoin non plus. Ni même sur un 386... à condition bien sûr d'utiliser les bons outils. Si tes programmes doivent tourner sur des machines qui ont quinze ans, tu dois les développer avec les environnements et compilateurs de l'époque, car ceux d'aujourd'hui sont bien plus lourds et feront ramer ton code quel qu'il soit. Inutile après de vouloir économiser quelques cycles en déroulant des boucles.
Puis VB a toujours été lent.
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager