Discussion :

[LittleWhite]

Bonjour,

J'écris un post, d'abord pour signaler la présence de ce document: http://google-styleguide.googlecode....k/cppguide.xml
Je m'excuse pour tout ce qui ne lise pas l'anglais ...

Je voudrais remarquer deux points assez interessant, vu que l'on en parle souvent sur ces forums:

- http://google-styleguide.googlecode....xml#Exceptions

We do not use C++ exceptions.

Nous n'utilisons pas les exceptions C++

- http://google-styleguide.googlecode....line_Functions

Define functions inline only when they are small, say, 10 lines or less.

Définissez les fonctions en inline lorsqu'elle sont petite, disons, 10 lignes ou moins.

Je vous laisse découvrir le reste

[Goten]

Pour les exceptions je trouve leur arguments contre l'utilisation des exceptions pas très... justifiable.

Je vois qu'ils utilisent les API de type printf plutôt que les flux ... pourquoi pas :p. Mais j'en ferais pas une régale générale personnellement.


edit : J'ai fini de tout lire, et en effet, comme le dit Joel y'a des trucs assez WTF.

[Joel F]

le document tourne depuis pas mal de temps. y a des trucs à dresser les cheveux sur la tete. On en a debatu sur la ML Boost.dev et y a de strucs vraiment laids.

Cependant, dans une boite genre google je comprends ce genre de truc un peu wtf. Apres le suivre comme ça dans un autre cadre, j'y crois moyen.

[LittleWhite]

le document tourne depuis pas mal de temps. y a des trucs à dresser les cheveux sur la tete. On en a debatu sur la ML Boost.dev et y a de strucs vraiment laids.

Pour le document, je me doutais bien qu'il était là depuis pas mal de temps, mais je viens de tomber dessus aujourd'hui ... et juste pour que d'autres ( gars paumé comme moi ? ) sachent, je l'ai mis ici.

Cependant, dans une boite genre google je comprends ce genre de truc un peu wtf. Apres le suivre comme ça dans un autre cadre, j'y crois moyen.

Et puis, je l'ai aussi mis ici, car récemment nous avons ( enfin pas moi perso ) sur les inline.

Et puis personnellement, je ne fais jamais d'exception, donc ça m'arrange d'avoir un document d'une grande société dire que eux non plus ( genre je vais peut être pouvoir postuler là bas ).

Mais sinon, pour les trucs WTF, vous pouvez précisé ce qui vous choc?

[Joel F]

les excdptions deja, suivi de:

" In general, constructors should merely set member variables to their initial values. Any complex initialization should go in an explicit Init() method."
- la RAII c'ets pour les tequels lapons genre.

"Do not overload operators except in rare, special circumstances. "
" Some Boost libraries encourage coding practices which can hamper readability, such as metaprogramming and other advanced template techniques, and an excessively "functional" style of programming. "

genre le functionnel c'est mal.

[Goten]

Haha, j'avais loupé celui sur le style fonctionnel... huhu, elle est bonne celle là.
C'est comme pour la justification des exceptions : ça oblige à utiliser le RAII ... euh et?

Je suis le seul chez qui le document se load pas en ce moment ?

@Joel : les tequels lapons, c'est la première fois qu'on me la fait celle la...

[LittleWhite]

les excdptions deja, suivi de:

" In general, constructors should merely set member variables to their initial values. Any complex initialization should go in an explicit Init() method."

Bah, celle là ne me choc pas du tout.

Je m'explique. On a une classe avec un pointeur sur un fichier ( oui d'accord, je me crois encore en C ), et d'autre donnée à la noix.
Si on commence à faire l'ouverture du fichier dans le constructeur.... si une erreur se produit, on peut la retourner. Certes, en plus il nous en empêche à cause de la suppression des exceptions.
Mais après moi, mon problème, c'est une exception, je l'attrappe où? ( bon je vais encore faire hors sujet ). Mais comme je bosse toujours en C au boulot, et que le code est assez crade, notamment à la gestion des erreurs ( et à la notification de celle ci ) je me suis habitué à m'occuper de mon erreur ( affichage de l'erreur, changement d'état ... ) et puis après, je retourne juste un code d'erreur, pour si l'utilisateur veut, arrêter le programme. Après, si il ne veut pas ... bah c'est son problème, moi j'ai fait mon max.
( Utilisateur == codeur qui utilise mon code ).

Donc, avoir un constructeur, qui ne peut pas retourner un code d'erreur, moi perso, j'aime moyen.
Après c'est un point de vue, j'imagine, et cela dépend du cas.

Je suis le seul chez qui le document se load pas en ce moment ?

Même problème ( depuis que j'ai crée le topic ). Mais j'avais des problèmes d'affichage sous firefox ( du texte sans formattage :s ).

[3DArchi]

Salut,
Je n'ai pas encore pris le temps de lire le doc. Mais j'imagine que google ne doit pas être très différents des autres entreprises où j'ai vu des règles de codage : certains aspects du C++ sont peu ou pas recommandés pour différentes raisons bonnes ou mauvaises : méconnaissance de la part du rédacteur, complexité induisant un niveau de compétence inadéquat avec les profils disponibles, contexte projet, organisationnel, etc.
Les exceptions (souvent pour de mauvaises raisons) et la programmation générique (trop technique) sont 2 aspects qui font souvent peur.

[Joel F]

Salut,
Je n'ai pas encore pris le temps de lire le doc. Mais j'imagine que google ne doit pas être très différents des autres entreprises où j'ai vu des règles de codage : certains aspects du C++ sont peu ou pas recommandés pour différentes raisons bonnes ou mauvaises : méconnaissance de la part du rédacteur, complexité induisant un niveau de compétence inadéquat avec les profils disponibles, contexte projet, organisationnel, etc.
Les exceptions (souvent pour de mauvaises raisons) et la programmation générique (trop technique) sont 2 aspects qui font souvent peur.

c'est exactement ça. J'en rigole personnellement de ce document mais je les comprends parfaitement.

[Luc Hermitte]

Ils ont un problème de base de code ancienne avec laquelle il faut rester compatible.
Vu que les exceptions exigent de penser le code différemment, ils sont restés en C with classes pour cet aspect là. (c'est ce que je déduis de la seule justification valables qu'ils ont donnée dans leur document)

Quant aux fonctions init(), j'en ai horreur : je préfère ne pas avoir d'objet plutôt que de devoir tester si l'objet est valide dans toutes ses fonctions. Les invariants "statiques" c'est bien, mangez-en.

[jblecanard]

Salut

Je suis aussi adepte des bonnes pratiques (ou du moins, je m'efforce de l'être). J'ai parcouru le document et je trouve qu'il n'y a rien de fondamentalement choquant.

C'est vrai que le coup de l'init est un peu crade, mais il ne faut pas oublier que dans de très grosses boîtes, il y a parfois une couche supplémentaire au-dessus du paradigme objet (COM pour Microsoft par exemple, mais ce n'est pas qu'un exemple et je n'utilise pas COM mais une autre couche composant), et le constructeur à un rôle pivot entre cette architecture et les objets. Dès lors, l'utilisateur prend la main sur un init et pas sur le constructeur, ne pouvant par exemple pas lui passer d'argument puisque le mécanisme d'intanciation est opéré par l'architecture de composants.

Cela dit, l'argumet utilisé dans le document à ce sujet est fallacieux, sur ce point, je suis d'accord avec vous. Se coltiner une vérification de l'objet à chaque méthode, c'est plus que naze. Mais en général, les architectures de composants font qu'on n'a justement pas ce problème (c'est quand même bien gaulé).

Pour les autres points, il s'agit essentiellement de restrictions. Par exemple je ne peux pas utiliser de templates dans mon projet, mais parce que le code doit compiler sur plusieurs compilateurs dont certains... qui ne supportent pas les templates.

Ensuite il y aussi des restrictions lié à une sorte de "manque de confiance" dans les programmeurs. C'est une manière de garder la main sur la robustesse du code. C++ est quand même complexe. En réduisant les fonctionnalités du langage que les développeurs ont le droit d'utiliser, on rend dans le même temps plus facile le contrôle de qualité du code source, et les mauvaises surprises. Il ne faut pas oublier le rollover qu'il y a dans les grosses équipes. Entre les prestataires, les stagiaires qui croient savoir faire, etc... si tout le monde y va de ses templates et de ses opérateurs surchargés, ça peut vite devenir le bazar !

Les features avancées du C++ sont laissées aux équipes bas niveau qui s'en servent et gèrent ça proprement avec un savoir faire global supérieur à la plupart des développeurs qui sont au plus haut niveau. Je trouve ça très bien. Dès lors, les règles érigées le sont pour le plus haut niveau, et certaines équipes y dérogent pour de bonnes raisons.

Je trouve que c'est une très bonne approche, comme en sécurité : on ferme tout, et on ouvre ponctuellement ce dont on a besoin. Réparer du mauvais code produit par un incompétent coûte très cher, il faut donc s'en prémunir autant que faire se peut. Et vous savez tous autant que moi que les incompétents ne sont pas l'espèce la plus rare dans notre milieu.


Allez, pour vous faire plaisir, j'y vais de ma petite critique technique. Je trouve bizarre leur technique pour interdire les constructeurs par copie (utiliser DISALLOW_COPY_AND_ASSIGN). Ce serait pas plus simple de simplement les mettre en private et de ne pas les implémenter ?

[LittleWhite]

Allez, pour vous faire plaisir, j'y vais de ma petite critique technique. Je trouve bizarre leur technique pour interdire les constructeurs par copie (utiliser DISALLOW_COPY_AND_ASSIGN). Ce serait pas plus simple de simplement les mettre en private et de ne pas les implémenter ?

Oui, celle là, je l'avais vu ... et je me dit que la coup de la macro est quand même un peu inutile. Mais peut être que des gens ne savent pas ...

[guillaume07]

je m'imagine mal faire une appli robuste et lisible sans utiliser le mécanisme des exceptions.

[3DArchi]

Quant aux fonctions init().

Lorsque j'ai vu les gens préconiser des fonctions init, c'était parfois pour regrouper un ensemble d'initialisations commun à plusieurs constructeurs :

Code :

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

1
2
3
4
5
6
7
8
9
10
 
class A
{
public :
   A():blabla{init();}
   A(blibli):blublu{init();}
private:
    void init()
    { ....}
};

Mais c'est vrai que c'est rarement compris comme ça et plutôt pensé sous la forme :

Code :

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

1
2
3
A a;
a.init();
// maintenant je peux utiliser a :(

Peut être que C++0x en permettant d'enchaîner les constructeurs permettra de se passer d'une partie de ces fonctions init().
Mais comme dit Jean-Bernard, il y a aussi la contrainte imposée par certain framework.

Ensuite il y aussi des restrictions lié à une sorte de "manque de confiance" dans les programmeurs.

C'est un argument que je croise souvent, que j'ai compris à un certain moment et sur lequel je m'interroge de plus en plus pour plusieurs raisons.
Il y a d'abord un à-priori sur le manque de confiance envers les gens et ca me heurte.
Après, je préfère penser que la monté en compétence peut se faire aussi sur le langage. Et ce d'autant plus que les aspects avancés ne sont pas seulement enfouis tout au fond de couches réservées à des cadors et interdites à d'autres.
Toujours sur cet aspect, avec le temps j'en suis arrivé à penser que le coût d'entrée (et le risque induit par des nouveaux arrivants ou un trop fort turnover) dans un projet est moins lié au langage et aux ésotérismes utilisés qu'à 1/ aux implicites métier et à son historique, 2/ à l'histoire du soft (ses codeurs, ses architectes, les bugs 'traumatisants', etc.). Bref, le langage me semble être la chose la plus facile à apprendre et à partager.
Enfin, je me demande dans quelle mesure cela n'est pas contre productif : renoncer à des aspects 'avancés' (je pense en particulier aux génériques) c'est aussi mettre en place des architectures qui peuvent au final être plus complexes et par conséquent générer plus de bugs.
Bref, pas si simple que toutes ces règles...

[koala01]

Salut,

Toujours sur cet aspect, avec le temps j'en suis arrivé à penser que le coût d'entrée (et le risque induit par des nouveaux arrivants ou un trop fort turnover) dans un projet est moins lié au langage et aux ésotérismes utilisés qu'à 1/ aux implicites métier et à son historique, 2/ à l'histoire du soft (ses codeurs, ses architectes, les bugs 'traumatisants', etc.). Bref, le langage me semble être la chose la plus facile à apprendre et à partager.
Enfin, je me demande dans quelle mesure cela n'est pas contre productif : renoncer à des aspects 'avancés' (je pense en particulier aux génériques) c'est aussi mettre en place des architectures qui peuvent au final être plus complexes et par conséquent générer plus de bugs.
Bref, pas si simple que toutes ces règles...

Je ne peux qu'être d'accord avec toi...

Quand on y pense, un langage de programmation, ce n'est pas grand chose:

• moins d'une centaine de mots clé
• une syntaxe pas forcément difficile à assimiler
• certaines particularités propre à la philosophie ou à l'histoire du langage
• un certain nombre de structures / fonctions /classe (selon le langage envisagé) fournies par le langage lui-même

Au delà, il faut rester conscient du fait que les grands principes de la programmation, qu'elle soit procédurale pure, OO ou générique restent toujours les mêmes, et l'important est donc, bien plus que le langage lui-même, tout le travail "préparatoire" (conception, algorithmes, ...) qui doit être fait avant l'écriture de la première ligne de code.

J'ai la conviction qu'il est possible d'apprendre n'importe quel langage de programmation en quelques mois à peine (sans y passer 8 heures par jour), mais qu'il faut souvent (beaucoup) plus de temps pour le maitriser réellement, et que tout est généralement fait pour, justement, inciter les gens à évoluer.

Enfin, vouloir imposer une fonction init alors que le RAII est un principe des plus utiles à utiliser (s'il est possible de le mettre en oeuvre, du moins, mais c'est le cas des langages OO), imposer des structures rigides en renonçant à la programmation générique, si disponible, c'est, à mon sens, prendre le risque de copier / coller hasardeux ou de bugs qui auraient parfaitement pu être évités.

De manière générale, si je peux admettre l'idée que les gens aient peur de l'incompétence de leur équipe (car il faut avouer que c'est effectivement un risque important, surtout s'il y a beaucoup de turn over), je me dis que, plutôt que de faire avec et donc effectuer un nivellement "vers le bas", il serait autrement plus intéressant (pour tout le monde) d'essayer de tirer les collaborateurs les moins compétants "vers le haut" en les incitant à parfaire leur compétances, quitte à les "surveiller" peut être d'un peu plus près

[Klaim]

je m'imagine mal faire une appli robuste et lisible sans utiliser le mécanisme des exceptions.

Note que quasimment tous les jeux produits dans l'industrie du jeu vidéo (je dis bien l'industrie classique) n'utilisent pas les exceptions (sur console notemment) sous plusieurs pretextes plus ou moins justifiés dont le plus important : on a pas le droit a l'erreur sur console. (ya aussi le problem des perfs qui est souvent justifié dans l'embarqué du moins, mais même sur pc ça a un cout à connaitre...)

Autrement dit des appli robustes et lisibles il y en a sans exceptions, mais bon c'est sur que c'est plus difficile a écrire sans les exceptions. Au final les exceptions sont super utiles tant que les utilisateurs finaux les voient pas... et bon dans le jeux c'est naturellement prohibé.

Ce qui ne m'empeche pas de les utiliser dans mon propre jeu parceque je ne suis pas affecté par le coup de l'utilisation et même j'en profite par plusieurs aspect même dans le cas ou le jeu ne peux pas continuer. C'est juste un assez rare dans ce domaine. Et puis si je devais porter le jeu sur console, je ferais tout simplement sauter tout systeme d'exception. Pas le choix.

J'ajoute que le milieu du jeu vidéo est connu pour adopter les nouvelles techniques sur le tard, c'est un milieu assez méfiant dans le domaine (a cause des risques cummulés certainement). Dans le milieu indépendant par contre je vois que les développeurs s'en foutent royalement tant que le jeu est codé de manière a avoir le resultat escompté et pas dans des délais impossible. Aussi les bonnes pratiques type "utiliser les exceptions et savoir s'en servir correctement" sont ...mises en pratique
Un peu comme dans l'open source en général en fait.


Pour le point des compétences, personnellement je suis de votre avis. Par contre j'ai vu des projets/boites ou la situation était trop difficile pour que de l'energie soit dépensée dans l'apprentissage de "nouvelles" techniques ou plutôt le partage des connaissances dans les équipes.
Pour moi, c'est l'état d'urgence issu du manque de préparation comme tu dis koala01 ou encore du dangereux optimisme des collègues qui handicap toute avancée de connaissances et de qualité du code dans un projet ou une entreprise. D'ailleurs, est-ce que ce n'est pas souvent hors du cadre du travail qu'on apprends le plus? Lorsqu'on "joue" avec des techniques et autres connaissances comme si c'était des jouets fascinants?

Dans tous les cas, le mélange des points de vus a) un étudiant qui a fait 2 à 3 ans de cours de programmation à l'école est un programmeur, pas besoin de savoir plus; et b) les programmeurs sont toujours en retard dans les projets ; tout ça dévalue le métier parceque le reste du monde ne se rends pas compte que pour arriver a ecrire le bon code il faut avoir...........pris le temps..........................de.................REFLECHIR!

[Invité]

Les règles de Google sont tout à fait logique, certains trucs hardware nécessitent de ne pas utiliser les exceptions ni la RTTI... Il s'ensuit qu'il ne faut pas mettre trop de chose dans le constructeur car un constructeur ne peut échouer qu'en lançant une exception.

Et puis c'est vrai que quelque part, une fonction qui renvoie un code d'erreur nous engage moralement à en faire quelque chose, alors qu'une fonction qui peut lancer une exception... ca ne se voit pas.

[koala01]

Note que quasimment tous les jeux produits dans l'industrie du jeu vidéo (je dis bien l'industrie classique) n'utilisent pas les exceptions (sur console notemment) sous plusieurs pretextes plus ou moins justifiés dont le plus important : on a pas le droit a l'erreur sur console. (ya aussi le problem des perfs qui est souvent justifié dans l'embarqué du moins, mais même sur pc ça a un cout à connaitre...)

J'aurais presque tendance à demander si cela implique que la connexion internet est considérée comme systématiquement existante et de qualité

Je suis d'accord avec le fait que, théoriquement du moins, un fichier ne peut pas être absent sur console, mais, à coté de cela, étant donné que les consoles sont de plus en plus utilisées pour le jeu en réseau, que va-t-il arriver si, d'aventure, la connexion adsl vient à être coupée, pour une raison ou une autre

Autrement dit des appli robustes et lisibles il y en a sans exceptions, mais bon c'est sur que c'est plus difficile a écrire sans les exceptions. Au final les exceptions sont super utiles tant que les utilisateurs finaux les voient pas... et bon dans le jeux c'est naturellement prohibé.

Aucune exception ne devrait pour ainsi dire remonter jusqu'à l'utilisateur final, mais c'est un autre débat (qui porte sur la bonne utilisation de celles-ci )

Ce qui ne m'empeche pas de les utiliser dans mon propre jeu parceque je ne suis pas affecté par le coup de l'utilisation et même j'en profite par plusieurs aspect même dans le cas ou le jeu ne peux pas continuer.

Il me semble totalement utopique de croire qu'une technique particulière puisse être la solution à tous les maux.

Les exceptions sont parfois la meilleure solution, parfois la pire, comme n'importe quelle solution dont l'utilisation peut être envisagée dans n'importe quel process de production d'une application / bibliothèque.

Mais, de là à refuser une technique parce que l'on estime "qu'il y a un risque" pour que le développeur en abuse ou l'utilise "à mauvais escient", c'est rabaisser le développeur bien bas, non

[jpouly]

Contrairement a des languages (et framework) comme Java ou C#, le C++ donne aux développeurs plusieurs solutions pour un même probléme.

Je comprend qu'une entreprise cherche à normaliser les techniques et l'ecriture du code source de ses applications.

On peut toujours discuter de la norme après, et la faire évoluer .

Un petit exemple parmis tant d'autres : le constructeur de copy.

[nikko34]

Les règles de Google sont tout à fait logique, certains trucs hardware nécessitent de ne pas utiliser les exceptions ni la RTTI... Il s'ensuit qu'il ne faut pas mettre trop de chose dans le constructeur car un constructeur ne peut échouer qu'en lançant une exception.

donc du coup tout leur code suit la même règle? Moi ça me fait penser à du nivellement par le bas.

Et puis c'est vrai que quelque part, une fonction qui renvoie un code d'erreur nous engage moralement à en faire quelque chose, alors qu'une fonction qui peut lancer une exception... ca ne se voit pas.

non, non vraiment, là c'est n'importe quoi. Si tu récupères pas une exception ça va me remonter jusqu'au plus haut (et c'est ptet ce que tu veux). Si tu ne fais rien avec ton retour d'erreur... ben il ne se passe rien.

Le système d'exception existe en C++ parce qu'il se marie bien aussi avec le RAII et la notion de destructeurs qui peuvent libérer les ressources automatiquement.

Après oui si on utilise le C++ sans RAII, sans exception, ben c'est un peu dommage quoi.