Version imprimable
Non, pas du tout...Citation:
Envoy� par camboui
Par principe, tu dois te dire que tout ce qui apparait dans un fichier d'en-t�te t'est accessible, point barre.
Si, pour une raison ou une autre, le d�veloppeur avait voulu limiter la connaissance que tu as d'une classe ou d'une fonction, il se serait arrang� pour ne pas te fournir le fichier d'en-t�te dans lequel la classe est d�finie ou la fonction d�clar�e.
Attention, je veux bien faire avec les deux "cercles" dont tu parles... Mais �a d�pend surtout d'o�. Aussi, j'estime que n'importe quel dev doit savoir lire une doc, donc que mon idiot-proofisation (oO) ne se limite qu'� cela dans la majeur partie des cas.Citation:
Envoy� par koala01
De l'autre c�t�, il parait �vident que je ne vais pas fournir tous les ingr�dients de ma recettes au gens qui n'en ont pas besoin, surtout s'il est dangereux de jouer avec.
Dans le monde de bambi, o� tout le monde il est beau, tout le monde il est gentil, et o� tous les d�veloppeurs ils sont comp�tents, oui...Citation:
Envoy� par Lavock
Seulement, cette vision idyllique est contredite par les faits.
Dans les faits, combien de d�veloppeurs sont (je le pense r�ellement) incomp�tents ou ne lisent jamais la doc qui leur est fournie (ou du moins, jamais suffisamment en profondeur pour en comprendre tous les rouages :question:)
Et, dans les faits, quel impact pourra avoir la seule ligne proche de
m�me si elle est mise en �vidence par tous les moyens possibles et imaginables, si elle est noy�e dans 150 pages de doc :question:Citation:
attention cette classe est � usage interne uniquement, ne l'utilisez pas � des fins personnelles
Alors, oui, dans l'absolu, ce devrait �tre suffisant, mais, en pratique, s'il y a moyen d'apporter une s�curit� suppl�mentaire, il peut sembler opportun d'en profiter ;)
[EDIT]Et je vais m�me aller plus loin.
M�me le d�veloppeur comp�tent qui a pris soin d'�tudier la doc en profondeur ne va pas s'y r�f�rer de mani�re syst�matique pour �crire la moindre ligne de code.
Or, le temps passant, les souvenirs s'estompent ou s'alt�rent toujours peu ou prou.
M�me ce d�veloppeur peut donc, � un moment donn�, en arriver � "vaguement se souvenir qu'il �tait question de telle classe" et vouloir l'utiliser, alors que, s'il en �tait effectivement question dans la doc, c'�tait pour clairement stipuler qu'il ne fallait pas s'en servir...
[/EDIT]
Sur ce point, nous sommes d'accord :DCitation:
De l'autre c�t�, il parait �vident que je ne vais pas fournir tous les ingr�dients de ma recettes au gens qui n'en ont pas besoin, surtout s'il est dangereux de jouer avec.
:piou:Citation:
Envoy� par koala01
Sans parler du pr�sent exemple, je pense que nivel� par le bas, c'est encourag� la m�diocrit�. Si un dev est trop b�te pour lire une doc, alors oui il lui faut une biblioth�que idiot-proof. Mais c'est quand m�me bien dommage >< !Citation:
Envoy� par koala01
pour les classes internes, je compare ca au dynamic_cast. Tout le monde comprend que utiliser dynamic_cast pour "tester" le type exact d'un objet et effectuer une action diff�rente est "mal".
mais aller taper la classe "helper" interne, tout le monde semble me dire "si ca doit arriver il faut le laisser faire".
ben moi je dis non, c'est la meme chose;
j'ai l'impression de devenir de plus en plus integriste avec l'age... c'est mal ? :s
les gens ne sont pas idiots... mais pour le cas du mutex, meme si on conseille d'utiliser le ScopedMutexLock au lieu du Mutex directement, les gens qui lisent le fichier en-t�te verront le mutex et pas forc�ment la classe helper (qui est plus bas). Et pis c'est aussi plus naturel d'utiliser un Mutex lorsqu'on est nouveau sur le projet.Citation:
Envoy� par Lavock
Mais supposons qu'un SECOND programmeur, toujours tr�s comp�tent, vienne dans une fonction, lise le code et d�cide de rajouter un "if(finished) return;" au milieu, sans voir le mutex. Soudainement tout se casse, et c'est pas faute d'avoir pas lu la doc ou d'avoir utilis� le mauvais outil;
80% des bugs sont des bugs "collectifs", ils apparaissent dans le code ecrit par A dans une partie obscur du logiciel, parce qu'un individu B a chang� le code de C dans une partie compl�tement differente.
Par exemple chez nous, le logiciel s'est mis a plant� dans du tr�s vieux code car quelqu'un a retir� le support de weak_ptr sur une classe qui n'avait rien a voir.
Individuellement, chaque changement est justifi� et personne n'a fait d'erreur, le bug est "collectif". et la personne qui a cr�� le bug n'est meme pas au courant... chacun est comp�tent.
et moi mon interet c'est de reduire les bugs "collectifs" aussi.
Ahh... je n'ai jamais dit que c'est pas dommage, et, crois moi bien, je regrette sinc�rement et r�ellement cet �tat de fait...Citation:
Envoy� par Lavock
Mais il faut �tre r�aliste et accepter l'id�e que le monde est imparfait par nature, autrement, nous serons non seulement d��us, mais, en plus, les erreurs "des autres" risquent de nous retomber dessus...
je suis d'accord avec toi...Citation:
Envoy� par screetch
� mon sens, il faut �valuer le point au del� duquel il ne faut pas laisser la classe helper disponible ;)Honn�tement, non... Pas � ce point de vue l�Citation:
j'ai l'impression de devenir de plus en plus integriste avec l'age... c'est mal ? :s
Mais cela m�rite un b�mol:
Tant que, malgr� ton "int�grisme", tu n'en arrive pas � vouloir obliger n'importe qui (qui ne soit pas hi�rarchiquement li� � toi, s'entend) � se rallier � tes id�es, ce n'est pas un mal.
Le jour o� tu d�cidera de descendre sur Paris pour aller "casser la gueule" � un type qui n'est pas de ton avis, cela le deviendra :D
Non (enfin, pas tous)...Citation:
Envoy� par screetch
Par contre, ils sont tr�s facilement distraits, et leur distraction vaut pleinement idiotie :D
je suis 1 seul sur mon projet, donc je n'ai pas ce genre de probleme.Citation:
Envoy� par koala01
c'est pour cela que sur mon projet, les fichiers include sont cach�s, les locks de mutex sont priv�s, l'op�rateur & sur les entit�s est interdit (pour ne pas recuperer un pointeur), le dynamic_cast n'est pas autoris� (desactiv� dans la compilation).
et encore, je l'ai laiss� s'encrasser et la je vais nettoyer (�) sec :)
J'avoue que �a fais r�fl�chir... Mais est-il vraiment raisonnable de modifier du code que l'on ne conna�t pas vraiment ? L'auteur n'aurait-il pas du signaler l'utilisation de mutex dans la classe ?Citation:
Envoy� par screetch
Je dois avouer cependant que je comprend ton point de vue.
Whoa, si j'avait su que ca ferait ce remue m�nage ^^.Citation:
Envoy� par 3DArchi
Personellement, tout est question d'appliquer la m�thode d'encapsulation � un package. On pousse le g�nie logiciel au maximum o� les blocs s�par� ne sont pas les classes mais aussi des ensembles classes.
On inclue bien une classe dans une autre, pourquoi ne pouvont nous faire pareil en C++ avec un package qui n'est qu'une grosse classe simul�e.
Au lieu de cela, nous avons un namespace qui cloisonne le code sans faire rien d'autre.
Pour ce qui est du passage au C# au C++, c'est une d�cision difficile mais il est difficile de faire un jeu qui soit en C# sur PS3, Psp, Ds, Wii, iPhone, Linux et Mac.
M�me si pour les 4 derniers cas, Mono fait un r�sultat plut�t positif, ce n'est pas encore le saint graal.
L'utilisation m�me de C++ pour le gameplay devient tellement contraignante que les jeu, � d�faut d'avoir un support officiel d'un langage pour les machines, en arrive � int�grer un moteur de script tel que LUA (Sims3, Wow, Natural Selection 2 etc...) ou Python (Eve Online ...).
Avouons-le (du moins j'en suis fier d�fenseur): une architecture logicielle et la programmation sont beaucoup plus fluide et agr�able en C# qu'en C++.
Pourtant, je vais sur C++ car: il faut bien connaitre C++ pour penser � int�grer Mono ou Ruby comme moteur de script (ca j'ai r�ussi � le faire), il faut aussi se rendre � l'�vidence que je ne peux me passer de C++ pour l'envergure de puissance que requiert mon projet actuel (beaucoup d'IA, Mono et encore moins Ruby ne feront l'affaire) et enfin je suis �tudiant en jeu vid�o et la tendance actuelle n'est pas encore � utiliser un langage manag� (hormis UnrealScript)... et les langages attendu du domaine comme D ou Go (des langages compil�s et non manag�) ne sont qu'embrayonnaire et les voir un jour sur console changerait sensiblement les m�thodes de d�veloppement de jeu vid�o.
lorsque l'on est plusieurs a travailler sur le meme projet on est toujours amen� a changer du code que l'on ne connait pas. tiens je le fais en ce moment meme. Je suis sur a 99% que je vais p�ter un truc, et sur a 90% que le truc que je vais p�ter n'est pas important (dans le sens ou on utilise pas vraiment la fonctionnalit� que je vais casser).
mais rejeter la faute sur les autres n'avance a rien, trouver un coupable est contre-productif, fixer le probl�me permet de continuer mais a fait perdre du temps. Tandis que s'assurer que l'on utilise correctement l'outil permet de minimiser les erreurs et �ventuellement de ne pas perdre de temps.
et ma technique pour ca c'est de demander au compilateur de tout v�rifier (en tous cas c'est une des possibilit�s). ca revient a detecter l'erreur potentielle au moment ou on la commet.
et ca m'est arriv� recemment d'avoir cass� un truc par inadvertance, alors qu'il etait possible et meme "facile" de blinder le code pour que ca n'arrive pas. la logique a �t� que la personne, au lieu de blinder le code, a pr�f�r� aller au plus vite. du coup, j'ai cass� un truc et fait perdre 6h de taf a 30 personnes, et pris la faute sur moi, et le code moisi est toujours en place. Ce genre de comportement coute cher et rend les coll�gues un peu agressifs
[edit] c'etait en rapport avec le post de lavock :)
Je n'ai pas compris pourquoi on parlait de nivellement par le bas, il me semble au contraire que rendre son code difficile a mal utiliser est un bon moyen d'enseigner aux autres des techniques efficaces, non? Le code difficile a mal utiliser "guide" l'utilisateur vers du code correcte et si il a un minimum d'
J'essaie dans mon code (m�me perso) de "blinder" au maximum en isolant autant que possible, abusant d'assertions et en faisant en sorte qu'il soit quasimment impossible de se tromper avec l'interface des classes/systemes (je perds notamment pas mal de temps a travailler les interfaces, mais �a se r�duit avec l'experience heureusement). J'ai boss� sur des projets seul et a plusieurs et a mon sens �a revient exactement au m�me : le moi d'aujourd'hui est diff�rent du moi de demain et mieu vaut �pargner des erreurs au moi de demain, le guider par l'erreur (en exploitant le compilo en fait -- vive le typage fort) et au pire les assertions au runtime.
C'est devenu obsessif depuis que j'ai vu a quel point �a me faisait gagner du temps, tout simplement parceque j'ai confiance en mon code (qui du coup devient rapidement "correct") parceque je sais qu'il plantera vite si ya un probleme. De fait il devient beaucoup plus facile d'avancer avec le code de quelqu'un (d'autre ou son soit pass�) et d'avancer rapidement sur l'utilisation de ce code quand on sait qu'on sera pr�venu de la moindre erreur (pr�vue).
Personellement pour expliquer cette mani�re de penser aux stagiaires et aux autres employ�s non-programmeurs, j'utilise l'image suivante :
Les programmeurs sont des aveugles qui tirent le projet (fouett�s par des managers....non je plaisante).
Quand ils rencontrent un bug, ils viennent de se cogner contre un mur.
Les assertions sont nos mains, qui, si on prends la peine de les tendre vers l� ou on va, nous pr�viennent quand on approche d'un mur, tout en entrant en contact avec.
Les testeurs (service QA) sont nos chiens d'aveugles. Ils nous guident pour comprendre nos erreurs et nous r�v�lent des probl�mes plus difficiles a d�couvrir pour nous m�me qui tentons d'avancer sur un chemin invisible.
On est vraiment des aveugles: tout ce qu'on tente de faire rel�ve de l'esprit et de la th�orie jusqu'� ce qu'on essaie de lancer l'application pour se confronter a la r�alit�, parfois dure, mais avec laquelle il faut rentrer rapidement en contact avant de se la prendre au mauvais moment, sans pr�venir.
Avec les habitude, l'experience, notre cecit� est de moins en moins un handicap.
Voil� �a vaut ce que �a vaut comme image mais �a explique bien pourquoi faut organiser son code de mani�re plutot d�fensive.
Tu t'es peut �tre un peu trop habitu� a la notion de package, elle n'est pas n�cessaire dans le cas pr�sent (comme dans d'autres languages d'ailleurs). Il y a des tas de methodes pour isoler le code tel que tu le d�cris en C++ sans besoin d'une notion de package. Surtout qu'il serait absurde de consid�rer un ensemble de fonctions, de classes et potentiellement d'instances comme "un objet" que sont les packages. Ca n'a tout simplement pas de sens en C++. Je me r�p�te, mais je pense que tu comprendras mieu en comprenant les fondamentaux du pourquoi du comment. L'exemple du fait des include/cpp au lieu d'un fichier par classe est un bon point de d�part.Citation:
On inclue bien une classe dans une autre, pourquoi ne pouvont nous faire pareil en C++ avec un package qui n'est qu'une grosse classe simul�e.
Au lieu de cela, nous avons un namespace qui cloisonne le code sans faire rien d'autre.
Au passage -- HS-- , Lua et Python sont, il me semble, toujours utilis�s "par desssus" les "r�gles du jeu" pour les manipuler, les r�gles d'un jeu sont rarement impl�ment�es dans les languages de scripts mais en C++ pour les raisons que tu �voques effectivement. Elles sont impl�ment�es en c++ et peuvent �tre manipul�es via du script (dans cet ordre de d�veloppement). Ce qui donne la flexibilit� du script pour les modifications/parametrages, guides scenaristiques etc. ali� a la puissance "brutale" du C++(ou C ou asm ou tout ensemble) pour l'execution de "l'essentiel".
Le fait est que, dans le monde de bambi, on ne devrait pas s'inqui�ter de savoir si, oui ou non, nous avons affaire � un *bon* programmeur, ni si, oui ou non, il *risque* de faire une c...e avec notre code.Citation:
Envoy� par Klaim
Or, si tu tente (quel qu'en soit le moyen) de faire de mani�re � ce que ton code r�siste un tant soit peu aux programmeurs fatigu�s, distraits ou, simplement mauvais, tu autorise implicitement la m�diocrit� lorsqu'il s'agit de l'utiliser.
En cela, cela revient � consid�rer n'importe quel �tranger � ton service ou � ton �quipe de dev comme... le plus m�diocre de tous ceux qui existent, y compris le meilleur d'entre nous.
Voil� pourquoi le terme "nivellement par le bas" est apparu dans la discussion ;)
EDIT: j'ai parl� d'un code qui est destin� � �tre diffus�, mais le raisonnement est souvent appliqu� au niveau des applications... Ne dit-on pas que la majorit� des bugs trouvent leur origine entre la chaise et le clavier :question:
Citation:
Le fait est que, dans le monde de bambi, on ne devrait pas s'inqui�ter de savoir si, oui ou non, nous avons affaire � un *bon* programmeur, ni si, oui ou non, il *risque* de faire une c...e avec notre code.
Or, si tu tente (quel qu'en soit le moyen) de faire de mani�re � ce que ton code r�siste un tant soit peu aux programmeurs fatigu�s, distraits ou, simplement mauvais, tu autorise implicitement la m�diocrit� lorsqu'il s'agit de l'utiliser.
Ah �a part du principe que le dit programmeur n'est m�me pas un minimum curieux de savoir "pourquoi" �a "marche pas" (compilation ou runtime?) (le code lui indiquant d�j� pourquoi).
Ce n'est plus un programmeur a ce niveau l�, mais bon effectivement yen a pas mal dans le milieu malheureusement.
Oui, c'est un peu cela, effectivement...Citation:
Envoy� par Klaim
Mais tu sais comme moi qu'il arrive, m�me aux meilleurs, de ne pas avoir "la t�te � ce qu'il font", que ce soit parce qu'ils viennent d'enchainer 16 heures de boulot, dont 10 � d�bugger une grosse partie et qu'ils en ont "plein les boost" (heuu... "plein les boots":P:D), qu'ils viennent de s'engueuler avec leur femme, ou qu'ils ont simplement pass� une mauvaise nuit (liste qui n'a rien d'exhaustif).
Et puis, surtout, il faut regarder la r�alit� en face... :P
Ben en fait j'ai plutot tendance a consid�rer le code prot�g� comme un gain de temps pour tout le monde (sur le projet) plutot qu'autre chose, pour justement que quelqu'un qui soit pas dans un etat optimal de reflexion (ce qui au final reste relativement rare) soit quand m�me a m�me de faire son boulot sans que le tiens le "g�ne" de mani�re.
Salut,
Je pense qu'il y a 2 choses distinctes : faire du code blind� - ce qui me parait un minimum - et ne proposer que des outils en mousse. Pour reprendre l'exemple des mutex : oui dans le code que j'impl�mente, je pense qu'il vaut mieux utiliser des locker RAII sur les mutex. En revanche, si je d�veloppe une biblioth�que de mutex, ma biblioth�que exposera aussi bien les lockers RAII que les mutex en brut. A charge de l'utilisateur d'utiliser ce qui lui semble le plus pertinent pour son probl�me.
pourquoi le mutex RAII est en mousse ?
(ou plutot, pourquoi ne fournir que cela est en mousse)
il me semble qu'on ne peut pas d'un cot� promouvoir les smart ptr et de l'autre demander des fonctions de lock nues, c'est le meme type de ressource et conduit a des problemes similaires (leak, asym�trie)
tout comme les ouvertures/fermetures de fichiers par exemple.
Je suis d'accord que les mutex nus pr�sentent des probl�mes similaires aux pointeurs nus. Je suis d'accord pour dire qu'une biblioth�que de mutex devrait avoir des locker RAII pour faciliter l'utilisation de ses mutex. Je suis d'accord que dans la majorit� des cas, ne pas utiliser un tel locker fr�le avec la faute professionnelle. Je suis d'accord que la doc devrait recommander l'utilisation
de ces lockers. Mais je pense que la biblioth�que devrait permettre � l'utilisateur d'acc�der uniquement aux mutex s'il ne veut pas du locker. Aux risques et p�rils de l'utilisateur. Je peux avoir mon propre locker r�pondant � mes propres politiques, par exemple. Ou alors, il n'y a pas de mutex, il n'y a pas de locker et l'api propos�e par la biblioth�que a un niveau d'abstraction plus �lev�.
Je pr�f�re laisser la libert� � un utilisateur de faire un code qui plante mais je me dois de faire un code qui pr�sente le moins de risque de planter. Pour le coup, je crois que ce sont simplement des points de vues (inconciliables ?).