Règle de codage chez google

Version imprimable

Voir 40 message(s) de cette discussion en une page

10/05/2010, 18h02
Joel F

Citation:

Envoyé par benzoben

Je suis tout a fait d'accord.
Je ne suis pas du tout contre les exceptions bien au contraire. Mais c'est vrai qu'à partir d'une certaine taille de projet, il faut malheureusement un peu "museler" les individualités pour le bien de tous. Car passer du temps à debugger le bout de code optimisé aux petits oignons et dont seul l'auteur a su ce qu'il voulait faire, eh bien, des fois c'est pas possible.

Lui apprendre à commenter/documenter/tester serait peut etre mieux pour tout le monde ?
10/05/2010, 18h04
Klaim

Citation:

Même dans son périmètre (donc indépendamment de son contenu), la convention Google est très laxiste. En particulier, rien n'est figé sur des points aussi variés et importants que le multitâche, l'historique des fichiers sources, les protocoles de test d'unité, les invariants, les ABI dans les architectures matérielles mixtes, la politique de gestion des latences matérielles, etc. Ceci dit, peut-être y a-t-il d'autres documents pour ces points, j'avoue ne pas avoir regardé.

A mon avis il doit y avoir des directives différentes pour chaque projet... Mais je n'ai pas plus d'infos concrètes.

Sinon je suis d'accord aussi avec le reste, d'ailleurs j'ai tendance a me remoraliser de projets avec features coupées (pas de boost, stl réduite, heritage multiple interdit, templates vus de travers, etc) avec mes projets perso, sous windows avec visual studio. Ca fais du bien au cerveau :)
10/05/2010, 22h03
gl

Citation:

Envoyé par koala01

Mais, d'une certaine manière, n'est ce pas aussi une possibilité de limiter le turn over que d'essayer de faire évoluer ceux qui acceptent les remarques constructives :question:

Il est clair qu'un type manquant de compétence à qui on dit, sans vraiment pousser la caricature, "tu es incompétant, mais trop con pour qu'on essaye de te faire évoluer" ou qu'un autre à qui l'on dit, sans pousser d'avantage la caricature : " c'est bien, tu es compétant, mais nous ne sommes pas intéressé par le fait que tu essaye de transmettre ton savoir" n'auront que très peu envie de rester...

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.

Citation:

Envoyé par koala01

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 :question:

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.

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.
10/05/2010, 23h00
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 :D ).
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 ...
10/05/2010, 23h04
JolyLoic

Citation:

Envoyé par gl

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.
10/05/2010, 23h16
koala01
Citation:

Envoyé par gl

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 :aie:) 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 :question: :D:P

Citation:

Envoyé par gl

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.

Citation:

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" ;)
11/05/2010, 00h46
gl

Citation:

Envoyé par koala01

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

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.
11/05/2010, 00h52
koala01

Citation:

Envoyé par gl

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 :D

Citation:

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 :question: (du moins dés que le salaire est un minimum correct et permet de vivre honnêtement :aie:)... Mais nous ferions sans doute bien d'éviter d'essayer de refaire le monde ici :D

Les exceptions

C'est vrai qu'il y a lieu de se demander si les exceptions devraient être utilisées.

Pour: le fait de pouvoir coder la séquence logique d'une procédure, puis traiter les exception exceptionnellement. C'est simplement logique. La séquence est plus facile à lire et à corriger.

Contre: les fonctions qui peuvent retourner des exceptions ne se voient pas à l'oeil, même quand c'est codé by the book. Si on est pas équippé par un outil de programmation (genre NetBeans ou Eclipse en Java) qui nous aidera à identifier quel fonction utilisée retourne quoi et quelle exception a besoin d'être retournée, ça peut être un travail quelque peu ardu. Si on est pris pour vérifier le code d'un autre, c'est encore pire. Pour programmer régulièrement du Java, je peux dire que les erreurs générique retournée par des exceptions génériques, qui retournent une erreur du genre «Une erreur s'est produite, bonne chance!», c'est asser frustrant merci! :aie:

Mais je crois qu'il faut considérer malgré tout que le language de programmation est une forme de language mathématique qui combine la logique booléenne avec le calcul.

D'une certaine façon, on peut dire que le language C a coupé les coins rond en utilisant des fonctions pour éviter d'implémenter le concept de procédure. Mathématiquement, une fonction f(x) = y devrait toujours retourner une valeur qui varient en fonction des valeurs données en entrée. Le C s'est permi de définir une procédure comme une fonction f(x) = void, ce qui me parait comme un choix de design asser ordinaire. Le même problème se présente avec les erreurs qui sont retournées par une fonction: on peut se demander si d'écrire f(x) = -1 (erreur) ou f(x) >= 0 (pas d'erreur) est mathématiquement correct.

Il me semble donc à moi que c'est ici que le débat devrait se dérouler. Dans cette perspective, l'exception est tout à fait appropriée aux procédures. Il peut servir aussi pour les fonction si un problème survient qui forcerait la fonction à retourner une valeur inconsistante. Contraiement à Google, moi c'est plutôt le fait pour une fonction de retourner un statut que je remet en question.

De mon point de vue, un code adéquat serait plutôt du genre:
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 #define proc void int add(int x, int y) { return x + y; } fstream ouvrirf(string nom) throw (err_inexistant) { fstream f(nom); if (!f) throw err_inexistant; return f; } proc renommerf (string nom) throw (err_inexistant) { ... }

14/05/2010, 21h10
ptyxs

Citation:

Envoyé par Goten

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

Citation:

Envoyé par dvdbly

C'est quoi un tequel ?

Notre ami voulait parler d'un teckel (les programmeurs, pour ce qui est du code orthographique, ça laisse encore à désirer:mrgreen:...)
14/05/2010, 23h59
Goten

Moi je voulais parler de rien, je me suis contenté de quoter. Mais brefle, passons.
15/05/2010, 10h40
dvdbly

Citation:

Envoyé par ptyxs

Notre ami voulait parler d'un teckel (les programmeurs, pour ce qui est du code orthographique, ça laisse encore à désirer:mrgreen:...)

Aha ! Héhé !
15/05/2010, 10h49
dvdbly

Citation:

Envoyé par Goten

Moi je voulais parler de rien, je me suis contenté de quoter. Mais brefle, passons.

Oui... mais tu n'es pas forcément l'ami mentionné... puisque j'avais "quoté" ta "quotation".

Cela dit, tu avais raison : elle est bien bonne celle du teckel lapon, et je dois avouer que je la ressortirai avec plaisir dès que l'occasion se présentera !
28/05/2010, 15h36
reptils

mouais... pas trop choqué par ce que j'ai lu. Il faut voir qu'il y a tellement(trop?) de degré de liberté en C++ qu'il faut imposer des règles pour éviter des codes hétérogènes.
Dans le cas où on se fait un projet à soit, ces règles n'ont vraiment lieu d'être, mais pour un développement en équipe... c'est une autre histoire.

En ce qui me concerne, je n'utilise jamais les stream du C++ étant donnée les perfs déplorables. *printf au lieu de *stream etc.

Question, pourquoi les gens n'utilisent que très peu les exceptions?
28/05/2010, 17h01
nikko34

Citation:

Envoyé par reptils

mouais... pas trop choqué par ce que j'ai lu. Il faut
Dans le cas où on se fait un projet à soit, ces règles n'ont vraiment lieu d'être, mais pour un développement en équipe... c'est une autre histoire.

bah... je citerais Edsger Dijkstra:

Don't blame me for the fact that competent programming, as I view it as an intellectual possibility, will be too difficult for 'the average programmer', you must not fall into the trap of rejecting a surgical technique because it is beyond the capabilities of the barber in his shop around the corner.
Edsger Dijkstra

En gros, c'est pas parce que le coiffeur du coin ne sait pas le faire qu'on doit rejeter une technique de chirurgie.

Mais bon, hein, moi je suis bien content de bosser dans une équipe où tout le monde comprenne assez le C++ pour qu'on puisse utiliser ce qui nous va.

Citation:

En ce qui me concerne, je n'utilise jamais les stream du C++ étant donnée les perfs déplorables. *printf au lieu de *stream etc.

bah si ce sont les perfs le problème, utilise boost::lexical_cast<>() ou boost::spirit, ils ont des meilleures perfs maintenant :)

http://tinodidriksen.com/2010/02/07/...-string-speed/
http://www.boost.org/doc/libs/1_43_0...rformance.html

Citation:

Question, pourquoi les gens n'utilisent que très peu les exceptions?

Je crois que la plupart des gens les utilisent. Mais souvent ils n'en font pas de nouvelles et se retrouve avec un tas de code d'erreurs dans leur propre fonctions. En Java ça doit être pareil, sauf qu'ils sont obligés de les catcher.
01/06/2010, 12h27
screetch

le coiffeur du coin ne travaille pas en équipe...
la propriété principale du code d'entreprise (par rapport au code qu'on fait a la maison) c'est qu'il est relu beaucoup plus souvent qu'il n'est écrit, par beaucoup plus de personnes.
les normes de codages sont là pour ca, et ce n'est pas a nous de juger.
01/06/2010, 19h44
Joel F

Citation:

Envoyé par screetch

les normes de codages sont là pour ca, et ce n'est pas a nous de juger.

sauf que la elle sont plus que restrictives et sont basées sur une quantité de FUD impressionnante.
01/06/2010, 19h52
Goten

Citation:

Envoyé par screetch

les normes de codages sont là pour ca, et ce n'est pas a nous de juger.

Non mais on peut les commenter et en débattre :).
01/06/2010, 20h28
koala01

Je ne pourrais pas être plus d'accord avec joel ou avec Goten...

Nous sommes tous bien conscients du fait que les règles de codages doivent exister, et qu'il faut "flinguer à vue" tout ce qui s'en écarte, que ce soit en terme de convention d'écriture / de "mise en forme" du code, de convention de nommage, de présentation de commentaires ou de tolérance à ce que j'appellerais les "sucres syntaxiques".

Si l'on souhaite que tout le monde puisse lire "aussi facilement que possible" le code de n'importe qui, si l'on veut éviter toute méprise, l'absolue nécessité des règles de codage ne fait strictement aucun doute.

Par contre, si les règles de codage rejettent des pans entiers du langage pour ce qui n'est généralement plus que des "légendes urbaines" (ou peu s'en faut), qu'elles ont pour résultat un "nivellement par le bas", ou d' "institutionnaliser" des approches qui rendent le développement plus compliqué que ce qu'il ne devrait être sans pour autant améliorer ( pour ne pas dire en diminuant) la qualité du code produit ou du développement, il faut aussi pouvoir débattre des points noirs et défendre son point de vue, avec l'espoir de faire évoluer les choses vers une meilleure situation.

Nous sommes tous conscients que ce n'est sans doute pas une personne seule qui arrivera à faire bouger la "montage bureaucratique" que peut représenter une société comme google (ou comme toute autre société utilisant des règles de codage aussi précise), mais, il ne faut pas oublier que ce sont les petits ruisseaux qui forment les grands fleuve: si ceux qui peuvent justifier de l'inopportunité d'une règle parlent "d'une même voix" et "tiennent le cap", elles ont malgré tout une chance d'atteindre et de convaincre quelqu'un qui pourra faire changer les choses.

Le lobbying a toujours existé et a souvent été utilisé, non :question:
01/06/2010, 21h58
JolyLoic

Sans parler de "faire bouger google", en discuter, et critiquer éventuellement, peut avoir comme impact d'éviter que des telles règles soient reconduites dans un environnement où elles seraient encore moins appropriées, simplement parce que "si google fait comme ça, ça doit être bien"
01/06/2010, 22h12
nikko34

Citation:

Envoyé par JolyLoic

Sans parler de "faire bouger google", en discuter, et critiquer éventuellement, peut avoir comme impact d'éviter que des telles règles soient reconduites dans un environnement où elles seraient encore moins appropriées, simplement parce que "si google fait comme ça, ça doit être bien"

c'est à dire, dans des endroits où on est susceptibles de travailler :)
02/06/2010, 05h19
koala01

Citation:

Envoyé par JolyLoic

Sans parler de "faire bouger google", en discuter, et critiquer éventuellement, peut avoir comme impact d'éviter que des telles règles soient reconduites dans un environnement où elles seraient encore moins appropriées, simplement parce que "si google fait comme ça, ça doit être bien"

Je crois effectivement que c'est ça le plus important: il faut se rendre compte que même les plus grands ne sont pas à l'abri d'une erreur, à tel point qu'un auteur bien connu a fait dire à un de ses héros:

Citation:

je suis plus intelligent que les autres, mes erreurs n'en sont que plus graves

Oui, de grosses boites font des choses qui peuvent ne pas être bonnes, oui de grands noms peuvent proposer des solutions qu'ils ne devraient pas (le coup de la boucle for( ; ; ) ), ...

Débattre de ces "inepties" (même si le terme est peut être un peu fort, il faut l'avouer) permet de faire évoluer les mentalités à tous les niveaux, et c'est le principal :D
02/06/2010, 12h31
screetch

ca fait de nombreuses fois que je lis "nivellement par le bas" dans ce genre de discussion et il me semble souvent qu'on crie au loup pour pas grand chose. La vous vous scandalisez (ne niez pas, même que vous vous moquez) et prenez des gens (inconnus...) de haut pour critiquer leurs intentions potentielles. Vos critiques sont en fait remplies d'extrapolations sur un document dont on ne connait ni l'auteur, ni les cibles, ni les conditions d'applications. OK pour debattre, mais au moins sur du concret... la j'avais plutot l'impression que vous ressassez de vieilles rancoeurs en prenant ce document a témoin.

Et si vous ne travaillez pas a google, pourquoi voulez vous donc qu'ils adoptent vos regles de codage a vous? j'ai du mal a suivre cela...
02/06/2010, 13h10
koala01

Citation:

Envoyé par screetch

ca fait de nombreuses fois que je lis "nivellement par le bas" dans ce genre de discussion et il me semble souvent qu'on crie au loup pour pas grand chose. La vous vous scandalisez (ne niez pas, même que vous vous moquez) et prenez des gens (inconnus...) de haut pour critiquer leurs intentions potentielles. Vos critiques sont en fait remplies d'extrapolations sur un document dont on ne connait ni l'auteur, ni les cibles, ni les conditions d'applications.

Il n'y a aucune extrapolation, juste une constatation de fait:

Quand on lit que google demande de ne pas utiliser un constructeur mais plutôt une fonction init, c'est un fait.

Le résultat est un "nivellement vers le bas" qui incite les gens à écrire du C with classes au lieu d'appliquer le principe du RAII, et de tous les avantages qu'il apporte.

Quand on lit que google demande de ne pas utiliser les exceptions, c'est aussi un fait.

On ne nie absolument pas qu'une telle décision puisse avoir été justifiée à une certaine époque, mais, maintenant, elle n'a plus lieu d'être, et, encore une fois, elle permet à des développeurs de se passer d'un pan entier des possibilités du langage.

Encore une fois, il s'agit donc bel et bien... d'un nivellement vers le bas, vu que tout est fait pour que cela permette à tous les développeurs qui sont de se "complaire" dans leur ignorance, sans essayer de s'améliorer.

Nous avons la chance d'utiliser un langage très riche et permettant énormément de choses.

Nous sommes conscients (du moins, je le suis personnellement) que cela apporte autant d'avantages que d'inconvénients, ne serait-ce que ce que l'on gagne en souplesse d'utilisation en le perd assez facilement en "risques potentiels" parfois très bien cachés.

Mais, quand on voit la facilité avec laquelle il est possible de créer des applications au moins aussi merdiques avec les langages qui ne proposent pas ces possibilités, et qu'il est tout à fait possible de trouver (pas forcément chez google, mais dans d'autres boites, petites ou grandes, utilisant principalement ces autres langages) des règles de codages qui "castrent" le développeur un tant soit peu consciencieux, on ne peut s'empêcher d'estimer que leu seul résultat probant de cette "castration" est... de ne surtout pas inciter le développeur à s'améliorer.

On peut (on devrait) bien sur se poser la question de savoir pourquoi tant de développeurs méconnaissent un langage que beaucoup prétendent pourtant maitriser (et je ne parle, malheureusement, pas seulement de C++), mais une chose est certaine: les règles que l'on critique ne font rien pour arranger les choses.

Citation:

OK pour debattre, mais au moins sur du concret... la j'avais plutot l'impression que vous ressassez de vieilles rancoeurs en prenant ce document a témoin.

Il n'y a pas la moindre rancoeur (du moins dans mon chef) à y voir: il y a une critique de "l'immobilisme" de la politique d'une boite qui a le malheur d'être connue et... de présenter un document critiquable :D

Citation:

Et si vous ne travaillez pas a google, pourquoi voulez vous donc qu'ils adoptent vos regles de codage a vous? j'ai du mal a suivre cela...

On apprécierait qu'ils adaptent leur règles de codage, simplement parce que c'est un document qui risque de... faire référence sous prétexte que "si google les utilise, elles sont forcément bonnes".

Or, si on est globalement d'accord avec la plupart, il y en a d'autres qui... démontrent au mieux une connaissance "obsolète", au pire, une méconnaissance du langage de la part de celui qui les a écrite, voir une vaine tentative de permettre à toute personne incompétente de faire du boulot plus ou moins acceptable.

Plutôt que d'accepter que les gens "passables" se complaisent dans leur état, une telle société (comme toute société d'ailleurs) devrait au contraire tenter de tirer ses collaborateurs vers le haut en les incitant à s'améliorer, quitte à dégraisser ceux qui refusent obstinément de le faire ;)

Au final, nous arriverions peut-être à redorer le blason du développeur et à faire en sorte que les sociétés ne se basent plus uniquement leur recherche de développeurs parmi les bac +5 ou bac +10 pour un simple "pisseur de code".
02/06/2010, 15h19
screetch

tu extrapoles. tu parles de "google" comme si les secrétaires étaient tenues de réspecter ce style de codage aussi.
02/06/2010, 15h33
Klaim

Je pensais que plusieurs points de cette convention n'étaient valables que pour les anciennes applications et les applications basées sur ces anciennes applications, par sur les toutes nouvelles applications.

Il faudrait quelqu'un (plusieurs personnes séparées dans l'idéal) de chez google pour nous dire comment ça se passe concretement au niveau du C++ surtout (si ils ont le droit d'en parler du moins).
02/06/2010, 15h51
white_tentacle

Citation:

tu extrapoles. tu parles de "google" comme si les secrétaires étaient tenues de réspecter ce style de codage aussi.

Moi je lis ça :

Citation:

C++ is the main development language used by many of Google's open-source projects. As every C++ programmer knows, the language has many powerful features, but this power brings with it complexity, which in turn can make code more bug-prone and harder to read and maintain.

The goal of this guide is to manage this complexity by describing in detail the dos and don'ts of writing C++ code. These rules exist to keep the code base manageable while still allowing coders to use C++ language features productively.

Citation:

Another issue this guide addresses is that of C++ feature bloat. C++ is a huge language with many advanced features. In some cases we constrain, or even ban, use of certain features. We do this to keep code simple and to avoid the various common errors and problems that these features can cause. This guide lists these features and explains why their use is restricted.

Non, clairement, le type qui a écrit ce document n'aime pas le c++ moderne :)
02/06/2010, 15h56
Mat.M
Citation:

Envoyé par koala01

Il n'y a aucune extrapolation, juste une constatation de fait:

Quand on lit que google demande de ne pas utiliser un constructeur mais plutôt une fonction init, c'est un fait.

Le résultat est un "nivellement vers le bas" qui incite les gens à écrire du C with classes au lieu d'appliquer le principe du RAII, et de tous les avantages qu'il apporte.

Quand on lit que google demande de ne pas utiliser les exceptions, c'est aussi un fait.

Je suis d'accord :D cependant cela peut-être discutable

-les exceptions n'interceptent pas toujours les "plantages" notamment s'il y a un effet de bord
-cela risque de ralentir les performances ( notamment pour un jeu vidéo comme l'ont précisé mes prédecesseurs)
-par contre niveau lisibilité et code constructif/hiérarchisé c'est mieux

Pour le constructeur d'une classe/méthode init() c'est vrai que c'est un peu faire du C wih classes :mouarf:
Le petit avantage d'une méthode init c'est que c'est plus lisible.
Et puis le gros inconvénient du méchanisme d'appel du constructeur c'est qu'il est appelé quand on n'en a pas envie...
par exemple si je déclare une classe "sur la pile" dans une fonction, le constructeur de la classe va être appelé obligatoirement
Code:

1 2 3 4 5 6 void FonctionQuelconque() { MaClasse classe;//<- appel implicite du constructeur. Et si on ne veut pas ? }
02/06/2010, 16h26
DesignFirst

A mon avis avant de critiquer ces regles de codage , il faut au moins récupérer un code source d'un projet de google et voir la qualité du code et le résultat de l'application de ces regles.

si par exemple vous scruter le code source du browser chrome, le constat est que le code est clean , trés clair, bcp de design pattern sont utilisés et pour le RAII ils ont un mécanisme plus poussé pour gérer la mémoire qui apporte plus de clarté et augmentation de perf, et je trouve d'ailleurs dommage qu'on ne peut pas isoler leur system de GC dans une dll a part pour l'utiliser dans d'autres projets.

et pour moi le nivellement vers le bas c'est lorsqu'on fixe la barre très haut et que personne n'arrive a sa hauteur sauf peut etre un guru ou 2 dans l'équipe ce qui engendre un code quasiment illisible.

Citation:

Envoyé par Mat.M

par exemple si je déclare une classe "sur la pile" dans une fonction, le constructeur de la classe va être appelé obligatoirement

C'est, en effet, le but du constructeur :D

Citation:

Code:

1
2
3
4
5
6
 
void FonctionQuelconque()
{
MaClasse classe;//<- appel implicite du constructeur. Et si on ne veut pas ?
 
}

Prenons le cas contraire: une classe pour laquelle un constructeur ne prenant pas d'argument n'a aucun sens:

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
Person
{
    public:
        /* pas de constructeur défini... un constructeur est ajouté par défaut
         * ... il est tout à fait normal d'avoir un personne dont 
         * le nom et le prénom prennent la valeur de... "", n'est-ce pas ?
         */
        void init(std::string const & n, std::string const & f)
        {
            /* Pour éviter d'en arriver à renommer Jean Dupont en
             * Jules Durant, on est maintenant obligé... de tester
             * la cohérence de la tentative d'initialisation :-P
             */
            if(name_=="" && firstname_="")
            {
                name_=n;
                firstname_=f;
            }
            else
            {
                throw allreadyInisalized(); // mince, c'est vrai... 
                                            // pas d'exceptions
            }
        }
    private:
        std::string name_;
        std::string firstname_;
};

Il est clair que la fonction init simplifie tout, hein :question: :D

02/06/2010, 16h34
Goten

Citation:

si par exemple vous scruter le code source du browser chrome, le constat est que le code est clean , trés clair, bcp de design pattern sont utilisés et pour le RAII ils ont un mécanisme plus poussé pour gérer la mémoire qui apporte plus de clarté et augmentation de perf, et je trouve d'ailleurs dommage qu'on ne peut pas isoler leur system de GC dans une dll a part pour l'utiliser dans d'autres projets.

Si leur "mécanisme plus poussé" est un GC comme tu as l'air de dire alors ... sa va juste faire couler encore plus d'encre :').
02/06/2010, 16h42
koala01

Citation:

Envoyé par DesignFirst

et pour moi le nivellement vers le bas c'est lorsqu'on fixe la barre très haut et que personne n'arrive a sa hauteur sauf peut etre un guru ou 2 dans l'équipe ce qui engendre un code quasiment illisible.

Justement, ca c'est l'effet inverse: un nivellement (tout aussi honteux que l'autre, d'ailleurs) vers le haut... surtout s'il est dans la politique de la maison de virer systématiquement toute personne incapable de s'adapter dans un délais donné ;)

Le nivellement vers le bas, ca consiste à permettre à des gens qui ne sont réellement pas compétents (quelle que soit l'origine de leur incompétence) de croire qu'ils sont capables d'écrire un code correct et "bullets proof", même si la seule expérience du langage qu'ils ont est le fait d'avoir suivi un cours ou un tuto (dont il faut avouer que la qualité moyenne est plutôt basse, même si on en rencontre quelques bons, parfois, presque par hasard :aie:).

Si tu n'incite pas les gens à s'initier à des techniques trop rarement vues en cours, et trop rarement correctement expliquées dans les tutos que l'on peut trouver, comment veux tu avoir la moindre chance de les faire évoluer :question:
02/06/2010, 16h43
DesignFirst

Citation:

Envoyé par Goten

Si leur "mécanisme plus poussé" est un GC comme tu as l'air de dire alors ... sa va juste faire couler encore plus d'encre :').

C'est pas moi qui le dis :) cherche juste V8 GC et tu trouveras plus de détail sur le sujet. c'est parmi les facteurs que google met en avant pour expliquer la rapidité et la robustesse de leur moteur JavaScript.

et t'a raison on va pas entrer dans un debat de GC , ca se terminera jamais :)
mais c'était juste pour dire qu'ils ont un mécanisme qui gere la memoire qui marche trés bien et on va pas les reprocher un nivellement vers le bas parce qu'ils n'utilisent pas RAII.
02/06/2010, 17h25
screetch

Si chrome a un code C++ moderne, c'est bien que les regles de codage citées plus haut:
- soit n'entrave pas la qualité de codage
- soit ne sont simplement pas appliquées
c'est un peu ce que je critique: on fait beaucoup de bruit ici sur un document dont on ne connait rien.

Je vois mal les gens prendre ce document en exemple car il est franchement difficile d'accès; c'est pas le premier pequenot venu qui va aller le trouver sur le net.

j'ai l'impression que ce fil de discussion se bat contre des moulins a vent...
02/06/2010, 18h05
koala01

Citation:

Envoyé par screetch

c'est un peu ce que je critique: on fait beaucoup de bruit ici sur un document dont on ne connait rien.

j'ai l'impression que ce fil de discussion se bat contre des moulins a vent...

c'est, de manière générale, le cas d'à peu près tous les débats qui se déroulent sans qu'une personne ayant autorité pour répondre ne prenne part à la disucssion ;) (et, de manière quasi systématique lorsqu'il s'agit de confronter des idées dans le domaine de l'informatique :D)

Mais, si ce débat permet à ne serait-ce qu'une personne de se faire un avis sur les règles qu'il devrait (faire) appliquer dans son équipe, ce sera déjà ca de gagné ;)

Citation:

Si chrome a un code C++ moderne, c'est bien que les regles de codage citées plus haut:
- soit n'entrave pas la qualité de codage

Il serait déjà possible de se "friter" rien que sur cette phrase...

Qu'appelle tu "qualité de codage" :question:

Est-ce, simplement, la facilité avec laquelle "les autres" arriveront à relire un code qu'ils n'ont pas écrit, ou insères tu dans ce critère de qualité la facilité (ou le niveau de difficulté) que l'on rencontre pour obtenir un résultat rendu difficile par les règles de codages :question:

Dans le premier cas, les seules règles de "mise en forme" suffisent, dans l'autre, je serais tenté de dire que, justement ces règles nuisent à la qualité de codage ;)

Citation:

- soit ne sont simplement pas appliquées

J'ai le sentiment très net que, chez google, ils seraient tout à fait capables de "tirer à vue" sur tout document qui ne les respecte pas :aie:

Citation:

Je vois mal les gens prendre ce document en exemple car il est franchement difficile d'accès; c'est pas le premier pequenot venu qui va aller le trouver sur le net.

Tu serais bien surpris :aie:

Il n'est pas particulièrement difficile à trouver, et tu peux compter sur pas mal de gens pour suivre le raisonnement contre lequel je mets en garde plus haut:

Citation:

c'est forcément le mieux en la matière, vu que c'est google qui les a mises au point

car, comme je l'ai déjà dit, même les plus grands sont capables de dire des bêtises :D
02/06/2010, 18h17
Klaim

Citation:

Il n'est pas particulièrement difficile à trouver

En fait, il a même été mis en avant au moins deux fois via des news sur Slashdot et autres relais d'informations "geek" et programmation.
03/06/2010, 09h16
white_tentacle

Citation:

Envoyé par DesignFirst

C'est pas moi qui le dis :) cherche juste V8 GC et tu trouveras plus de détail sur le sujet. c'est parmi les facteurs que google met en avant pour expliquer la rapidité et la robustesse de leur moteur JavaScript.

Pour moi, c'était plus le fait que tout le code javascript soit compilé en natif (jit) qui expliquait les performances de V8.

Citation:

et t'a raison on va pas entrer dans un debat de GC , ca se terminera jamais :)
mais c'était juste pour dire qu'ils ont un mécanisme qui gere la memoire qui marche trés bien et on va pas les reprocher un nivellement vers le bas parce qu'ils n'utilisent pas RAII.

Javascript (le langage) impose un GC (aucun moyen de faire autrement). Donc c'est logique que V8 contienne un GC. Ca ne veut pas dire que tous les objets utilisés dans le code de Chrome soient garbage collectés, et qu'il faut se passer de RAII.

Pour le reste, je n'ai pas l'impression que Chrome soit au-dessus des autres en terme de stabilité/robustesse/nombre de bugs (ce qui, à mon avis, serait un des meilleurs arguments en faveur de ces règles de codage).

Enfin, j'ai parcouru rapidement le code de chromium, peut-être que ce que j'y ai vu n'est pas représentatif, mais j'y trouve les mêmes écueils que dans tout le code que je vois d'habitude :
- aucun contrats
- noms de fonction parfois stupide (par exemple, Order pour une fonction de compariason)

En revanche, il m'a l'air relativement bien documenté (plus que toutes les règles de codage, c'est probablement ça qui fait qu'il est clair et accessible).
03/06/2010, 11h05
reptils

Citation:

Envoyé par white_tentacle

Non, clairement, le type qui a écrit ce document n'aime pas le c++ moderne :)

Perso j'en fais parti...
Après ça vient certainement du fait que je fais du calcul scientifique et qu'il faut avoir une limite très ferme à l'OO. A trop en mettre on perd la lisibilité des equations, de la problématique qu'on traite (et surtout l'optimisation). A ne pas en mettre on perd de la flexibilité. Il faut placer un curseur.

Par contre là où les règles de prog de google préconisent de ne pas utiliser alloca, ben moi j'en ai super besoin...

Mais comme je disais dans mon premier message: ces règles ne me choquent pas tant qu'elles sont consistantes entre elles.

Pour finir je pense que:
Ce n'est pas parce que tu as une voiture qui peut rouler à 200km/h que tu dois rouler en toutes circonstances à 200km/h.
Sauf si tu es tout seul sur autoroute. Mais dans le cas cité (développement en équipe) il faut donc des règles pour que tout le monde circule sans danger, et arrive sein et sauf. (130km/h c'est bien).
03/06/2010, 11h25
nikko34

ah non, pas consistantes, cohérentes :P

Bah ce qu'on essaye juste de dire c'est que à faire des normes de codages sévères, on s'empêche d'aller à 200 km/h quand on en a besoin..
03/06/2010, 11h26
Goten

Citation:

Après ça vient certainement du fait que je fais du calcul scientifique et qu'il faut avoir une limite très ferme à l'OO.

C++ modern ne veut pas dire OO (j'ai même envie de dire, au contraire).

Voir 40 message(s) de cette discussion en une page