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...

[dvdbly]

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

C'est quoi un tequel ?

[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 ).

[GAujay]

D'après ce que je sais, il y a au moins une raison pour laquelle Google n'utilise pas les exceptions (sur Android, tout du moins).

Comme vous le savez peut-être, le NDK pour Android ne supporte pas officiellement la gestion de la STL, RTTI, et des exceptions. D'après un responsable du projet chez Google (David Turner, si mes souvenirs sont bons), ces spécificités du langage C++ ont volontairement été supprimées car, à l'époque, beaucoup trop gourmande en ressources. En effet, lors des premiers pas du projet, le compilateur utilisé alors était le version 3 (si mes souvenirs sont bons, encore une fois) de GCC. Hors, sur les plateformes mobiles notamment, la compilation des mécanismes d'exceptions étaient tout simplement très mauvaise (taille du binaire beaucoup plus importante, performances largement diminuées, etc). Depuis, la gestion des mécanismes d'exceptions est devenue quasiment "0 cost" (grâce à GCC 4), dixit le même responsable Google.

Je pense donc qu'il s'agissait avant tout d'un choix historique technique, plus que d'une réelle volonté de cadrage de ses développeurs (du moins en ce qui concerne les exceptions). On ne rigole pas avec la portabilité et les performances chez Google ! ^^

[koala01]

D'après ce que je sais, il y a au moins une raison pour laquelle Google n'utilise pas les exceptions (sur Android, tout du moins).

Comme vous le savez peut-être, le NDK pour Android ne supporte pas officiellement la gestion de la STL, RTTI, et des exceptions. D'après un responsable du projet chez Google (David Turner, si mes souvenirs sont bons), ces spécificités du langage C++ ont volontairement été supprimées car, à l'époque, beaucoup trop gourmande en ressources. En effet, lors des premiers pas du projet, le compilateur utilisé alors était le version 3 (si mes souvenirs sont bons, encore une fois) de GCC. Hors, sur les plateformes mobiles notamment, la compilation des mécanismes d'exceptions étaient tout simplement très mauvaise (taille du binaire beaucoup plus importante, performances largement diminuées, etc). Depuis, la gestion des mécanismes d'exceptions est devenue quasiment "0 cost" (grâce à GCC 4), dixit le même responsable Google.

Je pense donc qu'il s'agissait avant tout d'un choix historique technique, plus que d'une réelle volonté de cadrage de ses développeurs (du moins en ce qui concerne les exceptions). On ne rigole pas avec la portabilité et les performances chez Google ! ^^

Bienvenue sur le forum

Le fait est que, si je peux considérer comme logique d'imposer des règles plus ou moins "castratrices" quand elles ont pour but de répondre à des problèmes particuliers dus à une implémentation particulière de compilateur, je trouve pour le moins dommage de ne pas envisager leur abrogation quand on se rend compte que l'évolution du compilateur le permet, simplement parce qu'il s'agit de "règles historiques".

Admettons que les outils, le matériel et l'état de l'art de l'époque ne nous incitent pas à utiliser certains mécanismes.

Il est tout à fait logique de refuser de les utiliser, car il serait irresponsable de faire autrement.

Mais quand on se rend compte, 5, 10 ou 15 ans plus tard, que les outils, le matériel et l'état de l'art ont à ce point évolué que de nouveaux besoins ont vu le jour, peut être est-il opportun d'envisager de passer "à la version supérieure" afin de prendre les différentes évolution en compte, non

Nous en revenons toujours au même point: si, tôt ou tard, il n'était jamais question de revenir sur des décisions qui n'ont plus de raison d'être, nous en serions encore occupés à travailler sur un unique écran en ligne de commande vert sur fond noir

Je ne dis pas, loin de là, que les règles générales doivent être modifiées à tout bout de champs, mais, selon moi, il arrive un moment où un bon dépoussiérage s'avère plus que nécessaire.

Quand on remarque que la version du compilateur supporte (depuis longtemps) des mécanismes particuliers sans imposer de surcout prohibitif, que le matériel devient suffisamment performant pour amortir ce surcout et que l'état de l'art tend à rendre ces mécanismes "naturels", je crois que l'on peut dire que ce moment est arrivé

[Firwen]

En ce qui concerne le refus de l'utilisation des exceptions en C++, Google n'est pas si marginal que ça.
Trolltech/Nokia a la même doctrine pour sa librairie Qt, les principales raisons évoquées sont les problemes rencontrés en cas de bindings vers d'autres langages et les problemes de portabilité avec des devices embarqués.


Pour ma part, je dis oui aux exceptions dans un programme, non dans une bibliothèque.

[Klaim]

Je ne vois pas le problème avec une bibliothèque, au contraire. La plupart des exception que peut soulever le code d'une bibliothèque doit être intercepté en son sein c'est sur, mais certaines doivent quand même être transmises à l'extérieur si le traitement est réellement une "exception" difficile à ignorer.

[benzoben]

Le problème des exceptions (outre peut être le léger surcout de performance que cela entraine) c'est qu'il y a plusieurs façons de les gérer et qui impliquent des philosophies différentes. Pour n'en citer que quelques une:

• Catcher tôt ou laisser remonter jusqu'en haut
• Logger à chaque fois ou pas
• Quelles informations embarquer

De plus, prévoir une bonne hiérarchie d'exception pour couvrir l'ensemble des problèmes potentiels est déjà une gageure. Ou alors faire comme beaucoup, une seule exception générique MonAppException.

[Invité]

Je ne vois pas le problème avec une bibliothèque, au contraire. La plupart des exception que peut soulever le code d'une bibliothèque doit être intercepté en son sein c'est sur, mais certaines doivent quand même être transmises à l'extérieur si le traitement est réellement une "exception" difficile à ignorer.

Peut-être que Google veut faire des bibliothèques qui ne servent pas que depuis C++, avec le même compilo, et qui pourront aller sur de l'embarqué.

[LittleWhite]

Cela dépend des activités envisagés par Google.

Premièrement, peut être utilise t'il une autre convention, pour les nouveaux projets ( ou pas ).
Deuxièmement, peut être que dans les projets futurs, il n'y aura pas d'exception, et que en les enlevant totalement des projets actuels, ils auront un coup de portage plus faible.
On ne sait jamais ...

[JolyLoic]

Je privilégierais plutôt une position intermédiaire qui consiste à ne pas l'utiliser dans l'existant mais à ne pas s'en priver dans les nouveaux projets ou lors des grosses évolutions quitte à attraper toutes les exceptions à la frontière entre les deux mondes et à ne pas les propager.

Dans ce cas, j'utiliserais aussi une règle supplémentaire : Tout nouveau code écrit, qu'il soit dans un projet avec exception ou un projet sans exception, doit gérer les ressources comme si on était dans un projet avec exceptions. Ça ne coûte pas grand-chose, et ça permet de basculer plus facilement plus tard.

[koala01]

Pour commencer, je précise que j'ai la chance de travailler dans un environnement assez libre avec peu de règles rigides.

Je comprends ton point de vue, mais est-ce vraiment très fréquent comme motif de départ (ma question est très sérieuse) ?
De ce que j'ai vu, les causes principales du turn-over sont plutôt le recours massif à la prestation avec l'alternance de période de croissance et de compression et le salaire. Le manque d'intérêt du travail arrivant loin derrière.
Dans un environnement plus "stable", la montée en compétence est effectivement bien plus efficace à terme que des règles trop rigides.

Sinon je rajoute juste une précision que j'avais omise dans mon précédent message (précision que tu avais, je suppose, bien comprise, mais je pense qu'il est préférable d'éclaircir ce point) : le turn-over des équipes peut être une raison réelle de ce type de règles dans certains contextes mais ce n'est bien entendu pas généralisable à toutes les entreprises.
Ce point est d'ailleurs, à mon avis, une constante de la justification des règles de style controversées : ces justifications sont valables dans le cadre où elles ont été écrites mais ne sont pas généralisable. C'est pourquoi je pense qu'elles sont parfois difficiles à admettre et qu'elles ne sont pas transposables d'un secteur d'activité à un autre, d'une entreprise à une autre voire d'un projet à un autre dans la même entreprise.

J'ai longtemps travaillé dans un domaine associatif où l'on demandait au bénévoles un très haut degré de professionnalisme (pour la simple et bonne raison que l'on tenait, littéralement, la vie de gens entre nos mains).

S'il y a une chose que j'ai retenue de cette époque, c'est que l'envie d'évoluer est un moteur très important.

Bien sur, une fois sorti du contexte particulier que peut représenter un milieu associatif, il y a plusieurs raisons qui peuvent inciter (ou non) un employé à rester (car il y a également toute cette partie du turn over qui est due aux dirigeants, et dont il est difficile de parler sans devenir... acerbe), mais, en gros, il y a (entre autres, et pas forcément dans cet ordre):

• Le salaire
• les avantages "extra légaux"
• les horaires
• la distance entre le domicile et le lieu de travail
• l'ambiance de travail
• les possibilités d'évolution
• la reconnaissance du travail effectué (je parle de tout ce qui peut être fait sans que ce ne soit une obligation contractuelle)

Pour ma part, et bien que la question ne se pose plus trop étant donné ma situation, l'ambiance, les possibilités d'évolution et la reconnaissance du travail effectué sont sans doute ce qui pourrait le plus m'inciter à aller voir ailleurs, suivi de près par la distance entre mon domicile et mon lieu de travail (passer trois ou quatre heure dans un train matin et soir, ca devient vite fatigant ) et, à distance égale, il faudrait bien plus qu'une augmentation de cent ou deux cents euros pour que je me laisse dévoyer si l'ambiance est bonne et que mon travail est apprécié "à sa juste valeur".

Par contre, si l'ambiance est "à couteau tirés", que mes perspectives d'évolutions sont limitées (entre autres parce que je n'ai pas les dents assez longues pour m'imposer afin d'obtenir une promotion), ou que l'on estime tout à fait normal que je reste douze heures par jour pendant une semaine afin de finaliser un projet qui a pris un peu de retard, je serais presque d'accord pour aller voir ailleurs malgré un diminution de salaire.

Je fais peut être office d'exception sur ce point, mais combien de vous réagiraient de la même manière

Le gros soucis c'est que 5, 10 ou 15 ans plus tard, tu as une quantité assez importante de code qui ne gère pas cette fonctionnalité (c'est à priori la raison de la règle sur les exceptions chez Google).
Et dans le cas de fonctionnalités comme les exceptions, les introduire dans l'existant risquerait de casser beaucoup de code et tout convertir d'un coup peut être très couteux.

C'est bien pour cela que je parle d'envisager de passer carrément à une version supérieure, avec tout ce que cela peut comporter, mais sans oublier les enseignements du passé

Je sais bien que cela implique un investissement important en temps, mais c'est sans doute également l'occasion de prendre en compte des besoins nouveaux et de nouvelles possibilités d'évolution.

Ceci étant, à titre personnel, je trouve que la règle qui consiste sous ce prétexte à bannir complétement une fonctionnalité est excessive.
Je privilégierais plutôt une position intermédiaire qui consiste à ne pas l'utiliser dans l'existant mais à ne pas s'en priver dans les nouveaux projets ou lors des grosses évolutions quitte à attraper toutes les exceptions à la frontière entre les deux mondes et à ne pas les propager. Mais je ne suis pas sur que ce soit simple à mettre en place dans le cas de grosses équipes.

Effectivement, s'il y a moyen (même si cela peut s'avérer assez difficile à mettre en oeuvre) de prendre les évolutions "récentes" en compte sans devoir "tout casser", il est très certainement préférable de trouver ce "juste milieu"

[gl]

Je fais peut être office d'exception sur ce point, mais combien de vous réagiraient de la même manière

Oh tu n'es pas le seul je te rassures, je vois les choses grosso-modo de la même manière. Et je pense que l'on est plusieurs ici.

Mais de ce que j'ai pu voir dans mon entourage professionnel, ce n'est pas le comportement dominant.

[koala01]

Oh tu n'es pas le seul je te rassures, je vois les choses grosso-modo de la même manière. Et je pense que l'on est plusieurs ici.

Je n'étais pas *trop* inquiet sur ce point

Mais de ce que j'ai pu voir dans mon entourage professionnel, ce n'est pas le comportement dominant.

Cela a peut être un coté un peu dommage, non (du moins dés que le salaire est un minimum correct et permet de vivre honnêtement )... Mais nous ferions sans doute bien d'éviter d'essayer de refaire le monde ici

[ox223252]

Aujourd'hui je viens de me faire gronder car mes accolade sont sur une ligne vide et car mes indentation sont de d'une tabulation, alors que c'est pas ce qui est marqué dans les regles google (non je ne travail pas chez google et le projet ne suit pas de regles particulière )

Je me demande qui à pondu les règles googles, je me demande si il programmes , car après 10h sur mon éditeur de texe une indentation de deux espaces et illisible ^^.

Sinon plus globalement j'ai travaillé pour des projets dans le militaire et dans le médicale, et je peux vous garantir que les règles google ils s'en tamponnes, pour eux ce qui compte c'est la simplicité et la lisibilié du truc qui compte vaiment. Et quand on voit leurs raisons on peut se dire qu'ils ont raison.

par exemple ça ils en veulent pas :

Code :

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

if(test==0&&truc>2)machin=3;

c'est remplacé par ça :

Code :

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

1
2
3
4
if ( ( l_uiTest == 0 ) && ( l_uiTruc > 2 ) )
{
	l_uiMachin = 3;
}

Ca c'est vérifié par un logiciel et tout code qui ne correspont pas aux éxigences doit être éxpliqué et justifié, car la vie de gens est en jeux derrière