Critique de l'ouvrage "Coder proprement" de Robert C. Martin

[sjrd]

05/08/2010

Envoyé par benwit

Et de trois : http://conception.developpez.com/liv...L9782744023279

Et vous qu'est-ce que vous en pensez de sa règle J1 ?

Pour moi :
quote]il manque de cohérence avec sa règle J1 sur l'importation des classes dans Java. D'une part, il dit qu'une longue liste d'importation effraie le lecteur mais c'est oublier que les chers IDE modernes (qu'il invoque quand ça l'arrange) les cachent automatiquement. D'autre part, dire que le caractère générique crée moins de dépendance que l'import spécifique d'une classe, je vois vraiment pas en quoi ???

[/QUOTE]

Nouvelle critique parue :
Coder proprement de Robert C. Martin

[Baptiste Wicht]

Seconde critique du livre : http://conception.developpez.com/liv...L9782744023279

Un livre tout simplement indispensable pour apprendre à coder proprement. En plus de nous apprendre à coder proprement, il nous apprend également pourquoi il faut le faire, ce qui est indispensable pour motiver quelqu'un à programmer proprement. Ce livre m'a beaucoup appris sur la bonne manière de coder. Tous les éléments théoriques du livre sont mis en pratique via des exemples concrets de code. En plus de cela, un chapitre entier est consacré au remaniement d'une classe et un autre au remaniement d'un petit programme.

[...]

Un livre, tout simplement génial, que je conseille à tout un chacun

[maxim_um]

Quelques extraits au format PDF mis à disposition par Pearson:

Table des matières
(pdf 198 KB)

Introduction
(pdf 258 KB)

Extrait du chapitre 1 - Code propre
(pdf 689 KB)

Extrait du chapitre 5 - Mise en forme
(pdf 463 KB)

Extrait du chapitre 12 - Emergences
(pdf 74 KB)

[nprovost]

Excellent ouvrage ! Même s'il adopte un point de vue effectivement assez radical mais bien adapté à un langage "moderne" comme Java ou C#, il entraîne avant tout à prendre du recul sur le code que l'on écrit. C'est donc d'abord une méthodologie profitable au plus grand nombre, qui tord le cou à certaines habitudes ou en explique l'origine. Nombreux exemples.

[leToto]

Ce livre est un véritable régal, et tout est dit dans le titre : il s'agit d'apprendre à coder proprement.

La lecture coule en soi, le style d'écriture est propre, et les notions abordées sont plus que dignes d'intérêt.

A recommender à tous, surtout aux débutants qui auront ainsi une très bonne base question qualité de code.

[maxim_um]

Je ne l'ai pas lu, mais il parait qu'il est moins intéressant qu'un autre de ces ouvrages traitant aussi du même sujet, en l'occurrence «Agile Software Development: Principles, Patterns, and Practices». Cela dit, je n'ai pas regardé si ce livre a été traduit.

[benwit]

Et de trois : http://conception.developpez.com/liv...L9782744023279

Et vous qu'est-ce que vous en pensez de sa règle J1 ?

Pour moi :

il manque de cohérence avec sa règle J1 sur l'importation des classes dans Java. D'une part, il dit qu'une longue liste d'importation effraie le lecteur mais c'est oublier que les chers IDE modernes (qu'il invoque quand ça l'arrange) les cachent automatiquement. D'autre part, dire que le caractère générique crée moins de dépendance que l'import spécifique d'une classe, je vois vraiment pas en quoi ???

[vintz72]

Envoyé par benwit

Et de trois : http://conception.developpez.com/liv...L9782744023279

Et vous qu'est-ce que vous en pensez de sa règle J1 ?

Pour moi :

Euh... c'est quoi exactement sa règle J1 ?
Pour les imports, c'est clair qu'avec un IDE moderne, je trouve préférable de lui laisser faire son boulot. Ca évite même des désagréments en cas de recherche textuel par exemple.

[benwit]

J1 dit qu'il faut mieux faire des importations génériques (avec *) que spécifiques.
Exemple :
préféré un import java.io.*
à import java.io.File; import java.io.Inputstream, ...

Je dis que si les imports spécifiques prennent effectivement plus de ligne, c'est masqué avec avec les IDE moderne (argument que je lui renvoi puisqu'il les cites lui-même)
Mais concernant la dépendance, je ne vois pas.
Il a l'air de dire qu'avec l'import * il y a moins de couplage.
Je ne vois pas puisque dans les deux cas, si tu as besoin de l'import, c'est que tu utilises la classe. Dans les deux cas, si elle disparait du package, ça ne marchera plus !
Je préfère le import explicite car tu vois précisément les références.

Si vous comprenez ce qu'il veut dire, merci de m'expliquer.
Il faut que je regarde une version originale pour vérifier si cela a bien été traduit.

Pour ceux qui voudrait avoir un aperçut de ce livre, il y a quelques pages en aperçut dans Google Book.
Moi personnellement ça m'a vraiment donné envi de l'acheter, je vais le commander ce weekend.

[Baptiste Wicht]

Personnellement, je déteste les import génériques et c'est effectivement quelque chose avec lequel je n'étais pas d'accord lorsque j'ai lu le livre.

Je trouve très bien que les imports spécififiques prennent beaucoup de place, ça permet de se rendre compte qu'une classe a besoin de beaucoup d'autres (trop ? ) classes pour fonctionner.

Pour ce qui est du couplage diminué, je ne vois pas non plus.

[dissert]

(benwit) En conclusion, ce livre est à mettre entre les mains de tous débutants, cela ne fait aucun doute. Pour les développeurs plus aguerris, c'est déjà plus discutable, je leur conseillerai cependant pour découvrir l'argumentaire de cette école de pensée ou pour soulager leur névrose.

Je ne suis pas d'accord avec la cible du livre décrite ici.

Je pense qu'il faut une certaine séniorité dans le métier pour pouvoir prendre du recul par rapport aux principes énoncés. Autant les arguments m'ont parut souvent pertinents dans ce livre, autant les exemples ne sont pas toujours bons, et en particulier, en ce qui concerne l'étude de cas (chapitre 15), j'ai trouvé que l'application des différents principes n'étaient pas toujours clairs et surtout l'utilité de cette application n'était pas forcément évidente.

Et, pareillement à plusieurs ici, je suis contre les imports génériques (règle J1).

<troll mode="on">En Scala, on peut définir des imports "semi-generique", avec des sortes de regexp, qui permettent de déclarer exactement ce que l'on veut avec un minimum de lignes</troll>

[cinemania]

en même temps les imports générics, règle J1 ne s'appliquent pas à tous les langages.

en effet, les directives d'imports/using dans les autres langages, portent généralement sur tout le package/namespace.
en dotnet, il est préférable s'il n'y a pas de risque d'ambiguïté des noms, d'inclure un namespace, plutôt que de qualifier pleinement le type quand on l'utilise, sinon on nuit sévèrement à la lisibilité du code, surtout si le namespace fait 15km de long... cela va si on utilise des types System.String, mais plus du tout dès lors que l'on commence à nécessiter ce genre d'écriture... System.Collections.ObjectModel.ObservableCollection<System.String>
Les IDE comme Visual Studio 2010 indique clairement le nom et types complet lorsque l'on passe la souris au dessus de la déclaration, donc inutile de rendre le code illisible.

maintenant en java, où l'on peut spécifier, clairement le type importé, en haut avant le code dans la liste des imports, là il est évident qu'il vaut mieux faire des inclusions explicites.

Ensuite pour ce qui est des dépendances... il a tout simplement fumé la moquette avant d'écrire son postulat... que tu fasse une inclusion spécifique ou une inclusion générique, cela ne change rien au niveau de dépendance de l'application.

[yamura]

Je n'arrive pas à trouver de site web ou acheter ce livre, amazon est épuisé :s

[blstef]

J'ai fait des recherches car il m'interressait aussi:

Tu peux l'acheter en PDF pour 32,30 € (trop cher à mon avis) sur le site de Pearson:
http://www.pearson.fr/livre/?GCOI=27440100643800

Sinon la version originale en PDF pour 14 $ (plus raisonnable) mais je ne sais pas s'il on peut tout de même l'acheter (blocage par pays)...
https://memberservices.informit.com/...ner=53&cmd=add

Sinon, le site slideshare.net le propose en ligne:
"www.slideshare.net/MarwenMhamdi/coder-proprement"

Bonne lecture ;-)

[molarisapa]

Livre génial

La plupart des livres que je lis, je finis toujours par les revendre par la suite sur le marché de l'occasion.

Mais celui-ci je le garde pour le ranger dans ma bibliothèque parmi les classiques comme Design Patterns du "Gang of four", ou les ouvrages de Stroustrup