Discussion :

[koala01]

Il n'a meme pas besoin de tendre à devenir open source...

Le premier lecteur du code que tu crées, c'est toi ...

Le problème c'est qu'il y a mille et une raisons qui peuvent faire que tu veuilles revenir sur ton code plus tard.

Et "plus tard", ca peut varier de quelques heures à plusieurs mois, voir plusieurs années (apres tout, pourquoi pas )

Le problème, c'est que, ce qui te parrait peut etre limpide au moment où tu l'écris risque de te parraitre beaucoup plus nébuleux quand tu y reviens "plus tard" (et généralement d'autant plus nébuleux que ce "plus tard" est éloigné de la création, et c'est encore pis si tu "reprend" un code dont tu n'es pas l'auteur parce que tu es intégré au sein d'une équipe)

Des cinq gros conseils de "belle présentation du code" que voici

1. une linge= une instruction ou une declaration
2. indentation cohérente du code
3. utilisation de noms de fonction/variable en rapport avec l'usage qui en est fait
4. éviter les fonctions trop longues (+/- 50 linges max)
5. insertion de commentaires cohérents et utiles pour les parties les plus denses

seuls les derniers peuvent demander un peu plus de temps que les autres (ben oui, leur mise en pratique peut demander une réflexion approfondie )

Surtout, quand on vois les éditeurs actuels qui permettent de créer une identation de manière automatique...

Le temps "perdu" à la mise en pratique de ces conseils sera en fait regagné dans une proportion énorme par la suite (qu'il s'agisse du débuggage, alors que le code est encore limpide ou de la reprise du code plus tard)

Si, en plus, d'autres personnes doivent pouvoir etre en mesure de comprendre ce que tu as codé, le gain de temps s'éleve presque de manière exponentielle
[EDIT] Ceci dit, il est vrai que chacun voit midi à sa porte... par contre, il n'y aura au final que tres peu d'application sur lesquelles tu ne seras pas tenté de revenir

[spawntux]

Je suis tout a fait d'accord avec toi c'est d'aillieurs la methode que je pratique sur les gros projets et cette methode est execelente mais encore faut il que tout le monde la suive dans un meme projet ^^ d'aillieur j'ai une question tu utilise un TAB de combien ??
Personnelement j'utilise un TAB de 4 mais apres je voudrait savoir ce que vous en pensez ??(trop grand trop court...)

[koala01]

Je suis tout a fait d'accord avec toi c'est d'aillieurs la methode que je pratique sur les gros projets et cette methode est execelente mais encore faut il que tout le monde la suive dans un meme projet ^^

Ca, c'est la responsabilité du gestionnaire/chef de projet/ de l'entreprise que de définir (éventuellement sur avis des collaborateurs) une "politique de codage" cohérente commune et de la faire appliquer...

Et ce n'est pas une mince responsabilité

d'aillieur j'ai une question tu utilise un TAB de combien ??
Personnelement j'utilise un TAB de 4 mais apres je voudrait savoir ce que vous en pensez ??(trop grand trop court...)

Généralement, j'utilise une indentation de quatre espaces, mais sous forme d'espaces, et non sous forme d'une "définition du TAB" (et une mise en forme du type ANSI parce que le le K&R, personnellement, je ne m'y fais pas - meme si je n'éprouve que peu de problèmes à la lecture d'un code formaté avec - mais simplement parce que je trouve plus clair d'avoir l'accolade ouvrante sur la meme colone que l'accolade fermante )

L'avantage d'un nombre fixe d'espaces est, à mon sens, que cela évite les problèmes dus au fait que la tabulation peut etre réglée sur 4 espaces dans un éditeur et sur... 16 sur un autre, avec la perte de la mise en forme que représente le passage d'un éditeur à l'autre...

Mais, en COBOL, par exemple j'ai pris l'habitude, du coté de la data definition, d'alligner les types sur la première lettre et les noms correspondants sur la derniere, avec indentation du niveau -et donc, un espace "variable" entre le numéro du niveau et le type de la donnée et entre le type et le nom - "simplement" parce que c'était la mise en forme que le prof appréciait quand j'ai pris les cours (il faut aussi dire que le COBOL est limité en nombre de caractères par lignes, alors que C et C++ ne le sont pas )

Mais ces détails font typiquement partie "des gouts et des couleurs" - si, du moins, ils n'entrent pas dans l'optique d'une conception en équipe - et ce ne sont donc que des avis strictement personnels, avec tout ce que cela implique

[spawntux]

Oui bas tu doit avoir a peu pres les meme gout que moi je trouve egalement que les accolades sur la meme colonne c'est plus explicite ^^ +1 pour l'histoire chef de projet mdr .

[Jan Rendek]

Scott Meyers préconise de déclarer les variables locales le plus tardivement possible. L'argumentaire est dans un des items de "Effective C++", Item 32 "Postpone variable definitions as long as possible".
Son argument principal est effectivement de ne pas avoir à payer le coût de la
construction d'objets appartenant à des branches de la fonctions qui ne seront pas exécutées.

L'apparente clarté d'initialiser toutes les variables en début de bloc ne vaut que pour les programmeurs chevronnés dans les langages ou cette pratique est imposée.

Pour ce qui est du nombre d'espaces, de la place des accolades etc. Il existe des 'beautifiers' qui se chargent très bien d'uniformiser les différentes pratiques de tout un chacun.

[Médinoc]

Je suis contre les déclarations anticipées de variables en C++, car il arrive souvent qu'une variable ne soit écrite qu'une seule fois. Dans ce cas, s'il est possible de ne la déclarer et l'initialiser qu'à ce moment-là, on peut alors la déclarer const.

[Thierry Chappuis]

Scott Meyers préconise de déclarer les variables locales le plus tardivement possible. L'argumentaire est dans un des items de "Effective C++", Item 32 "Postpone variable definitions as long as possible".
Son argument principal est effectivement de ne pas avoir à payer le coût de la
construction d'objets appartenant à des branches de la fonctions qui ne seront pas exécutées.

L'apparente clarté d'initialiser toutes les variables en début de bloc ne vaut que pour les programmeurs chevronnés dans les langages ou cette pratique est imposée.

Pour ce qui est du nombre d'espaces, de la place des accolades etc. Il existe des 'beautifiers' qui se chargent très bien d'uniformiser les différentes pratiques de tout un chacun.

D'un autre côté, si on regarde les conventions de codage éditées par Sun concernant le langage Java, il est conseillé de déclarer toutes les variables en début de bloc alors même que le langage ne l'impose nullement. J'ai toutefois du mal à laisser de côté mes habitudes aquises en C++. Je ne sais pas si déclarer une variable proche de son utilisation change véritablement quelque chose sur une méthode de +/- 50 lignes max. par rapport à l'initialisation en début de bloc. En revanche, pouvoir initialiser des variables/objets directement à leur finale, et pouvoir déclarer la plupart de ces variables avec le qualificatif const lorsque c'est approprié apporte un gain substanciel en terme de lisibilité du code.

Thierry

[loufoque]

Mais, là, on aborde plus le problème des "bonnes" habitudes de programmation que le simple problème d'une déclaration anticipée.

Ainsi, cette simple ligne

Code :

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

membre=methrode1(methode2(methode3(methode4(), methode5())));

est, susceptible d'etre tout à fait valide si les types de retours correspondent aux type des arguments attendus par les différentes méthodes...

Mais il n'empeche que, meme avec des noms de méthodes "auto-commentée" (AKA dont on retrouve l'action effectuée dans le nom) la ligne présentera une difficulté de lecture bien suppérieure au code

Code :

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

1
2
3
4
5
6
 
type1 val=methode5();
type2 val2=methode4();
type3 val3=methode3(val2);
type4 val4=methode2(val3);
typefinal=methode1(val,val4);

qui fournira pourtant un résutlat tout à fait identique, et pas forcément plus lent à l'exécution - avec, bien sur,les types et les noms de méthodes/variables cohérents.

Si, ce sera potentiellement plus lent en C++0x.
Et je trouve cela beaucoup plus verbeux et plus sujets aux erreurs. Laisser faire l'inférence des types et la gestion des temporaires est plus pratique.

[koala01]

Si, ce sera potentiellement plus lent en C++0x.
Et je trouve cela beaucoup plus verbeux et plus sujets aux erreurs. Laisser faire l'inférence des types et la gestion des temporaires est plus pratique.

C++0x ne sera pas finalisé avant deux ans à peu pres, il est donc difficile de tirer des plans sur le comportement potentiel d'un tel code...

Cependant, avec les classes qui vont bien (comprenant opérateurs d'affectation et autres, par exemple), la différence ne devrait pas etre tres flagrante

Le fait, justement, qu'un code soit plus verbeux est, pour autant que les noms de variables soient choisis de manière cohérente (et pas uniquemement val1...valn) est, à mon sens, bien moins sujet à erreur, car plus précis, que le fait de laisser faire les choses par le compilateur...

Si ralentissement il y a, il sera plutot minime, surtout quand on voit la vitesse atteinte par les processeurs actuels, mais l'écriture verbeuse du code permet, à mon sens, de rendre le code plus facilement compréhensible.

De plus, le passage par une variable temporaire peut s'avérer, en définitive dans certain cas particuliers bien plus rapide que l'utilisation de la fonction (je penses, entre autres, aux boucles pour lesquelles il est préférable d'utiliser une variable temporaire récupérant monobjet.size() plutot que d'appeler monobjet.size() à chaque fois dans la boucle... surtout si la la taille du contenur n'est pas modifiée à chaque itération...)

Je ne veux pas dire qu'il faut éviter l'utilisation des racourcis proposés par le langage, car il sont intéressants malgré tout, je dis juste qu'il doivent etre utilisés à bon escient, au meme titre que n'importe quelle autre technique...

*Si* amélioration de la vitesse d'exécution il y a, entre le code qui utilise directement l'appel des fonctions et celui qui utilise des variables temporaires, et si elle est sensible au point d'inciter à recourrir à cette possiblité, j'ai personnellement tendance à estimer que son utilisaiton devrait n'etre envisagée qu'en phase de test et d'optimisation, une fois que le reste a été testé et correctement implémenté, ou, si tu préfères, à un moment où il semble clair qu'il ne sera plus nécessaire de retourner modifier profondément le code - et en ajoutant, "par sécurité", les commentaires qui permettront de comprendre le but de la manoeuvre.

[loufoque]

C++0x ne sera pas finalisé avant deux ans à peu pres, il est donc difficile de tirer des plans sur le comportement potentiel d'un tel code...

Cela n'est pas difficile du tout.
On sait que C++0x identifiera de manière différente les variables temporaires des variables non temporaires.
Certains compilateurs implémentent déjà cette possibilité.

On peut alors en particulier se permettre de déplacer les variables temporaires, alors qu'il est nécessaire de copier les autres.

La différence est flagrante pour tout objet référençant des ressources.

Le fait, justement, qu'un code soit plus verbeux est, pour autant que les noms de variables soient choisis de manière cohérente (et pas uniquemement val1...valn) est, à mon sens, bien moins sujet à erreur, car plus précis, que le fait de laisser faire les choses par le compilateur...

Il est surtout sujet à erreur dans le choix du type, provoquant problème de forwarding ou pire, une copie inutile.
Sans parler du fait que cela empêche certaines optimisations dans l'usage des références, qui sont probablement minimales en effet.

Si ralentissement il y a, il sera plutot minime, surtout quand on voit la vitesse atteinte par les processeurs actuels, mais l'écriture verbeuse du code permet, à mon sens, de rendre le code plus facilement compréhensible.

C'est sûr, la vitesse des processeurs nous permet d'utiliser du O(n) à la place de O(1).
D'ailleurs pourquoi ne pas rendre toutes les opérations exponentielles tant qu'on y est ?

De plus, le passage par une variable temporaire peut s'avérer, en définitive dans certain cas particuliers bien plus rapide que l'utilisation de la fonction (je penses, entre autres, aux boucles pour lesquelles il est préférable d'utiliser une variable temporaire récupérant monobjet.size() plutot que d'appeler monobjet.size() à chaque fois dans la boucle... surtout si la la taille du contenur n'est pas modifiée à chaque itération...)

Jamais un benchmark n'a réussi à démontrer une quelconque amélioration dans ce cas en utilisant un objet temporaire.
Pour la simple raison que std::vector<T>::size par exemple se limite à une fonction en ligne qui retourne une valeur.

L'utilisation d'une variable temporaire est uniquement utile si le traitement est relativement important pour éviter de faire plusieurs fois le même traitement.
De toutes manières, il n'y avait aucune répétition dans ton exemple originel.

*Si* amélioration de la vitesse d'exécution il y a, entre le code qui utilise directement l'appel des fonctions et celui qui utilise des variables temporaires, et si elle est sensible au point d'inciter à recourrir à cette possiblité, j'ai personnellement tendance à estimer que son utilisaiton devrait n'etre envisagée qu'en phase de test et d'optimisation, une fois que le reste a été testé et correctement implémenté, ou, si tu préfères, à un moment où il semble clair qu'il ne sera plus nécessaire de retourner modifier profondément le code - et en ajoutant, "par sécurité", les commentaires qui permettront de comprendre le but de la manoeuvre.

Une fois que tu réalises que tu as oublié d'implémenter les sémantiques de mouvement tu veux dire ?

[JolyLoic]

Cela n'est pas difficile du tout.
On sait que C++0x identifiera de manière différente les variables temporaires des variables non temporaires.
Certains compilateurs implémentent déjà cette possibilité.

Je n'ai pas trop suivi les discussions sur la move semantic, mais le compilateur n'est-il pas en droit de réécrire :

Code :

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

1
2
3
4
5
{
  T t1 = f();
  T t2 = g();
  T t3 = h(t1, t2);
}

ainsi :

Code :

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

1
2
3
{
  T t3 = h(f(), g());
}

Il a le droit de le faire aujourd'hui, ce serait dommage s'il ne pouvait plus le faire à cause de la move semantic.

[loufoque]

Un T temporaire est convertible en T&&, un T non temporaire ne l'est pas mais est convertible en T&.
(Un T temporaire reste convertible en T const&)

Après les compilateurs ont peut-être le droit d'analyser le code pour voir si l'objet n'est en fait pas un temporaire car non utilisé ailleurs. Je n'en sais rien.

Mais a priori si ce genre de choses était autorisé, ça l'est toujours, sauf que le pseudo-temporaire ainsi obtenu n'est pas forcément convertible vers T&&.

[Jean-Marc.Bourguet]

Ok, on écrira alors

Code :

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

1
2
3
4
T&& v1 = e1;
T&& v2 = e2;
T&& v3 = e3;
f(e1, e2, e3);

si effectivement on est dans un cas où ça peut jouer un rôle. Tient, je me demande comment ça interragit avec auto (qui règle le problème de la verbosité en autorisant l'inférence de type).

Mais le fond de la remarque de koala01 tient toujours: il est des cas où est est plus clair d'introduire des variables que mettre des expressions imbriquées. Même les fans de la programmation fonctionnelle sont d'accord.

Il est extrèmement optimiste de penser avoir des compilateurs C++0X en production dans deux ans. On n'a toujours pas beaucoup de compilateurs C++98 conformes sur tout (je parie d'ailleurs qu'il y aura des compilateurs implementant les lvalue references avant export).

[Jan Rendek]

D'un autre côté, si on regarde les conventions de codage éditées par Sun concernant le langage Java, il est conseillé de déclarer toutes les variables en début de bloc alors même que le langage ne l'impose nullement.

Le problème est différent en Java car toutes les variables de types non-scalaires sont allouées sur le tas.

[loufoque]

Ça doit rendre la NRVO impossible là par contre.

Le problème est différent en Java car toutes les variables de types non-scalaires sont allouées sur le tas.

Et la déclaration n'appelle pas le constructeur en Java il me semble. Cela n'est fait qu'avec new.
Comme avec des pointeurs en C++ quoi.

[Jan Rendek]

Et la déclaration n'appelle pas le constructeur en Java il me semble. Cela n'est fait qu'avec new.
Comme avec des pointeurs en C++ quoi.

C'est exactement ce que j'entendais par là.

[koala01]

Selon moi, si pour un meme algorithme, deux écritures sont possibles - l'une plus lente mais plus aisément compréhensible, l'autre plus rapide mais plus complexe à appréhender - il y a lieu d'utiliser la premiere tant que le code et ses implications sont susceptibles d'être modifiés en profondeur...

N'oublie pas qu'un projet peut s'étaler sur plusieurs mois, voire, sur plusieurs années, et que plusieurs personnes sont même susceptibles de "poser leurs yeux" sur la même portion de code.

Or, l'esprit humain est ainsi fait que ca demande un effort important - même s'il est inconscient - pour se remémorer ce qui est plus vieux qu'à peine quelques minutes... Je te laisse imaginer ce qu'il en est apres plusieurs mois...

L'optique la plus saine, pour éviter les pertes de temps inutiles, c'est de privilégier un code facile à "reprendre en main", tant qu'on n'est pas certain que le code ne devra pas etre retouché.

Il n'est en effet pas rare que, au fil du développement, on en vienne à modifier ce qui a été fait - par ajout d'un membre dans une classe, par exemple - et que cette modification nécessite de modifier une partie du code existant...

Mais comme la partie de code à modifier peut très bien avoir été écrite plusieurs mois plus tot - voire, par une autre personne de l'équipe - il est primordial que la personne qui sera chargée des modifications puisse prendre rapidement ses marques. Plus le code sera complexe, plus la personne aura du mal à récupérer ses marques...

Et certains algorithmes sont déjà suffisemment complexes pour ne pas les rendre encore plus difficiles à appréhender par l'utilisation d'une écriture - certes, qui fait gagner quelques nano secondes - mais qui va demander (beaucoup) plus de temps pour comprendre ce qui est fait...

Il faut bien comprendre que les optimisations d'écriture ne sont de nature qu'à faire gagner que quelques fréquences d'horloge... quelques nano seconde au vu des processeurs actuels.

Lorsque l'on testera les fonctions "petits bouts par petits bouts" la différence sera à ce point minime qu'on ne la remarqueras meme pas...

Par contre, ces optimisations d'écriture sont clairement de nature à faire passer plusieurs minutes, d'ici un mois ou deux, à se poser des questions du genre de "mais que fait ce test " ou "mais que fait cette fonction qui demande trois autres fonctions en paramètres ". Et ca, c'est vraiment du temps perdu pour rien...

Maintenant - une fois que tous les "petits bouts" sont prets et sont rassemblés - si, en période finale de test, on se rend compte qu'une optimisation d'écriture permettra de gagner en performances - parce que les petits ruisseaux font les grands fleuve et que, justement, cette fonction est appelée de nombreuses fois, et principalement au sein de boucles - nécessité fait loi: l'écriture doit être optimisée.

Mais ca doit etre fait en tout dernier, juste avant de remettre l'application à celui qui l'a demandée

Du moins, tel est mon avis, quitte à me faire traiter d'hérétique par certains

[Jan Rendek]

Je ne trouve pas que déclarer les variables en début de fonction soit un progrès en terme de maintenabilité et de clarté de code. C'est surtout plus clair pour ceux qui ont une grosse expérience dans des langages qui l'impose.
D'ailleurs, historiquement cette restriction n'a pas été imposée pour une meilleur lisibilité, mais pour simplifier l'écriture du compilateur.

Dans beaucoup de cas, je trouve que la déclaration de variables à l'endroit de leur emploi facilite la compréhension du code.

[koala01]

Si c'est en réponse à ma diatribe, je te rassures: je parlais plus du fait d'utiliser un mode verbeux dans l'écriture du code que de la déclaration anticipée des variables...

Mais, ceci dit, *certains* préfèrent avoir la liste de toutes les variables au début, et d'autres préfèrent avoir la déclaration au moment où il est possible d'en définir la valeur.

La déclaration au moment de l'initialisation avec une valeur directement correcte présente quelques avantages certains, dont, entre autre, une portée plus controlée, et il est de bon ton de s'y habituer...

Cependant, malgré les avantages de la déclaration juste avant l'utilisation, je ne jetterai jamais la pierre à quelqu'un qui, pour une raison quelconque, décidera d'utiliser une déclaration anticipée...

[Jan Rendek]

me voilà donc rassuré