Discussion :

[Joel F]

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 ?

[Klaim]

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

[gl]

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

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.

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

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.

[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

[ruste]

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!

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 :

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

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)
{ ... }

[ptyxs]

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

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

[Goten]

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

[dvdbly]

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

Aha ! Héhé !

[dvdbly]

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 !

[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?

[nikko34]

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.

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

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.

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

[Joel F]

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.

[Goten]

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 .

[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

[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"