Cher journal,
C'est la première fois que je me permets de t'envoyer quelques mots doux et crois bien que je suis ému. Je m'apprête à affronter ton moinssage impitoyable et, psychologiquement, c'est pas facile, surtout la première fois.
Mais peu importe, ce n'est pas de ça dont il est question aujourd'hui.
Récemment, j'ai dû interfacer un de mes projets avec celui d'un autre, nécessitant quelques modifications de l'autre côté (à savoir, pas mon projet). J'ai réalisé moi-même ces modifications sur le fameux projet dont le code, m'a-t-on dit, est "propre". Pourtant, certains bouts de code m'ont quand même sautés aux yeux… Ne serait-ce que sur l'architecture de code orientée PO où l'on peut voir des choses de ce type là :
class MonObjet(object):
def meth1(self):
# du code ici...
def ajoutEnBase(mabase, monobjet):
# Code qui ajoute mon objet en base
Bref, la notion d'objet n'est plus trop bien respectée, question philosophie objet on n'est pas super là.
L'exemple cité est volontairement ultra simplifié, je ne veux pas débattre de ce code là particulièrement.
Ma réflexion s'oriente plutôt sur les développeurs qui disent "Mon code est propre". Maintenant, je m'en méfie très largement et je n'ai rencontré, dans ma vie, que très peu de gens qui ont les compétences de dire "Mon code est propre".
Je crois qu'on n'a pas tous le niveau pour faire ce genre d'affirmation, il faudrait qu'on soit pris en main par un vrai gourou qui, lui, pourrait nous dire et nous former (un peu comme un Jedi et son Padawan).
Malheureusement, c'est souvent impossible… car, même si ce Jedi existe, il faudrait qu'il soit pédagogue, en plus d'avoir la volonté de prendre un padawan sous son aile.
Sur l'idée de Mentors, ça serait hyper classe d'avoir un petit site collaboratif où l'on pourrait poster des bouts de code pour avoir un avis avisé sur la question ou même, carrément, des questions d'organisation de code ou manières de faire (pas de developpez.com ou ce genre de site). Bon, il faudrait que des développeurs KDE, Gnome et j'en passe, prennent un peu de leur temps pour venir flâner dessus et aider des jeunes padawans en détresse, mais je pense qu'on peut apprendre beaucoup avec une bonne critique bien construite.
L'idée n'est sûrement pas bonne en soit et même pas applicable quand on travaille pour une boîte (code propriétaire toossa), alors on regarde des bonnes pratiques sur le net et on fait du mimétisme sur les projets libres existants. Mais, c'est pas toujours facile et pas toujours adapté.
Bref, coder bien et propre demande d'être intelligent et d'avoir du talent. Pas seulement, car il faut aussi avoir de l'expérience et la patience d'aller toujours plus loin dans sa recherche. Je ne pense pas que ça soit à la portée de n'importe qui.
# Code review
Posté par Jux (site web personnel) . Évalué à 10.
Une partie de ma formation (un stage en fait) où j'ai le plus appris niveau qualité du code, c'est dans une boîte qui pratique les revues de code systématique de tous les commit.
Ca signifie que pour qu'un bout de code intègre le projet, il faut qu'un autre ingénieur le relise. Outre trouver des bugs, ça permet aussi d'avoir une discussion sur la façon d'implémenter les choses, d'éviter l'over-engineering ("pourquoi y'a besoin de 3 factory et 4 proxy alors qu'une fonction suffirait ?"), etc…
Mais l'effet le plus intéressant, c'est que ça force à relire son code avant d'envoyer pour une revue, à vérifier que les commentaires sont là où il faut, à virer tous les trucs deg qu'on fait quand on développe dans sons coin (genre les log de debug à moitié commentés).
La deuxième chose, c'est d'écrire des tests unitaires. C'est très chiant d'écrire des tests pour du code spaghetti avec 45 dépendances dans tous les sens. Si on arrive à écrire des petits tests unitaires sur chaque fonction/classe, c'est qu'en général, le code est déjà bien découpé.
Après, y'a le style de code. Ca, c'est un peu les goûts et les couleurs, mais si le code passe une revue de code et des tests unitaires, c'est qu'il devrait être compréhensible.
[^] # Re: Code review
Posté par weeber (site web personnel) . Évalué à 5.
Pour ce qui est du style de codage il y a plein de guides, comme par exemple celui de Google (C++, ObjC, Python, etc.) :
https://code.google.com/p/google-styleguide/
[^] # Re: Code review
Posté par Antoine . Évalué à 2.
Côté Python, il vaut mieux suivre la PEP 8 :
http://www.python.org/dev/peps/pep-0008/
Idiomatic Python présente également de bonnes pratiques :
http://python.net/~goodger/projects/pycon/2007/idiomatic/handout.html
[^] # Re: Code review
Posté par lolop (site web personnel) . Évalué à 2.
Un complément, pour s'assurer qu'on respecte bien le PEP8, à l'espace près, et aussi faire quelques contrôles, il existe un bon outil: flake8
http://pypi.python.org/pypi/flake8
Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
[^] # Re: Code review
Posté par Juke (site web personnel) . Évalué à 4.
il y a aussi pep8 et pylint.
[^] # Re: Code review
Posté par Guillaume Camera . Évalué à 4.
Ton commentaire me semble pertinent et colle avec l'idée de quelqu'un qui te prendrait un peu en main, même si c'est pas toujours le même dans ce cas là. Dans mon ancienne boite aussi on faisait ça, et j'ai toujours eu des bons retours (Comme je suis un petit c**, c'est souvent mon égo qui prennait, alors que j'avais la chance d'avoir un Gourou qui m'apprenait la vie, et c'est pas pour autant que je suis devenu bon. Mais ça, c'est juste ma faute.)
[^] # Re: Code review
Posté par パパフラクス . Évalué à 2.
Essaye d'intégrer une équipe XP (http://fr.wikipedia.org/wiki/Extreme_programming), et tu progressera à vitesse grand V!
Le binômage c'est un peu une revue de code en continue.
De plus tu bénéficieras de nombreuse bonnes pratiques, méthodes et de la rigueur liée à ce mode de travail.
Tu partageras aussi l’expérience et la critique constructive de tes co-equipiers.
[^] # Re: Code review
Posté par ckyl . Évalué à 6.
Tu as raison pour le binômage. La principale qualité c'est d'avoir deux esprits qui ont des angles d'attaques et des connaissances différentes. C'est aussi très très très bon pour la motivation et la productivité. Tu te perds beaucoup moins et reste plus facilement focalisé et pragmatique. On est là pour finir une tâche.
Par contre ca n'empêche absolument pas les revues de code par un œil extérieur à celui qui l'a développé. L’œil extérieur est "naïf" et va donc facilement challenger la solution que tu proposes.
C'est ce qu'on faisait dans mon dernier taff. On pairait absolument comme on voulait (en gros quand c'est pas trivial ou chiant). Mais on est arrivé à la conclusion qu'un oeil extérieur apportait quand même beaucoup de chose (en plus d'augmenter encore le bus factor et de disséminer les compétences).
Revenir à un modèle une personne par domaine et basta est totalement désespérant après…
[^] # Re: Code review
Posté par ckyl . Évalué à 4.
J'ajouterais sur ma réponse que puisque un "beau" code qui ne sert à rien est un mauvais code. Le code review n'est donc qu'une petite partie du processus qui vise à écrire du code de qualité. Le but est de faire intervenir toutes les personnes qui peuvent fournir un retour dès qu'un changement est fait (et de les faires participer aux décisions quand nécéssaire).
Ceci peut inclure:
- Toute l'équipe pour discuter des choix
- Un autre dev pour faire de la revue de code. Le but étant de trouver les typos, les erreurs, les améillorations possibles etc.
- Un UI/UX qui va regarder l'impact du changement sur l'application etc.
- Un QA qui va avoir une autre vision des tests, sont avis sur l'integration générale etc.
- Un consommateur de la fonctionalité qui va dire si ca lui convient etc.
Bref on écrit du code pour une raison, un beau code c'est un code qui répond à cette raison. Il doit être simple, maintenable et ne pas en faire plus que nécéssaire. Ce qu'on ne fait pas est aussi important que ce que l'on fait.
[^] # Re: Code review
Posté par Victor . Évalué à 4.
Je ne suis pas totalement d'accord.
Il m'arrive par exemple très régulièrement de rendre du code propre avant tout pour la beauté de la chose en elle-même.
La plupart du temps, ça a pour effet de bord de me faire trouver des bugs, de factoriser des choses, d'en clarifier, etc.
Ce que je veux dire, c'est qu'un "code propre, beau et clair" est ce qui fait qu'un code est bon, et donc qu'il fait bien ce qu'il veut faire. Et pas l'inverse. Donc ça vaut le coup parfois de se dire "je ne sais pas du tout ce que ça apporte à la résolution du problème, mais je vais nettoyer ce code pour la beauté du geste".
J'ajouterais que pour moi un code propre, c'est un code qui traduit parfaitement l'intention du programmeur.
On doit comprendre du premier coup ce que le programmeur voulait faire en le lisant (avec éventuellement des commentaires pour les parties un peu tricky).
Quand je vois du code qui ne correspond pas à ça, alors il ne peut pas être un beau code propre.
Et pour aller plus loin, je pense que c'est le même genre de raisonnement qui anime les chercheurs quand ils étudient des choses abstraites qui n'ont rien à voir avec les problèmes actuels.
C'est souvent la seule manière de trouver une bonne solution à un problème que l'on ne connaissait pas au moment de la trouvaille !
[^] # Re: Code review
Posté par ckyl . Évalué à 6.
Tout est toujours question de pragmatisme.
Appliquer ce que tu dis à une base de code réelle ca ne marche pas. Sur ta base de code une immense majorité va finir à la poubelle, ne jamais évoluer, ou se faire détruire par un changement de spec fonctionelle, de techno ou je ne sais quoi. Passer du temps à réécrire pour la beauté de la chose c'est à 99% perdre du temps.
Attention ca ne veut absolument pas dire qu'il faut accumuler de la dette technique ou se foutre de la qualité du code bien au contraire. Le but est que quand on livre un fonctionalité, on est globalement satisfait du travail produit, c'est propre documenté, testé. Sauf cas exceptionel il faut alors souvent resister à l'appel de la réécriture qui va enlever autant de bugs qu'en remettre (la couverture de tes tests reste constante) et qui est surement veine.
Ton travail de refactoring tu le fais quand tu as besoin (c'est à dire que tu dois retoucher au code pour d'autres besoins fonctionels ou non fonctionels) et exceptionellement quand c'est vraiment justifier tu le passes en dette technique.
Bref ton code il devrait être raisonablement bon dès que tu livres, sinon tu t'es un peu perdu en chemin. Si tu es dans un hot spot de ton appli tu vas passer ton temps dessus et tu vas l'ameillorer petit à petit mais pas uniquement pour la beauté de la chose à fonctionalité équivalente. Sinon "raisonablement" est souvent largement suffisant. Après si tu t'es vraiment lourder sur un truc, bha c'est de la sâle dette technique.
Il faut s'adapter à la situation, mais resister au mythe de la réécriture qui va resoudre tout les problèmes est aussi important que de savoir identifier et juger les faiblesses de ce qu'on produit.
[^] # Re: Code review
Posté par Maxime (site web personnel) . Évalué à 9.
Tu as écrit le commentaire que je comptais écrire ce soir. Lors de mon dernier stage, tout code devait être validé pour pouvoir le soumettre. C'était la politique pour toute la boite :
- Les ingénieurs avec assez d'expérience dans un langage pouvait demander à obtenir les compétences pour faire du code review sur langage.
- Même si on a les compétences, on doit demander à un peer de vérifier.
- Pour certains morceaux de code sensibles, le nombre de personnes autorisés à valider le code peut être restreint. Je me souviens avoir eu un changeset validé par 3 ou 4 personnes !
Maintenant que je ne suis plus en entreprise mais que je continue quand même à coder, ça me manque énormément de ne plus pouvoir avoir de retours sur mon code. Souvent on fait des choses qui marchent, certes, mais sans se douter qu'on pourrait faire mieux. C'était très formateur.
LGTM :)
[^] # Re: Code review
Posté par Guillaume Knispel . Évalué à 2.
C'est d'ailleurs la méthode de dev de Linux et le facteur de dev mesuré scientifiquement comme étant le plus important d'un point de vue de la qualité du code produit.
# Très bonne idée !
Posté par François GUÉRIN (Mastodon) . Évalué à 6.
Salut,
Je suis pour ma part (seul) développeur dans une collectivité, et je fais du python (aussi). La question de la 'propreté' du code est une question que je me pose chaque jour, en pensant à mes petits camarades qui reprendront (peut-être) mon code un jour…
J'utilise django pour mes développements, j'essaie de coller le plus possible au exemples proposés sur le site du projet, mais ça n'est pas toujours évident.
En terme d'architecture d'une application, la question se pose également, et il est souvent difficile de trouver des exemples pertinents (le sont-ils ?) qui correspondent aux problématiques posées.
Bien à toi !
[^] # Re: Très bonne idée !
Posté par cosmocat . Évalué à 4.
La solution est dans le précédent commentaire. Fais de la revue de code!!!!
-->[]
[^] # Re: Très bonne idée !
Posté par etenil . Évalué à 2.
S'il est le seul dévelopeur ça va être coton…
[^] # Re: Très bonne idée !
Posté par Anonyme . Évalué à -1.
pourquoi pas trouver un volontaire ? genre une personne qui te corrige les fautes dans les commentaires. C'est un oeuil extérieur, et tu forcera a faire de joli commentaire
[^] # Re: Très bonne idée !
Posté par BAud (site web personnel) . Évalué à 10.
C'est un œil extérieur et tu te forceras à faire de jolis commentaires.
de rien ;-)
[^] # Re: Très bonne idée !
Posté par cosmocat . Évalué à 3.
je sais pas si c'est si bien que ça de chercher quelqu'un pour relire des commentaires alors que la tendance actuelle est d'éviter au maximum les commentaires dans le code (avoir des noms de variable et fonctions qui "parlent") pour ne garder les commentaires que pour des cas bien particuliers ( documentation d'API, description de code bizarre car optimisé pour la performance ou pour contourner un bug, tout ce qui n'est pas "logique").
Le reste ne doit pas contenir de commentaires car si ton code est modifier, les commentaires introduisent une double maintenance (évolution du code ET des commentaires).
[^] # Re: Très bonne idée !
Posté par cosmocat . Évalué à 2.
J'adore les mecs qui répètent la blague que tu viens de faire et qui croient que t'as dit une ânerie…
# POO
Posté par Thomas Sanchez . Évalué à 8.
Code OO != code prope.
Surtout en Python.
[^] # Re: POO
Posté par Batchyx . Évalué à 10.
Je dirais même plus: Certains veulent voire de l'orienté objet partout, et considèrent "moche" tout code qui n'est pas orienté objet. C'est souvent le même genre de personne qui considèrent que les langages multi-paradigmes comme Python ou C++ sont "presque toujours moche", et qui te citent des exemples de codes qui sont propres ou moyennement propres, mais juste pas orienté objet.
En l'absence d'implementation de
MonObjet.meth1etajoutEnBaseou d'une déclaration de l'auteur original qui soutiens qu'il fait du code orienté objet, rien ne permet de me dire si ce code est propre ou non. SiajoutEnBasefait du duck-typing sur ses deux paramètres, alors il est parfaitement propre et logique que ça soit une fonction libre.[^] # Re: POO
Posté par Flo . Évalué à 4.
Ce qu'on voit surtout en objet, c'est de l'over-engineering — et en plus, raté. Par exemple, des méthodes qui pourraient être statiques, sont implémentées en méthodes d'instance. Du coup, pour éviter la multiplication d'objets utilitaires, on code un singleton. (Je précise que dans aucun cas il ne s'agit de limiter l'accès à une ressource, comme une connexion base, un fichier… cas pour lequel le singleton est approprié). Le plus drôle, c'est quand on trouve un mélange de méthodes d'instance et de méthodes de classe, sans aucune raison.
Et le moins drôle, c'est quand cela ne choque personne d'autre que moi :o
[^] # Re: POO
Posté par Antoine . Évalué à 0.
L'over-engineering, c'est justement d'écrire des méthodes statiques en se disant « là, je n'ai pas besoin d'une instance, je vais micro-optimiser un peu ».
Je me demande dans quel langage tu codes. Il n'a pas de fonctions toutes simples ?
[^] # Re: POO
Posté par Victor . Évalué à 3.
En Java, une fonction simple est implémentée comme une méthode statique.
Du coup, c'est exactement ce qu'il disait : plutôt qu'un singleton qui sert à rien, utilisons des méthodes statiques utilitaires.
[^] # Re: POO
Posté par Guillaume Knispel . Évalué à 2.
Ce que tu décris c'est de l'optimisation précoce, pas de l'over-engineering (où alors on considère que l'optimisation précoce est un sous ensemble de l'over-engineering ptet ?)
# Maintenable?
Posté par BlueWhisper . Évalué à 10.
Pour ma part, j'en reste à juste essayer de l'avoir maintenable…
Voici une référence intéressante.
[^] # Re: Maintenable?
Posté par kowalsky . Évalué à 10.
Moi j'en suis à "compilable"…
[^] # Re: Maintenable?
Posté par Victor . Évalué à 3.
Tu dois faire du fonctionnel ;)
Si ça compile et que ça traduit l'intention du programmeur, ça marche !
[^] # Re: Maintenable?
Posté par Batchyx . Évalué à 2.
Non. Ça fait ce que le programmeur veut (et encore), mais ça ne veut pas dire que ça marche.
[^] # Re: Maintenable?
Posté par Victor . Évalué à 2.
Oui, bah c'est un peu ce que je viens de dire, finbon…
# Bref, coder bien et propre demande d'être intelligent et d'avoir du talent.
Posté par tanguy_k (site web personnel) . Évalué à 8.
Je ne crois pas.
Si tu demandes a 2 personnes de peindre un mur en blanc, l'un fera un boulot sale et l'autre le fera consciencieusement et le résultat sera parfait.
Pourtant pas besoin d’être Einstein pour peindre un mur en blanc, et celui qui l'aura mal fait n'est pas un idiot pour autant.
AHMA produire du code propre demande :
- de la passion
- de la patiente (du temps donc)
Souvent en entreprise on manque d'argent et donc de temps. Plus particulièrement en France, on a une vision court terme du développement logiciel, surtout dans les SSII qui embauchent la majorité des développeurs.
Pour forcer une personne qui n'a pas la passion ni la patiente pour produire du code propre ou pour s'assurer qu'une personne passionnée et patiente n'oubliera rien, il y a plein de méthodes et d'outils : les tests automatises, le code coverage, le code review, l’intégration continue, les outils d'analyse de code…
[^] # Re: Bref, coder bien et propre demande d'être intelligent et d'avoir du talent.
Posté par SQP . Évalué à 10.
faut qu'elle soit quand même en bon état la patiente, ou une mourante peut faire l'affaire ?
[^] # Re: Bref, coder bien et propre demande d'être intelligent et d'avoir du talent.
Posté par freem . Évalué à 1.
Il a dit qu'il faut du temps, donc pas mourante ;)
# Propre en Python ???
Posté par Vador Dark (site web personnel) . Évalué à -10.
C'est possible du code propre en python ? C'est pas salle by design du python ?
[^] # Re: Propre en Python ???
Posté par etenil . Évalué à 5.
Il faut attendre qu'il mue.
[^] # Re: Propre en Python ???
Posté par reno . Évalué à 8.
On n'est pas Vendredi..
Et Python, mis à part l'absence de typage statique (possible avec cython je sais), est un langage vraiment très propre à mon avis d'amateur: je ne connais pas Python mais à chaque fois que je vois du code Python je comprends ce qu'il veut dire.
[^] # Re: Propre en Python ???
Posté par François GUÉRIN (Mastodon) . Évalué à 6.
Pour avoir manipulé et maintenu pas mal de code dans différents langages, python est effectivement l'un des plus lisibles : obligation de l'indentation, propreté des tableaux par inférence… avec un bon IDE, voir juste un éditeur avec un peu de coloration, c'est très clair.
Le seul truc qui pourrait paraître un peu scabreux, c'est le duck-typing, mais à l'usage c'est très utile. Et puis on est entre adultes consentants !
[^] # Re: Propre en Python ???
Posté par barmic . Évalué à 4.
Tout n'est pas rose non plus, le fait de ne pas déclarer les variables peu rendre la lecture compliquée (cette donnée membre est elle héritée ? Par exemple).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Propre en Python ???
Posté par Jux (site web personnel) . Évalué à 3.
J'adore Python et je l'utilise énormément. Le seul gros problème que j'ai avec, c'est l'impossibilité de déclarer des fonctions pures (sans effets de bord). Comme tout ce qui n'est pas type de base est passé par référence, on a vite fait de modifier un paramètre sans y penser.
Il y a aussi les règles de "scoping" qui sont pas très instinctives, avec les boucles qui n'ont pas leur propre espace de noms (une variable déclarée dans une boucle for est en fait déclarée dans le def contenant la boucle).
[^] # Re: Propre en Python ???
Posté par palm123 (site web personnel) . Évalué à 9.
L'un des mes proches est disons un fort développeur, il a beaucoup codé dans plein de langages (donc C, C++, Java, Pascal, Cobol, assembleur…) a adoré LISP, se pose des questions sur la qualité de son code, a une bibliothèque monstrueuse sur les algos et les langages cités.
Depuis quelques années, il programme quasi exclusivement en Python, dit qu'il programme 3 à 10 fois plus vite qu'en Java ou en C/C++, que son code contient moins de bugs.
Et quand il a besoin de performances, il écrit un module en C.
Alors les spécialistes diront sans doute que l'absence de typage statique est un problème, sans doute mineur.
ウィズコロナ
[^] # Re: Propre en Python ???
Posté par barmic . Évalué à 6.
« des spécialistes » car il y a un paquets de spécialistes vraiment excellents qui sont aussi des intégristes d'un truc ou d'un autre (la POO c'est pourri, le typage statique il y a que ça de vrai, l'inférence de type est la seule solution acceptable,…). C'est d'ailleurs une des raisons du nombre de langages.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Propre en Python ???
Posté par Atem18 (site web personnel) . Évalué à 7.
Comparé à ce que certains produisent en php, javascript ou d'autres langages "populaires", je trouve que Python est au contraire très lisible comme langage. Et ce même en codant "salement". Mon site web est sous Django et même sans toucher mon code pendant un petit moment, j'arrive toujours à le comprendre.
[^] # Re: Propre en Python ???
Posté par Christophe B. (site web personnel) . Évalué à 3.
Essaye avec du Perl Objet tu m'en diras des nouvelles.
Je suis passé a python a cause de ça.
Faites le test demander a quelqun qui ne connait pas python de lire un scripts python et d'essayer de comprendre, la plupart
du temps il comprend !
[^] # Re: Propre en Python ???
Posté par Atem18 (site web personnel) . Évalué à -5.
C'est gentil de demander, mais non. Perl est comme le C, c'est à dire orienté procédurale. Et puis en général, les besoins ne sont pas les mêmes. Perl est surtout fait pour du script web ou non. Donc cela dépasse rarement les centaines de lignes de codes.
Je l'ai fait, et je confirme que la personne à compris assez facilement ce que le code produisait en résultat. Et en passant, il me semble que le code Ruby est lui aussi assez facile à lire.
[^] # Re: Propre en Python ???
Posté par Christophe B. (site web personnel) . Évalué à 4.
rhoooooooooo c'est pourtant pas les exemples qui manquent !
reprenez moi si je me trompe mais Nagios est écrit en perl
Talend OPen Studio était à l'origine du moins écrit en perl
j'ai moi même un scripts perl de 3000 lignes pour gérer un serveur TCP
Aidez moi dans d'autres Gscripts perl > 900 lignes
A+
chris
[^] # Re: Propre en Python ???
Posté par El Titi . Évalué à 1.
Talend OPen Studio _était à l'origine du moins écrit en perl_
Merci de confirmer ce qu'on dit. Au delà d'une certaine taille Perl est inadapté.
[^] # Re: Propre en Python ???
Posté par Christophe B. (site web personnel) . Évalué à 2. Dernière modification le 20 novembre 2012 à 07:18.
Cela peut s'appeller de l'évolution aussi hein …
et dans le cas de Talend le choix semble plus basé sur le markettng ou la facilité de recrutement que le choix techniques
[^] # Re: Propre en Python ???
Posté par claudex . Évalué à 3.
Ce sont de drôle d'extensions de fichier pour des fichiers Perl. http://nagios.svn.sourceforge.net/viewvc/nagios/nagioscore/trunk/lib/
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Propre en Python ???
Posté par Christophe B. (site web personnel) . Évalué à 4.
Tout programme d'une certaine importance peut se décliner en plusieurs langages,
car justement pour certaines choses perl est tout à fait adapté, comme le C a d'autres
à chaque langage son domaine de prédilection.
Je ne défends pas Perl outre mesure, comme je l'ai dis plusieurs fois il m'a beaucoup appris sur le fonctionnement interne des langages notamment objet et bien d'autres choses.
Mais des que les structures se complexifie le code devient illisible et difficile a maintenir sur la durée.
Rentrer dans un code de 3000 lignes, pour modifier ou rajouter une fonction demande quasiment une bonne journée (mais je suis peut être lent)
Par contre quand il s'agit d'analyser des fluxs comme des fichier de logs par exemple, Perl demontre toute sa puissance et parfois je regrette certain sucre syntaxique dont je devrais rechercher la correspondance en Python.
Et en fait je m’aperçois que perl perd de son attrait, comme quoi une fois que l'on est arrivé au sommet on ne peut que redescendre …
[^] # Re: Propre en Python ???
Posté par freem . Évalué à 4.
Perl, c'est excellent pour les regex, et l'utiliser pour remplacer de petits scripts est plutôt une bonne idée.
Par contre, je plussoie pour l'illisibilité… bon, après, je suis un fanatique du typage fort, j'aime la POO, et j'ai fait peu, voire très, très peu, de dev web.
Après, on peut ergoter longtemps sur les langages, mais j'aimerai souligner un point:
le temps que l'on mets à écrire un code ne dépends pas que de son langage, mais surtout de ses lib standards (ou officielles, selon le langage).
La "lenteur" d'écriture de C++ viens du fait que la lib standard est limitée (par choix du comité, qu'on aime ou pas). Je pense que si elle était l'égale de celle du JAVA, de Python ou du .NET, les avis changeraient quelques peu.
Seulement, C++ est standardisé par l'ISO, ce qui est à la fois bien et mal. Les autres langages cités ne sont pas des standards officiels produits par un ensemble d'entreprise (tel JAVA sur qui
SunOracle à la mainmise et fait ce qu'il veut, ou .NET qui n'est réellement supporté que par MS, avec, certes, un concurrent libre, mais qui semble ne pas tenir trop la route), et ne souffrent donc pas les mêmes contraintes, qui peuvent parfois s'avérer des avantages (compatibilité assurée d'un standard avec ses ancêtres, par exemple).# Propre != bon
Posté par GuieA_7 (site web personnel) . Évalué à 10.
C'est ma définition, elle vaut ce qu'elle vaut, mais pour moi un code propre est un code dépourvu de ce genre d'horreur :
N'importe codeur rigoureux et consciencieux peut donc faire du code propre. Mais ledit code peut quand même avoir une mauvaise conception, être lourd et inefficace etc…, et donc être mauvais.
[^] # Re: Propre != bon
Posté par Flo . Évalué à 5.
Tout à fait d'accord.
Par contre, l'avantage du code propre, c'est qu'on ne va pas passer des heures pour voir s'il est bon.
# Mon code est propre
Posté par maboiteaspam . Évalué à 2.
Mon code est propre
En même temps ça dépend beaucoup de la personne qui va lire le code.
L'un n'en aura rien à foutre et acceptera n'importe qu'elle m* pourvu que ça marche.
L'autre se plaindra de la pauvre qualité du programme, pourtant fonctionnel, qui aurait pu utiliser tel pattern ici, ou là.
Ou bien encore d'un autre qui se cabre au premier copier coller venu.
Au final, on fait comme on peu avec les ressources mises à dispositions et les objectifs à atteindre.
Après, à chacun de voir quel niveau d'implication il peut bien investir avec ses connaissances, pour le meilleur (!= perfection).
Pour autant, dois je dire, ça m'emmerde profondément quand je comprends qu'au sujet de l’agriculture et des pesticides additifs**, on fait comme on peut, pour "le meilleur des mondes"…
** [et vas y que je m’essoufflerais à tous les citer]
# Avis d'un théoricien
Posté par fmaz fmaz . Évalué à 10.
Tout d'abord, je tiens à dire que je ne programme quasiment pas mais j'enseigne la programmation et je corrige des projets d'étudiants. En ce moment, j'enseigne un module de preuve de programme. Ce n'est pas un module de très haut niveau. C'est du L2 mais je le trouve très intéressant.
En effet, même si au final, on ne prouve pas réellement son code, écrire comme si on allait le faire pousse à écrire plus proprement pour plusieurs raison.
1. pour prouver un code, il faut savoir pourquoi il ne plante pas. On peut ainsi documenter les variants et invariants de boucles. On peut spécifier le comportement des fonctions qu'on écrit. Bref, on peut documenter le code et ça rend la relecture plus simple.
2. prouver, c'est chiant et c'est long. Garder une structure globale simple simplifie beaucoup le boulot.
Bref.
# Opensource ?
Posté par mazarini . Évalué à 6.
J'ai eu l'occasion de participer à des projets opensource. Le moins que l'on puisse dire, c'est que la revue de code fonctionne.
Les sources sont lus et et relus par plein de monde. Les gens que j'ai cotoyé n'étaient pas toujours tendre dans leur critique du code.
Ca permet de faire pas mal de progrès en propreté du code.
[^] # Re: Opensource ?
Posté par liberforce (site web personnel) . Évalué à 4.
Même sans écrire de patch, et donc sans revue, se plonger dans les sources est un excellent moyen de progresser. J'ai appris énormément en lisant des bouts de code de GTK, sur comment concevoir une API, trouver des noms de fonctions et de variables compréhensibles, homogènes. Du coup tu peux deviner facilement le nom d'une fonction et dans quel objet elle se trouve, et c'est un gain énorme de temps !
# POO
Posté par barmic . Évalué à 10.
Je préfère ce que tu présente à ça :
Car ce n'est pas la responsabilité de MonObjet de savoir comment s'enregistrer en base. Généralement on utilise un objet par exemple session qui permet de persister des objets. C'est le DAO.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: POO
Posté par El Titi . Évalué à 4.
Tout a fait et dans le lien que tu pointes, on se retrouve avec un contrôleur encore en plus qui fait appel à un DAO … 2 objets en plus. Tout ça pour s'abstraire du mécanisme de stockage alors qu'on a juste à modifier une ligne le jour oû on change de methode . Bienvenue dans la sur conception des langages mono paradigme objet. Ploum au secours !
[^] # Re: POO
Posté par dyno partouzeur de drouate . Évalué à 10.
Le jour où tu as 300 classes dans ton projet et que le chef vient te dire qu'en plus de MySql, ce serait bien de pouvoir utiliser une base Oracle pour les gros clients, tu es content d'avoir centralisé l'interface avec la BDD dans des DAO au lieu que le code de persistence se retrouve dans tes objets eux-mêmes…
[^] # Re: POO
Posté par Guillaume Camera . Évalué à 2.
C'est exactement le genre de remarque que j'aimerai qu'on me fasse après (voir avant) un commit :)
[^] # Re: POO
Posté par ckyl . Évalué à 5. Dernière modification le 16 novembre 2012 à 09:12.
Comme toujours c'est une question de compromis. Retarder au maximum l'implémentation de ce dont tu n'as pas besoin actuellement sans toutefois bloquer les évolutions futures. C'est tout l’objectif des méthodes agiles, éviter l'overdesign en étant capable de livrer le même ensemble de fonctionnalités. Souvent que tu fasses le refactoring au moment ou tu en as réellement besoin ou un an avant ne change rien, sauf que dans 90% des cas tu n'en as pas besoin.
Il ne faut évidement pas tomber dans le cliché facile, et avoir le jugement pour essayer d'utiliser l'approche la plus rationnelle pour ton domaine (tu n'as pas les mêmes contraintes quand tu livres une application ou des API avec contrat de compatibilité sur 7 ans). C'est ca le boulot de dev, et la notion de "code propre" est donc fondamentalement subjective. On livre des fonctionnalités pas du code.
Tu as un exemple assez violent là: https://www.youtube.com/watch?v=o9pEzgHorH0
A ne pas suivre les yeux fermés, beaucoup des questions critiques qui sont faites sont parfaitement valides mais garder dans sa tête cette approche est très bon.
[^] # Re: POO
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Les méthodes agiles disent qu'il faut résister à l'envie du patch en bois et factoriser quand il le faut. Typiquement si ton projet est petit, il n'y a pas besoin d'avoir d'objet proxy, mais cela change avec le nombre d'objet concerné. Il y a quand même une règle qui dit que moins il y a de code, mieux on se porte. Les guideslines Linux ne sont pas mauvais sur le sujet.
Pour faciliter la maintenance, il faut avoir du code simple, avec "changement atomique" ou au moins que cela ne compile plus en cas de changement multiple nécessaire. Il faut une arborescence claire entre module pour éviter de copier/coller du code pour éviter une dépendance circulaire, en général, cela signifie qu'un nouveau module doit être créer.
"La première sécurité est la liberté"
[^] # Re: POO
Posté par El Titi . Évalué à 2.
Exactement ce que je soulignais plus loin.
Un codeur Java éclairé. Merci
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 3.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: POO
Posté par barmic . Évalué à 4.
En regardant vite fait sa documentation il semble que c'est précisément ce qu'il fait : vois. Il utilise un objet session qui gère les interactions avec la base et tu l'appel avec de simples objets, comme avec hibernate par exemple. La différence entre les deux c'est que chacun s'adapte au langage qu'il utilise (typage statique ou non).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: POO
Posté par devnewton 🍺 (site web personnel) . Évalué à 2.
Ca c'était avant!
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: POO
Posté par fearan . Évalué à 5.
List => 1
String=>2
Files=>3
Paths=>4
StandardCharsert=>5
Oui on est à 5 maintenant (mauvaise foi inside surtout pour le dernier ;) )
m'en fout c'est vendredi !!!
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: POO
Posté par devnewton 🍺 (site web personnel) . Évalué à 3.
Tu confonds objets et classes.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: POO
Posté par windu.2b . Évalué à 3.
En effet, sa liste serait plutôt :
Soit, 4 objets + autant d'objets qu'il y a de lignes dans le fichier lu
[^] # Re: POO
Posté par barmic . Évalué à 4.
Pour chipoter, les classes sont des instances de la classe Class (si c'est pas classe ça).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: POO
Posté par Dr BG . Évalué à 10.
Tant qu'il ne confond pas classe et coquetterie…
[^] # Re: POO
Posté par ckyl . Évalué à 6.
J'ai jamais compris l’intérêt de pinailler sur un exemple précis.
L'API Java est généralement mal gaulée pour l'utilisateur final. Tu as un nombre de bonnes briques de base extraordinaire, par contre il manque souvent le happy path à l'utilisation. D'où commons et guava, qui malgré tout ne résolvent que très partiellement le problème. Ce qu'ils voulaient faire est très clair, mais ils ont juste oublié un truc dans la conception.
[^] # Re: POO
Posté par barmic . Évalué à 3.
Je suis tout à fait d'accord mais elle évolue dans le bon sens. nio2 que montre devnewton est un grand pas en avant. Avant ça l'arrivé de Scanner avait pas mal aidé. Mais c'est sous utilisé (on voit encore souvent des cours donner des classes toutes faite pour faire le même boulot que Scanner).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: POO
Posté par ckyl . Évalué à 3.
Je parle de manière générale. Tu as raison elle évolue mais très lentement si tu prends en compte toute la surface de l'API.
J'essaie de ne pas me focaliser sur des exemples de 3 lignes à 2 francs qui ne servent à rien, voir ne pas me focaliser sur un exemple tout cours. C'est un problème général de l'API Java. Des trucs les plus triviaux de la manipulation de fichier, aux collections, aux blocs plus velus. Unitairement les blocs sont pas crado mais forment rarement un tout utilisable tel quel. Pour prendre un exemple moins trivial fait moi un serveur NIO avec une couche SSL tu vas voir que tu vas t'amuser pendant un moment. Des choses comme ca je dois pouvoir t'en sortir une très longue liste. Il en résulte des kilomètre de glue, de code dupliqué, de lib incompatible ou de JAR hell.
[^] # Re: POO
Posté par devnewton 🍺 (site web personnel) . Évalué à 1.
Ca n'est pas vraiment la "philosophie java". Quel est le problème que tu cherches à résoudre avec ce serveur? 99% du temps, tu vas utiliser un framework de communication correspondant aux besoins de ton projet. Il sera peut être bloated, mais il fera le café, 100 balles et un mars.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: POO
Posté par devnewton 🍺 (site web personnel) . Évalué à 2.
Ce code pose plein de problèmes par rapport à la version java:
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: POO
Posté par fearan . Évalué à 0.
Je dirai que dans tout langage bien foutu, à la fin du scope il se ferme, en c++ la possibilité de redéfinir les destructeurs est très bien pour ça, et on sait même quand il est appelé, sans avoir a faire un truc explicite; c'est la tranquillité du développeur, alors qu'en java, on sais bien redéfinir un destructeur, mais y a rien pour le faire directement, on peut juste le suggérer.
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: POO
Posté par ckyl . Évalué à 5.
http://docs.oracle.com/javase/tutorial/essential/exceptions/tryResourceClose.html
Comme le with en Python.
Pour ce qui est de balancer ca dans un dtor c'est une très mauvaise idée dans un langage à GC.
[^] # Re: POO
Posté par fearan . Évalué à 2. Dernière modification le 16 novembre 2012 à 16:43.
oui et pourtant qu'est ce que c'est pratique, c'est bien dommage de pas avoir de mécanisme équivalent.
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: POO
Posté par lolop (site web personnel) . Évalué à 6.
Avec la précision de l'encodage et la fermeture automatique.
Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 0.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: POO
Posté par reno . Évalué à 7.
Beurk, si le GC ne tourne pas car tu as plein de mémoire libre, tu risque de garder le fichier ouvert très longtemps..
[^] # Re: POO
Posté par Christophe B. (site web personnel) . Évalué à 5.
Le langage perl est le meileur a ce petit jeu
mais est ce pour autant mieux ?
Dans ce genre de bidouille on ne teste pas si le fichier existe, il n'y a pas de limite non plus
si je pointe sur des fichiers comme /dev/random ou /dev/zero
bref ces sucres syntaxiques sont dangereux, ils permettent d'esquisser un traitement ou un algorithme
Mais des que l'on veut mettre en prod quelque chose
1- il faut tout tester et vérifier avant de faire quoi que se soit, ne serait ce que pour faciliter la recherche de problème
2- si on test il faut logger (surtout si c'est cron qui le lance :) )
3- et je n'aborde même pas la problèmatique liée à la sécurité, je suis bien a l'abri derrière mon pare feu
donc même pour un truc tout bête ya du code a pondre tout autour
une fois j'ai lu que l'on pouvait qualifier la qualité d'un programme aux nombres de ses messages d'erreurs
par exemple : oracle (la base de données pas la sté) et sa classification poussé des erreurs ORA- (et les autres) en recherche de problème
c'est un vrai bonheur, a part quelques messages génériques souvent le code erreurs fait mouches et l'on trouve
rapidement une explication au problème => c'est un exemple a suivre
Mais bon sa sent le vécu ya qq dizaines d'années de dev derrière
bon Dredi
A+
Chris
[^] # Re: POO
Posté par lolop (site web personnel) . Évalué à 2.
Pour moi ce n'est pas de la bidouille. À l'ouverture en lecture, si le fichier n'existe pas, une exception est levée - au code ad-hoc de la récupérer, ou sinon le programme se termine avec un traceback qui te permet de voir ce qui a été appelé lorsque l'exception s'est produite.
Si tu fais une boucle de lecture, tu vas entrer dans une boucle infinie. Si tu utilises le sucre syntaxique, tu vas remplir la mémoire et planter le processus. Tu détectes comment qu'un flux en entrée est "infini"? Et pourquoi veux-tu a-priori l'interdire?
Le il faut "tout" vérifier… dépend à mon avis du contexte de ce qu'est "la prod" pour ton logiciel.
M'ouaif.
Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
[^] # Re: POO
Posté par Christophe B. (site web personnel) . Évalué à 0.
Bien sur, entre le 2 lignes jetables fait pour corriger un truc, et le scripts que tu vas maintenir pendant plusieurs années
je fais bien la différence, mais si tu regardes bien tu trouveras plus de "sucre syntaxique" dans les 2 lignes que dans les autres scripts
et c'est normal, c'est fais pour ca …
Sur certain serveur il faut partagé la mémoire et si un processus mange tout y'en a plus pour les autres, demandes aux moules qui utilise Java :)
A+
chris
[^] # Re: POO
Posté par barmic . Évalué à 3.
La jvm a des options pour ça (Xmx notamment) et tu peut même facilement monitorer une jvm en cours de fonctionnement pour voir son utilisation de la mémoire. Donc la jvm prend la place que tu lui propose et meurt toute seule si elle tente de faire plus.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: POO
Posté par Christophe B. (site web personnel) . Évalué à -1.
Merci pour la précision …
je devrais pas la ramener sur un langage que je connais mal, c'était juste l'occasion d'être bête et méchant :)
A+
chris
[^] # Re: POO
Posté par wismerhill . Évalué à 4.
Pas tout à fait.
Quand la jvm arrive à sa limite, le thread qui a le malheur de créer l'objet de trop (goutte, vase, …) se prend un OutOfMemoryError, ce qui va probablement tuer le thread en question (sauf si on intercepte les Error, mais c'est dangereux) et libérer la mémoire retenue par ce thread-là.
Si ce thread n'était pas le seul thread non)-daemon de la jvm, les autres vont continuer comme si de rien n'était (mais avec peut-être des objets dans un état incohérent suite à la mort violente du thread sacrifié).
[^] # Re: POO
Posté par barmic . Évalué à 1.
Tout à fait, je voulais surtout indiquer qu'une jvm ne prends pas plus de mémoire que ce qu'on veut bien lui donner.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: POO
Posté par wismerhill . Évalué à 4.
Ce n'est pas si sur…
L'option -Xmx de java ne configure la limite que de la partie heap, c'est à dire celle qui contient les instances des objets.
Mais il y a aussi la partie non-heap, qui contient les classes chargées par la jvm. Dans la jvm d'oracle et openjdk ça se configure avec une option en -XX. La valeur par défaut du maximum du non-heap est 128Mo en 32bits et 160Mo en 64 bits.
D'autres jvm peuvent géré ça de façon complètement différente (exemple extrême avec gcj/gij où les classes sont compilées sous forme de bibliothèques natives).
Et ce n'est pas tout, il y a par exemple la classe java.nio.MappedByteBuffer qui permet de travailler sur un fichier mappé en mémoire, qui va donc prendre de la RAM supplémentaire en dehors (et sans les limitations) de celle contrôlée par la jvm (donc fuite de mémoire potentielle).
Tu peux voir la mémoire effectivement utilisée par le processus java via les tichiers stat* dans son répertoire de /proc (man proc pour les détails des champs), ça peut surprendre.
[^] # Re: POO
Posté par ckyl . Évalué à 4. Dernière modification le 20 novembre 2012 à 20:33.
Parfaitement. Notons qu'au passage ils sont en train de merger JRockit avec Hotspot ce qui implique la disparition de cette merde de PermGenSpace dans Hotspot qui est absolument ingérable.
Il y a deux règles générales avec la gestion mémoire Java:
- Ceux qui pensent que c'est pas ou peut configurable ne savent absolument pas de quoi ils parlent
- Ceux qui pensent qu'il suffit de configurer n'ont jamais eu à le faire
La troisième règle générale c'est que c'est inconfigurable si tu ne comprends pas profondément l'application, si tu déploie plusieurs applis dans une même VM, ou si tu ne connais pas parfaitement la version de la plateforme que tu utilises (genre à outil équivalent selon le GC utilisé le fractionnement young/tenured peut différer).
Dans un sens ca reste vrai. Tu peux tout borner sauf les stacks et les régions mmap AFAIK. Bon après tu peux aussi avoir du code natif qui va mallocer ou faire des sbrk si on va par là ;)
[^] # Re: POO
Posté par Yth (Mastodon) . Évalué à 3.
Mouais, enfin il trolle beaucoup le type qui disserte sur les bonnes et les mauvaises API, en plus il fait ça sous forme de présentation plutôt que d'article ça lui permet de ne rien expliquer, et d'asséner des vérités…
Plusieurs de ses exemples sont faux, ou franchement volontairement rendu plus moches qu'ils pourraient l'être pour un même résultat.
Je ne trouve pas le lien intéressant du tout !
Yth.
[^] # Re: POO
Posté par El Titi . Évalué à 3.
Question:
Faut il perdre son temps là dans le sprint courant ou il n'y que 10 classes ou accumuler cette dette technique et le traiter dans un sprint suivant ?
Et que se passe t'il si ton "beau" logiciel bien conçu ne passe jamais sous Oracle et est remplacé par un autre 10 ans plus tard.
La tentation est de passer des heures à produire une architecture quasi-parfaite finit par être contre productive.
Le mieux est l'ennemi du bien.
Et ici, Python te permet de mettre ce code dans "aucun" objet puisqu'il n'impose pas l'approche objet
Et tu as encore la programmation par aspect qui t'aide à traiter ce genre de problématique. C'est d'ailleurs bien le virage qu'à pris JEE ces dernières années.
[^] # Re: POO
Posté par El Titi . Évalué à 3.
Et ce que je trouve le plus drôle en fait, c'est que même avec ce genre de conception, dans ton cas, on a toujours du refactoring qui doit impacter l'architecture du projet parce qu'on découvre qu'on utilisait des fonctionnalités spécifique à telle db et que notre abstraction était insuffisante ou alors que finalement c'est une base NoSQL qu'on prend.
[^] # Re: POO
Posté par Nicolas Boulay (site web personnel) . Évalué à 1.
D’où le fait de ne pas faire d'abstraction, tant que cela n'est pas nécessaire.
Un code propre est un code ou l'on corrige n'importe quel bug en moins de 2h.
"La première sécurité est la liberté"
[^] # Re: POO
Posté par calandoa . Évalué à 10.
N'importe quel bug en moins de deux heures ? Tu bluffes, Martoni !
[^] # Re: POO
Posté par GaMa (site web personnel) . Évalué à 3.
Ben, une fois que ton code est propre et que tu as corrigé tous les bugs, il te faut vachement moins de deux heures.
Matthieu Gautier|irc:starmad
[^] # Re: POO
Posté par barmic . Évalué à 2.
Les ORM qui utilisent une fonction dans les objets du modèle utilisent soit un proxy soit de l'héritage (ou les deux) et éventuellement de l'introspection. Je ne suis pas sur qu'avoir des classes triviales soient de la sur conception.
C'est aussi agréable quand tu veut faire du cache, tu as une classe qui va pouvoir s'occuper du cache sans influencer le reste du code.
Note que j'ai parlé de ma préférence, c'est tout à fait discutable.
J'ai parlé de conception objet parce que Guillaume Camera expliquait :
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: POO
Posté par El Titi . Évalué à 2.
Non sur le lien wikipedia on a un objet metier , un DAO et un contrôleur. Dans le code plus haut il n'y en a pas besoin.
Une simple fonction suffit.Pas besoin de l'encapsuler dans un contrôleur.
Evidemment lorsque tout est objet dans un langage on a guère de choix.
[^] # Re: POO
Posté par barmic . Évalué à 2.
Et dans le contrôleur il y a quoi ? Simplement l'usage du DAO, l'exemple ne prends même pas la peine de mettre ça dans une fonction. Le contrôleur c'est juste le bout de code qui a besoin des objets, il instancie le DAO et récupère (ou sauve) des objets.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: POO
Posté par El Titi . Évalué à 2.
On est d'accord. 3 objets à créer
Alors qu'en python en s'en sort avec une fonction et un objet métier sans se prendre la tête.
Le jour où on en a besoin on le fait.
Un Javaiste va démarrer directos avec ces patterns. Et ce qui pourrait être testé en 30s prendra une demi-heure si on considère 10 classes métiers.
Ou alors on modélisera ça avec un DSL et une transfo pour générer toutes le bonnes classes.
Ou alors on place une annotation et on régénère toute la plomberie.
Wouah!!! Quelle boucle de développement rapide.
Mais bon on a compris depuis longtemps qu'être JEE Lead Architect est l'aboutissement d'une carrière.
C'est pas Pierre Tramo qui va me démentir. (Je mets pas les smileys , t'as compris je crois)
[^] # Re: POO
Posté par barmic . Évalué à 4. Dernière modification le 16 novembre 2012 à 11:16.
Tu parle de langage là où je parle de paterne de développement. Je vais pas continuer parce que je trouve dommage ces querelles de clochers sur les langages et le profile que l'on prête à leurs utilisateurs.
Il est impossible d'avoir une discussion de qualité si on par dans ce sens là car on par uniquement avec des apprioris.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: POO
Posté par Guillaume Camera . Évalué à 1.
Alors pourquoi dans la plus part des frameworks web, on a une méthode save() de l'objet ?
Sachant que ces frameworks gérent parfaitement plusieurs bases de données. Peut-être que derrière c'est écrit avec un DAO surement, mais dans ce cas on a quand même une méthode d'objet. Du coup, c'est quoi l'intêret ?
[^] # Re: POO
Posté par Tom . Évalué à 2. Dernière modification le 16 novembre 2012 à 09:50.
Parce que l'objet est souvent l'instance d'une classe Modèle qui hérite d'une méthode d'enregistrement en base (ou autre).
[^] # Re: POO
Posté par barmic . Évalué à 3.
Elles utilisent l'héritage pour faire le boulot du DAO (ce n'est pas toi qui écris la méthode save(), ni les constructeurs qui prennent une requête SQL en paramètre). Je dis juste que d'un point de vu « philosophie objet », ce n'est pas à l'objet de savoir comment se persister, mais à la base de savoir comment persister un objet. De la même manière que c'est à la console de savoir comment afficher et pas à l'objet. Ça ne te viendrais pas à l'esprit d'écrire ça :
au lieu de ça :
Personnellement, je n'ai jamais utilisé d'ORM comme tu le dis, je ne sais pas comment ils gèrent les transactions d'ailleurs.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: POO
Posté par El Titi . Évalué à 2.
C'est là justement que la philosophie objet montre ses limites.
C'est pour ça que l'AOP vient compléter ces lacunes.
La persistance n'est qu'un aspect des objets métiers.
Plutôt que de se casser le tronc à écrire chaque méthode save de l'objet ou créer une classe DAO associée à chaque classe métier, il faut regrouper ça dans un aspect.
Par la suite plutôt que de changer l'implémentation de chaque classe DAO, on se concentre sur un seul fichier.
Cette approche orthogonale est la plus efficace.
L'OOP n'est plus suffisante aujourd'hui.
Mais je suis d'accord, pour la mettre en oeuvre il faut déjà connaitre les patterns associés.
[^] # Re: POO
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Il me semblait que l'on pouvait faire les mêmes fonctionnalités de l'aspect avec de la simple programmation OO.
"La première sécurité est la liberté"
[^] # Re: POO
Posté par El Titi . Évalué à 2.
Bin ce sont 2 approches différentes.
Le but de l'AOP est de regrouper toutes les problématiques transverses (log, persistence, …) dans des points uniques sans être oblige de retoucher toutes les classes.
C'est pour ça que Java a introduit les annotations, non ?
[^] # Re: POO
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Oui, mais tu peux normalement t'en sortir avec des patterns factory/proxy/visiteurs. A priori, l'aspect programming devient très complexe dés que plusieurs traits doivent fonctionner ensemble.
"La première sécurité est la liberté"
[^] # Re: POO
Posté par El Titi . Évalué à 2.
On se comprend mal.
Evidemment que les design patterns sont appliquables.
L'AOP n'est qu'un outil complémentaire qui permet entre autres d'éviter d'écriture toute ce code redondant nécessaire à la mise en oeuvre de certains patterns.
Et pour d'autres aspects comme le logging par exemple il est très utile et je vois mal comment t'en sortir autrement qu'en écrivant chacune des méthodes de log à la mano.
[^] # Re: POO
Posté par freem . Évalué à 3.
Perso, je pense qu'aucun paradigme n'est parfait, et qu'ils ont tous un intérêt.
Les langages inspirés du tout objet se plantent royalement pour moi… D'ailleurs, ils font maintenant un peu de générique…
Pour cette histoire de sérialisation, moi je vois comment boost::serialization à fait (enfin, ce qu'il nous faut faire pour s'en servir) et je trouve le résultat plutôt pas mal.
Chaque classe sérialisable à une fonction template serialize() et est amie avec un des classes de boost. A partir de là, suffit de coller dans un fichier les implémentations template et basta (il proposent d'autres méthodes, mais c'est celle que j'ai préférée)
D'une part, ces implémentations, étant template, n'empêcheront pas de compiler/linker/exécuter en cas d'absence, et d'autre part on peut les regrouper toutes dans un seul fichier, potentiellement dans un autre binaire.
Le meilleur, c'est qu'il suffit de faire une classe serialisatrice pour que toutes les classes s'adaptent automatiquement.
Ca rejoint l'idée que ce n'est pas la classe elle-même qui doit savoir comment se sérialiser, mais elle doit savoir quoi sérialiser, et les passer à celle qui saura comment.
Certes, il y a plus de classes. Mais chaque classe ne doit être responsable que d'elle-même, selon les pattern GRASP.
Ces pattern ont effectivement le problème d'avoir plus de classes, mais elles sont plus petites, et donc bien plus maintenables et réutilisables. Tandis que tout mettre dans une seule classe, c'est comme tout faire dans la même fonction: un erreur qui empêche de connaître les méthodes responsables de la gestion d'une ressource, et qui par la même augmente la difficulté de réparer les bugs.
[^] # Re: POO
Posté par yohann (site web personnel) . Évalué à 1.
Chaque objet à une méthode save, et on a définit qu'une fois l'interface BDD
[^] # Re: POO
Posté par djano . Évalué à 2.
Plusieurs son de cloche existe.
Ce que tu décris est le pattern Active Record que personnellement je n'aime pas du tout car l'objet devient trop gros: il a trop de responsabilités et connaît trop de choses (il connaît toutes les bases de données? Waouw!)
Personnellement je préfère le pattern DAO qui sépare nettement le code technique (lien avec la base de données) du code métier, ca me semble plus maintenable sur le long terme.
Ensuite, je n'aime pas les ORM du types d'Hibernate qui sont censés tout faire, mais ne le font pas bien. Et puis les performances ne sont pas toujours au RDV.
[^] # Re: POO
Posté par barmic . Évalué à 2.
Je voudrais quand même calmer les esprits. J'ai parlé de ma préférence et de comment ça devrait être selon le paradigme objet (ce dont parlait l'auteur du journal). J'ai pas dis qu'une méthode ou l'autre était particulièrement nulle.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: POO
Posté par stopspam . Évalué à 1. Dernière modification le 16 novembre 2012 à 13:32.
Il est où le problème avec le code de la dépêche ? C'est un design pattern.
C'est le principe entre autre de SQLAlchemy chez python ou Entity Framework en c#. J'imagine qu'il existe un équivalent dans tous les autres langages.
[^] # Re: POO
Posté par barmic . Évalué à 2.
J'ai dis que je préfère le code de la dépêche plutôt que de remonter la méthode dans la classe MonObjet.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: POO
Posté par stopspam . Évalué à 3.
J'avais bien compris. Je me suis juste planté de personne dans le "Répondre".
# Code Review
Posté par daimrod . Évalué à 7.
Pour les non-anglophobes, il existe codereview. C'est l'équivalent de StackOverflow, donc un StackExchange, mais pour le Code Review. Sinon il existe aussi des outils de communication modernes comme les newsgroup et IRC sur lesquels on trouve des barbus assez compétents.
Pour ton code, vu que tu ne fournis aucun détail on ne peut rien dire, mais de manière générale, il vaut mieux préférer la composition à l'héritage.
# Commentaire supprimé
Posté par Anonyme . Évalué à 6.
Ce commentaire a été supprimé par l’équipe de modération.
# C'est quoi propre ?
Posté par Philippe F (site web personnel) . Évalué à 10.
Ce qui me gène profondément dans ton journal, c'est cette notion de "propre". D'une part, c'est un adjectif qui sous-entend que l'opposé serait "sale", ce qui pour quelque chose de virtuel est impossible. D'autre part, c'est un mot qui n'a aucune définition pour du code.
Je suppose que tu veux dire propre = respectant un certain nombre de principes de qualités. Mais tu ne cites pas les principes, on est donc largement dans du subjectif.
Passons un peu dans de l'objectif. Déjà, utilisons des mots sans connotation péjorative, c'est toujours désagréable pour un auteur de voir son travail insulté, d'autant plus quand c'est pas argumentée.
Quelles sont les attributs d'un code logiciel ? Ce qui me vient pour mon code et celui de mon équipe :
1) Lisible: c'est un peu abstrait, mais ça découle des principes suivants:
* règle de nommage cohérent dans toute la base de code
* le nom des fonctions dit ce qu'elles font
* le nom des arguments disent à quoi ils font référence
* des fonctions qui manipulent des arguments de même type utilisent le même nom
* les fonctions/méthodes sont relativement courtes
2) Documenté
* les arguments des fonctions sont expliqués
* les exceptions qui peuvent être générées dans les cas courant sont expliquées
* les valeur de retour standard et exceptionnelles sont expliquées
* le top, c'est quand il y a un exemple
* le tout en étant raisonnable, 10 lignes de doc pour une fonction de 1 ligne, c'est débile.
3) Maintenable
* ça découle des principes sus-cités en partie
* une chose ne doit être faite qu'une seule fois à un seul endroit pour des modifications faciles de comportement
* des abstractions sont construites au bons endroits pour des services rendus (mais cette partie-là est subjective et pas facile à expliquer)
* code livré avec des tests unitaires
4) Testable: on entre dans la zone du code de très bonne qualité
* jeu complet de test unitaire sur tout le code
* jeu complet de tests fonctionnels sur tout le produit
* les tests sont exécutables avec un seul exécutable bien nommé
* les tests ont eux-mêmes les attributs du code de qualité
Je n'ai pas mis que le code devait respecter les canons de la conception objet, car réellement, je ne pense pas du tout que ce soit indispensable. J'aime bien le style fonctionnel qui justement est à l'opposé de l'OOP académique. Et beaucoup de constructions OOP académiques se remplacent en une ligne de Python tellement ce langage est flexible [1].
Je vais plutôt au niveau de mon équipe insister sur le concept de "Loose coupling", couplage léger entre les composants, permettant de faire facilement évoluer un composant indépendamment des autres. Si l'objet répond à cette problématique, très bien. Si le fonctionnel répond mieux, je prend aussi. Si un mixte des deux fonctionne, je prend aussi.
Je suis très attaché aussi au KISS. Pas d'interface générique sur des trucs qui ne le méritent pas, mais par contre, j'encourage les interfaces simplifiées pour favoriser le découplage.
Pour en revenir à ton sujet, ce qui me choque, c'est qu'on a l'impression que "propre", pour toi, correspond uniquement au respect d'un canon de la Programmation Orienté Objet. J'en conclus que du code qui respecte tous les principes plus haut mais pas l'OOP serait pour toi non "propre" ?
Je t'invite réellement, d'une part à ne pas juger le code des gens avec des adjectifs péjoratifs et subjectifs.
Il m'est arrivé comme tout le monde de travailler sur du code externe et d'avoir des reproches à lui faire. Mais contrairement à toi, je vais parler de code inutilisable pour notre projet, inexploitable, difficile à comprendre, difficile à faire évoluer.
Bref, je ne porte pas de jugement de valeur sur la personne, surtout dans un forum public.
Note [1]: pire, certaines constructions académiques comme le Singleton vont à l'opposé du code de bonne qualité, car rendent les choses non-testables.
[^] # Re: C'est quoi propre ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
1)
Concernant les noms, je dirais même plus : il ne faut surtout pas être créatif, et utiliser le même mot même pour des objets de programmation différent. Par exemple en ocaml, l'espace des noms des type et des paramètres est séparé, il est donc souhaitable d'utiliser le même nom pour le type de la donné complexe et le paramètre des fonctions qui l'utilise.
2)
Pour la doc, il peut être souhaitable de maintenir à jour une spec en même temps que l'écriture du code et pointer sur les points de spec dans son code pour faire référence au niveau supérieur, cela évite de se noyer dans son code. Seul les points complexes ou non évident ont intérêt à être expliquer dans la doc.
3)
Une bonne métrique de la maintenabilité est le temps moyen de correction d'un bug (en gros <2h).
4)
C'est encore mieux si tes tests sont passées dans un outil de couverture de code, cela permet de voir ce qui a été oublié.
"La première sécurité est la liberté"
[^] # Re: C'est quoi propre ?
Posté par Guillaume Camera . Évalué à 1.
C'est exactement pour cette raison que je ne voulais pas m'étendre sur le code, j'ai encore beaucoup de choses à apprendre et je ne crois pas que je sois bien placé pour juger ce qui est 'propre' de ce qui ne l'est pas. C'est juste que d'un point de vue académique(pas que scolaire, mais le code que j'ai pu lire ou les API que j'ai pu utiliser), je ne suis pas habituer à voir ce genre de chose. Et je crois pas avoir dit que je trouvais cela moche, j'ai juste été surpris, et pour moi ça ne rentrer pas dans la logique objet.
Je ne voulais offenser personne encore moins cracher sur un travail.
Non, c'est plus un mélange de logique (qui peut-être ne l'est pas dans le cas cité) qui me titille la rétine, mais je dois surement manquer de méthodes d'organisation de code.
C'est quand même un compromis à trouver, la difficulté c'est de le faire tout seul. C'est bien de pouvoir avoir un avis externe sur la question, particulièrement quand on code pour son petit projet dans son coin.
Les quatre points que tu cites sont des bons éléments de réponses à la question que je pose finalement dans le journal.
[^] # Re: C'est quoi propre ?
Posté par Philippe F (site web personnel) . Évalué à 2.
Je te crois, mais réellement, le choix de l'adjectif "propre" est tendancieux.
Il y a peut-être un travail de désapprentissage de la programmation OOP à mener. Lis la dépêche récente sur John Carmack et la programmation fonctionelle. Il y a des liens intéressant sur l'approche fonctionelle dans différents langages, y compris Python.
Ca, c'est clair. L'expérience aide beaucoup. L'humilité aussi (je me suis planté, je reprends tout à zéro). Et le fait de se planter un certain nombre de fois est probablement le plus instructif.
De toute façon très clairement, pour savoir si tu as réussi ton découplage, il y a que le temps qui te le dira: le jour où tu dois faire une modif quelconque, le temps qu'il faudra pour l'appliquer, le nombre de méthodes, objets et fichiers touchés te diront si ton découplage était bien.
Voire même, tu n'avais prévu aucun découplage et c'était bien parce que à l'époque personne n'en avait besoin, ça aurait été une perte de temps de le faire et même si tu avais essayé, tu n'aurais jamais trouvé le bon niveau de découplage par rapport au besoin futur.
En ce sens, l'approche SCRUM / Extrem Programming sont intéressantes : le code est prêt au changement. Etre prêt au changement, ce n'est pas coller des interfaces qui abstraient tout et n'importe quoi, ça c'est juste être prêt à un changement très précis dans le code. Etre prêt à n'importe quel changement, c'est avoir plus ou moins les 4 points que je décris (et je prétends pas être exhaustif).
[^] # Re: C'est quoi propre ?
Posté par Jux (site web personnel) . Évalué à 4.
Ca j'en suis de plus en plus convaincu. Un des gros problèmes à mon avis, c'est que les écoles/uni (celles que je connais en tout cas) ont tendance à avoir des cours de POO complètement débiles où on crée une hiérarchie complexe pour un petit problème (parce que sinon ça tient pas dans un labo) et où un étudiant qui arrive avec une solution faite de 3 fonctions de 10 lignes et un tableau va se faire démonter par le prof.
La POO, c'est sympa, mais dans 90% de ce qui est présenté à l'école (et dans les tutos sur le net), le code serait plus simple, moins long et plus compréhensible avec juste quelques fonctions. Et garder la POO pour les parties où c'est vraiment utile, où ça simplifie les choses.
Cette présentation "Stop Writing Classes" concernant la POO en Python est très très pertinente à ce sujet :
http://pyvideo.org/video/880/stop-writing-classes
[^] # Re: C'est quoi propre ?
Posté par freem . Évalué à 1.
Ce que j'ai surtout constaté dans les cours sur l'OO, c'est que jamais personne ne m'a parlé de design pattern… Même pas GRASP, qui poutant est la base d'une conception adaptable…
[^] # Re: C'est quoi propre ?
Posté par djano . Évalué à 2.
Mauvais cours, changer de cours :)
Plus sérieusement, la programmation est un art difficile car elle requiert un très long apprentissage. Même si l'on t'avait présenté quelques design pattern, tu ne les aurais pas tous vus, et surtout pas ceux dont tu as/auras besoin. Il va falloir te former tout seul, lire et relire des articles, pratiquer encore et toujours.
Tes pratiques vont aussi évoluer avec le temps.
Pour la route voici un PDF intéressant qui a fait évoluer mes pratiques sur comment concevoir une API:
http://lcsd05.cs.tamu.edu/slides/keynote.pdf
Voici un des principaux enseignement que j'en ai retiré: vive l'immutabilité, elle m'a permis de diminuer par 3 la consommation mémoire d'une application!
[^] # Re: C'est quoi propre ?
Posté par freem . Évalué à 2.
Bah en fait, mes cours remontent à il y a quelques années alors en changer, s'trop tard :D
Mes pratiquent ont pas mal évolué en fonction de ce que j'ai fais, et des sujets que je travaille dans mes loisirs, notamment grâce à l'open source. Sur ce point, je crois que les logiciels libres ont été mon meilleur prof, même sans y avoir réellement contribué:
Pour certains points, les cours (de BTS du moins) ne pouvaient pas enseigner ces choses, mais pour d'autres (les VCS, par exemple) il aurait été pas mal qu'on aborde les classiques (à l'époque, CVS et SVN déjà)
Le boulot n'a que peu fait évoluer mes méthodes pour le moment, à mon grand regret. Pas non plus énormément d'expérience professionnelle il faut bien le dire :D
[^] # Re: C'est quoi propre ?
Posté par djano . Évalué à 2.
Mauvaise boite, changer de boite ;)
Non je rigole.
Il faut dire qu'un BTS est tout de même très (trop?) court pour aborder les nombreuses choses a voir, et même dans des études plus longues (master, école d’ingé), c'est tout de même très difficile de tout voir.
Par exemple, j'avais utilise CVS et SVN dans des projets, mais personne ne m'a enseigne les tests unitaires, alors que j'aurais gagne un temps fou a éviter de retester manuellement les mêmes 3-4 fonctions que l'on avait développé sur le logiciel. J'avais fait su scheme (un (()langage (((LISP))()))), de l'assembleur, du C, C++, Java), mais les tests n'avaient jamais vraiment été abordés.
Les tests sont les parents pauvres de l'éducation en programmation informatique en France (et ailleurs?), et c'est bien dommage.
Bref, je peux juste te recommander de lire certains des liens qui ont circulé sur cette page, lire du Martin Fowler ("Refactoring: improving the design of existing code", j'adore :) ) ou d'autres auteurs comme Paul Graham, Jeff Atwood, Joel Spolsky, Kent Beck, Le Gang of Four (Design Patterns: elements of reusable design) etc. Lis aussi tout sur XP, c'est au moins intéressant pour les pratiques de programmation.
Le plus marrant, c'est que ces articles se contredisent parfois, et c'est la que ça devient intéressant pour que tu te questionnes et te fasse ta propre opinion. Pas toujours tout de suite, mais parfois avec le temps.
Pour finir, pratique encore et toujours, donne toi des petits defi, mais pense toujours que:
Chaque ligne de code c'est du "legacy": c'est plus un problème qu'une solution. Donc si tu peux réduire le nombre de ligne de code, c'est vraiment le mieux.
Le code est lu 10, 20 ou encore plus de fois qu'il n'est écrit, alors soigne particulièrement le code avant de le committer: demande toi si tu en as réellement finis. Doit tu ajouter des commentaires qui expliquent POURQUOI le code est tel qu'il est. Doit tu refactoriser le code? Doit tu renommer cette méthode, est que ce nom est bien choisit? Y-a-t il de la duplication, etc.
Sur ce même sujet, il te faut 2 fois plus d'intelligence pour debugger ton code qu'il ne t'en a fallu pour l’écrire, alors évite le code trop "sioux" :) et pense aussi que tous tes collègues (même les moins bons) doivent pouvoir travailler sur ton code.
Demande a des pairs plus compétents que toit de revoir ton code (pas le gars le plus nul de la boite, parce que ça passe comme une lettre a la poste) et écoute les critiques.
Bien sur, tout ça doit se faire dans le meilleur rapport temps / productivité pour corser le tout. :)
Mais je t'assure que si tu suit les conseils ci-dessus, tu vas progresser a vitesse grand V.
Et tout le monde fait des erreurs a un moment ou a un autre de tout façon ;)
[^] # Re: C'est quoi propre ?
Posté par freem . Évalué à 2.
La pratique, ça à toujours été mon meilleur prof : je suis auto-didacte pour 95% de mes connaissances informatique (hum… en solo: QBasic, asm x86, langage C, programmation générique, C++11, linux, bidouillages windows, reverse engineering (ouai, bon, ok, cracking plus qu'autre chose), diverses techniques d'attaque, gestion de version, cmake, perl, shell, licences libres, design pattern du GoF et GRASP, technique de chiffrement, de dissimulation et d'autres trucs que j'oublie certainement. En cours: les classes, le sql, merise, UML, notions de réseau renforcées, active directory, notions de droit. C'est à peu près tout… donc pas 95%, mais plus de 60% si on considère que c'est du 1 vs 1, ce dont je doute TRES fortement. ).
Après, potasser… je fais ça quand je tombe sur un article qui m'intéresse, ou qui traite d'un problème que je rencontre (ou ai rencontré). D'ailleurs, faut que je dégotte une solution pour plier openGL à mes caprices :P
Pour ce qui est d'éviter les astuces de sioux, c'est clair, et pour le nombre de lignes de code, ça fait longtemps que j'applique le fameux principe du fumiste: moins j'en fait, mieux j'me porte!
Et pour vérifier que le code est compréhensible par les autres, un outil que j'aime beaucoup, même s'il à ses limites, c'est cccc : C and C++ Code Counter, qui mesure divers indices et donne une idée de la complexité: nombre de chemins de code, entres autres.
Dommage qu'il ne supporte pas très bien les template, tout de même. Mais malgré ça, pas mal de bons indices sur le code à améliorer si on vise la lisibilité. Et conséquence annexe, on se retrouve avec un code plus performant :P (moins de lignes, moins de bugs, moins de mémoire bouffée, ce genre de choses…)
[^] # Re: C'est quoi propre ?
Posté par galactikboulay . Évalué à 1.
Dans la partie lisibilité, on pourrait rajouter l'indentation - pour avoir corrigé des programmes d'étudiants qui mettaient tout au même niveau, je peux dire que c'est vraiment ignoble pour comprendre ce que le code fait.
[^] # Re: C'est quoi propre ?
Posté par ckyl . Évalué à 4.
Et si vous voulez un peu plus de matière objective il existe un bon bouquin chez Microsoft Press qui contient 900 pages de bonnes pratiques et de bons et mauvais exemples: Code Complete par Steve McConnel. N'importe quel développeur expérimenté l'ouvrant se dira de prime abord que c'est une suite de trivialités mais si on passe l'étape de l'ouvrir avec un œil autocritique et en cherchant à trouver les petites choses qui rendent le code meilleur il est très intéressant.
Après ce genre de choses ça ne reste que la souche de la programmation.
# La différence entre le bon et le mauvais développeur
Posté par Nasga . Évalué à 10.
Tu vois y'a le mauvais développeur, il est sur un projet, il code.
Le bon développeur, il est sur un projet, il code mais c'est un bon
chasseurdéveloppeur…# Question d'intelligence
Posté par lordblackfox . Évalué à 0. Dernière modification le 16 novembre 2012 à 12:59.
Donc en suivant ta dernière phrase, tu viens de te jeter des fleurs ;)
(Par contre, j'approuve l'idée du site collaboratif)
[^] # Re: Question d'intelligence
Posté par barmic . Évalué à 4.
Je ne pense pas, il est plus simple d'apprécier la qualité de quelque chose que de la produire.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
# tu vis chez les muets ?
Posté par fearan . Évalué à 2.
Ou à l'étranger au choix, parce que dire "mon code est propre" ça je le peux, je viens de le faire.
Bon blague à part la actuellement je bosse sur du code que je dirai over-engineering raté. Pour rajouter un message ne contenant qu'une chaine de caractère entre le client/Serveur faut modifier une dizaine de fichiers java différent. Si tu veux ajouter une chaine de caractères aux résultats des codes de calculs(c++) tu en as pour une grosse quinzaine rien que pour l'avoir coté serveur java (il reste encore le client java où faut le propager). Dont une bonne moitié coté c++, 'merci thrift!
à un moment on transmettait l'équivalent de map (clé->valeur) entre java/c++, mais il a été dit que c'était pas 'beau' et qu'il valait mieux passer par des objets complètement définis. Je sais pas, entre 2 fichier à modifier et un truc conceptuellement pas top, et 18 fichiers à modifier (je viens de vérifier dans les changesets, fait en deux fois évidemment, vu qu'il y a eu un oubli lors du premier) ma décision va à la version où y a que deux fichier à modifie, surtout qu'on peut factoriser le traitement de conversion de la map c++ => java, ce qui est impossible avec des objets différents sans introspection sans de devoir définir des interfaces assez lourdes…
Bref, code propre, ça dépend surtout de ce qu'on entend par propre.
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
# Heureusement qu'il y a Bibi pour rappeler les grands classiques...
Posté par calandoa . Évalué à 10.
# Réponse simple à la question.
Posté par 2PetitsVerres . Évalué à 4.
Du code propre, c'est au mieux quelque chose de relatif, au pire quelque chose qui n'existe pas.
Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.
# Comme dirait Bernard la marionnette des guignols
Posté par Christophe B. (site web personnel) . Évalué à 0.
C'est comme le pucelage, t'as la trouille avant, après t'en es fier …
Le dredi c'est permis :)
A+
chris
# Le code propre...
Posté par liberforce (site web personnel) . Évalué à 3.
…c'est du code que j'ai écrit. Le code sale, c'est les autres.
C'est ce qu'une bonne partie des développeurs a l'air de penser, du coup ça fait souvent un second trou au c*l de repasser derrières ces "bons" développeurs… De même que si je relisais du code que j'ai écrit il y a quelques années, j'en ferais sans doute une jaunisse.
[^] # Re: Le code propre...
Posté par ckyl . Évalué à 3.
Pourquoi quelques années ? Reprend le code du mois dernier ça marche aussi ;)
L'apprentissage est lent, par contre l'oubli de ce qui a forgé les choses est rapide.
[^] # Re: Le code propre...
Posté par liberforce (site web personnel) . Évalué à 3. Dernière modification le 16 novembre 2012 à 19:25.
C'est pour ça que je mets beaucoup d'énergie dans le style et la beauté du code. N'ayant pas une mémoire phénoménale, le seul moyen de m'y retrouver plus tard c'est d'être le plus clair et le plus lisible possible. Et puis j'ai suffisemment récupéré du code de merde pour ne pas avoir envie d'infliger ça aux gens qui passent après moi…
Je pense que c'est pour ça qu'on parle de code "propre" ou "sale", c'est un peu comme l'hygiène. C'est comparable à l'état dans lequel tu laisses les chiottes pour celui qui passe ensuite.
[^] # Re: Le code propre...
Posté par Sufflope (site web personnel) . Évalué à 2.
Ah ouais ça marche bien cette métrique ! En plus c'est cohérent avec la taille de la boite et ton implication (donc le temps que tu penses y passer) : plus la première augmente et la seconde diminue, moins tu as de risque de te faire chopper donc plus tu laisses de traces immondes de ton passage !
# package-by-feature, urbanisation
Posté par djnet . Évalué à 1.
Depuis que j'ai lu ça:
package-by-feature
… je me méfie des architectes techniques (ceux qui veulent, entre autre, mettre toute la couche persistance dans un package; ce qui rend impossible la 'brique logicielle réutilisable')
Organiser, son code du point de vue 'métier' (feature),
c'est se caler sur le point de vue 'utilisateur'
(les avantages sont détaillés dans le lien).
L'urbanisation du SI (ou architecture d'entreprise),
c'est la même chose au niveau du SI:
caler les 'services', 'applications' sur les 'offres métiers'.
Bonne Journée à tous !
# Du code propre, c'est quoi ?
Posté par jpllaroche (site web personnel) . Évalué à 2.
Bonjour,
pour moi qui est 40 ans d'informatique et je code encore
c'est de produire du code que tous le monde peux relire!!!!
bien-sur connaître ça machine et plus tu la laisse faire ce quelle sait mieux c'est
bien pour cela ex: sur le Ipower (AS400) les personnes réinvente le cycle et moi je peux te dire tu n'arriveras jamais a la hauteur
donc un excellent compilateur et un langage digne de ce nom il faux d'abord en exploiter les ressources avant de réinventer la roue dans l'écriture du code
quand je programme en C++ sur linux et que je vois que pour utiliser du MAP on me dit aaaah avec les vector je peux refaire et plus rapide
je me dit il a rien compris et en plus ça beug les fonctions qui sont mise a dispo j'essaye de les utiliser et de rester claire
le procédural n'est pas mauvais et le modulaire non plus ( j'utilise la méthode AXIAL) mais parfois je vais faire hurler ( un bon goto ) est plus rentable
en 1979 je comptais encore les octés ,les programmes d'aujourd'hui ne font pas mieux ( je parle en gestion) quand je vois qu'il faut 15MO alors que j’utilisai 24 ko pour faire la même chose !!!! là je suis sur un projet perso je voudrais réactualiser un vieux Designer Screen TUI avec Ncures et montrer que cela marche tout aussi bien
tu vas a l'usine les guas ils veulent pas de la sourie les écrans dont-il faut cliquer 30 fois pour avoir la réponse et revenir en arrière pour finir brefff les objets on fini par ne plus savoir ou en est comment ça marche
je ne suis pas contre l'objet mais la maintenance du programme une grosse application de gestion Entreprise de A-Z c'est 1200000 lignes si là tu réfléchies la clarté de ton code c'est la possibilité de pouvoir dire que si tu as une modification importante tu peux te permettre de faire un programme qui vas modifier ton code sans avoir a tout te le taper a la main faire un analyseur qui te dit ou et quoi faire …. ont pourrait déliré beaucoup sur ce sujet
car un excellent code est ce que pourquoi ont veux l'utiliser si c'est ultra-perfomance ou la qualité de la maintenance deux chose pas incompatible mais des-fois complètement a l'opposé et pourtant cela peut être de excellent code l'un il faut passer 15 jours pour comprendre l'autre il est lisible et modifiable par tous et de suite …..
c'est vrais je suis un vieux pépé mais je relie encore certain livre et je me documente encore pour produire du code aujourd'hui je vois que pour le C++ X0 enfin je le souhaite on vas vers une proposition ou la réinvention du printf le compilateur diras niet j'exagère un peu LOL la fonction existe utilise la fonction
regardez l’histoire du DCML il n'y a pas longtemps qu'il est mise à dispos dans GCC (et je ne parle des autres MS….) même si IBM avait mise a dispos ce n'est pas normale un chiffre double n'a rien avoir avec des zones de 30,10 DCML j’achète un camion de boulon aux poids (tonnes) et je revend les boulons à la pièces votre double il est a la ramasse
aujourd'hui depuis 30ans on a pas fait avec du C++ un langage un truc ou la base de donnée l’écran le printer (prtf) le programme quelque chose qui parle simplement il n'y a pas d'unification des buffers ( a pas confondre a union) ont reste du source compiler on a pas un environnement objet pourtant les mécanismes sont simple,
une déclaration de file dont les composantes d'un record sont fait d'objets le programmes devrais avoir une unification dans le comportement sans mon intervention reconnaissance automatique objet attribut partage de relation ( ps sans include de sources lol) enfin de compte ont fait plein de truc avec le c++ presque de l'assembleur mais cela souffre… et devrais utiliser des techniques OO (ObjetObjet) a ne pas confondre avec ++ bon peut-être devrais-je me tourner vers Smalltalk des année 80 …. Non je voudrais que mon langage C++ soi plus riche
( je crois que je vais partir à la retraite et je n’aurais pas vue quelque chose qui dépasse l'OS400/IBM38 en terme de propreté et de cohérence Sécurité) voilà mon problème?
**amicalement**: j'ai essayé de montrer que la propreté du code est lier à plein de paramètres …. qu'il est difficile de définir simplement ce qu'est du code propre sans tomber dans les querelles de clocher.JPL @bientôt
[^] # Re: Du code propre, c'est quoi ?
Posté par ckyl . Évalué à 10.
Ce qui est rigolos puisque je pense que personne ne peut relire ou comprendre ton commentaire…
[^] # Re: Du code propre, c'est quoi ?
Posté par jpllaroche (site web personnel) . Évalué à -1.
Merci d'avoir quand même essayé
car du code propre si je parle pas dans ton langage basic car la connaissance ne ce limite pas au PC mais bien au-delà donc "OO" tu connais pas voilà peut être une chose qui te ferais du bien.
code propre à lire ce qui est au dessus pour beaucoup c'est un style !!!!! dommage car les 4 ou 5 styles en C++ ce valent….. donc je n'ai pas envie de polémiqué et la méthode AXIAL tu comprends pas OK c'est américain IBM complètement différente de Merise mais pouvant l'utiliser et pas l'inverse ou alors la réponse que je voulais dire ne te parait pas explicite du genre programme inbouffable car pour l'utilisateur "d'une complexité tordue" et n'en veux pas, donc "Sale le code". Car on programme pas pour soi …. c'est vrais moi je fais de la GESTION D'ENTREPRISE et pas un programme de dessin ou autre évidement il y a une grande différence lollllllllll j'ai vue tellement de personne arrivé du monde PC expert et qui n'étaient même pas capable de s’intégrer dans une équipe , sur qu'il savaient programmé mais mais pour fabriqué leurs bidouilles. n’intégrant pas le standard de la l'entreprise ni ne communiquaient.
Et quand je dis qu'avant de réinventer la roue dans un langage on ferais mieux d'utiliser ce qui existe que cela est plus performant et mieux écrit je suis sur de ce que je dis.
je ne jette pas la pierre mais peut être dans le C++ qu'il manque des fondamentaux qui rendais cela plus lisible ???
"Humour je sais me moquer de moi et a juste titre"
bon j’écris comme je parle je fais des fautes je suis logique et pas le français hirondelle prend 2 LL parce-qu' elle a 2 ailes et vélo prend un L parce qu’il a deux roues j'avais 19,5 en dissertation et -80 pour les fautes
et alors…
mais je suis fiers car j'ai du code qui tourne qui est utilisé sans le savoir dans leurs quotidiens de programmeur
je suis pas connu parce que cela ne m’intéresse pas cela m'a permis de m’éclater tranquillement…
JPL @bientôt
[^] # Re: Du code propre, c'est quoi ?
Posté par jpllaroche (site web personnel) . Évalué à -1.
PS j'aurais du le dire et c'est un défaut certaine chose devienne évidente après 40ans d'informatique
l'explication "Du code propre, c'est quoi" de Posté par Philippe Fremy (page perso) le 16/11/12 à 12:34. Évalué à 10.
est tellement implicite que je voulais donner d'autre directions sur cette discussion
JPL @bientôt
[^] # Re: Du code propre, c'est quoi ?
Posté par ckyl . Évalué à 5.
J'avoue que je suis complétement largé. Je pense que si tu postais des journaux ou un blog pour nous faire part de ta sagesse issu de ton expérience beaucoup de personne t'en serais reconnaissantes.
D'ailleurs j'encourage tout le monde à aller voir ton site web, c'est un receuille de pépites pour tout développeur cherchant à s'ameillorer ! On comprend d'un seul coup la qualité de ton discours et le recul que tu as sur les choses.
[^] # Re: Du code propre, c'est quoi ?
Posté par jpllaroche (site web personnel) . Évalué à -1.
[tu comprends pas OK c'est américain IBM complètement différente]
bon là encore Merise à été largement plus en France qu'ailleurs mise en avant, la méthode AXIAL elle permet (explication très bref) de développer et de mettre en production des entités (ex: gestion de bilan comptabilité) sans avoir a réalisé l'ensemble de la comptabilité tant en analyse organique ou fonctionnelle avec tout ce qui impose pour l'acceptation du projet, de plus l'analyse ce conçois sur la base de données dont on utilise en partie la théorie des ensembles et la granulation de la base de données en quelque sorte on sépare les entités au travers de la BD relationnel et prévois la communication entre ces entité avec la BD , la programmation ce trouve très allégé et l'ensemble des modules tant pour le nombres de lignes et la cohérence et maintenance.
Mais comme tu le vois cela peux aussi être vite le bordel donc cela nécessite d'avoir un vrais architecte ayant la connaissance de sont environnement et gardant Merise en tête et bien en tête. Ceci est le point faible d'AXIAL , IBM en Europe dans les année 80 avait pris cela en charge et pensait que cela rentrerait rapidement en université, comme d'habitude "COMME ON EST IBM ON CROIS QUE TOUT LE MONDE NOUS REGARDE" pour preuve OS2 ou le bios donnée a Bill. bref aujourd'hui je pense que l'on devrais faire une pose et rassembler tous ce qui est BON plutôt que de continuer a produire dans son coin quitte à réinventer X fois la même chose.
Linux est aujourd'hui quelque chose de stable et facile a appréhender (mettre en place) mais il na pas un environnement qui comme l'OS400 à une intégration RELATIONNEL entre la programmation la Bd la gestion interactive (Ecran) la gestion papier (Liste divers facture etc..) le C/C++ est un langage très propice pour réalisé cela ( AS400 écrit en MI machine interface a été réécrit en C++) j'aimerais que Linux y vienne cela ferais la pige A MS qui a sont "AX" lollll car lui il a compris, il avait jusqu'à ces dernières années des as400 pour géré son entreprise c'est quand même un monde!. Linux est capable et largement capable de répondre actuellement a celui de tous les utilisateurs aussi bien que Windows le tournant actuellement est sur les grands projets tel que l'AS400 est capable de les gérés MSSQL a pris une bonne longueur de retard en comparaison PostgreSql qui fait de l'ombre a Oracle….
@bientôt j'aime ce forum car il y a des sujets intéressants et des réponses qui vont du sujet très simple à quelque de très compliqué j’écris rarement mais je lit beaucoup. "_Merci d'avoir pris le temps de me lire_.CYKL"
JPL @bientôt
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.