swilmet a écrit 647 commentaires

Refactoring: Improving the Design of Existing Code (Martin Fowler)

Je ne l'ai pas lu, mais à la fin du chapitre sur le refactoring dans Code Complete, c'est la seule ressource additionnelle qui est donnée, avec ce commentaire :

This is the definitive guide to refactoring. It contains detailed discussions of many of the specific refactorings summarized in this chapter, as well as a handful of other refactorings not summarized here. Fowler provides numerous code samples to illustrate how each refactoring is performed step by step.

Mais il faut savoir que la 2e édition de Code Complete est sortie en 2004, donc il se peut qu'un autre livre plus récent, et peut-être meilleur, est sorti.

Voici ce qui est dit dans le livre, qui s'applique tant pour les for, que pour les while :

Si un index de boucle doit être utilisé en-dehors de la boucle (parfois bien après), c'est préférable de lui donner un nom long.

Si une boucle est assez longue, il est facile d'oublier à quoi correspond le i ou le j (donc il faut souvent revenir en haut de la boucle pour voir à quoi elle correspond). Du code est souvent modifié, étendu, et copié dans d'autres programmes, donc beaucoup de programmeurs expérimentés évitent complètement des noms comme i.

Une des raisons pour lesquelles les boucles s'allongent est qu'elles sont imbriquées. Pour améliorer la lisibilité, il vaut mieux mettre des noms longs. Ça permet d'éviter de confondre i et j, et ça rend certaines lignes plus informatives (comme je l'ai expliqué dans le journal).

Si vous devez vraiment utiliser i, j et k, faites le uniquement pour des boucles simples (donc qui ne sont pas imbriquées, et qui ne sont pas très longues, et dont l'index n'est pas utilisé en-dehors). Mais pour éviter tout problème, c'est plus simple de se donner une règle où on n'utilise pas du tout les i, j et k.

---

Voilà, pour moi la meilleure raison est la première, que j'avais déjà expliqué dans le commentaire juste au-dessus.

En ayant lu The Pragmatic Programmer, tu risques de connaitre déjà beaucoup de chose en lisant Code Complete. Mais Code Complete parle de plus de sujets.

Beautiful Code est sorti en 2007, donc c'est normal que Code Complete (2e édition en 2004) ne le référence pas, mais ça a l'air intéressant. Il y a aussi Programmers at Work, qui est plus ancien.

Oui, c'est un des conseils qui est assez controversé.

Ce qui gêne plus, c'est quand le i ou le j est utilisé en-dehors de la boucle, pour retenir par exemple le dernier index valide ou qqch du genre. Dans ce cas il vaut carrément mieux créer une autre variable retenant cet index, avec un nom qui permet de savoir de quoi il s'agit.

Dans le lien que tu donnes, il y a un commentaire contradictoire :

[...]
le vocabulaire est parfois incorrect et que vous vous énerverez régulièrement devant les coquilles.

Ah ben tant mieux s'il est bien écrit, tu fais bien de le dire.

Mais personnellement, en informatique je préfère lire de l'anglais. J'ai donné une raison (les termes techniques qui ne sonnent pas bien en français). Mais c'est aussi un bon entrainement, on apprend du vocabulaire, etc.

Aussi, le dernier paragraphe c'était histoire de troller un peu vers la fin :) Il fallait bien que quelqu'un ne soit pas du même avis.

Oups. J'ai oublié de parler des points négatifs.

Dans le livre il y a dans les marges pas mal de références vers d'autres sections du livre, mais les références sont trop vagues (il faut chercher une sous-sous-section parmi une quinzaine de pages parfois…), il faudrait des numéros de pages.

Et aussi, le texte est en « fer à gauche » au lieu d'être justifié. Mais bon on s'y fait.

Sinon, hors-sujet, mais je dois pas être fait pour le marketing : je suis arrivé à écrire « Bref, à déconseiller. » tout à la fin, alors que je n'ai montré que des points positifs du livre :)

Si tu n'aimes pas le titre du thread^W fil, rien ne t'empêchais de la changer dans ton propre commentaire.

C'est d'ailleurs une fonctionnalité très peu utilisée sur Linuxfr je trouve, et qui serait bien pratique, pcq parfois certains fils deviennent monstrueusement long, et ça part dans tous les sens.

Si en plus tu organises ta façon de travailler correctement, c'est très correct.

C'est ça que je n'aime pas avec GNOME 3, c'est qu'il y a beaucoup moins de « façon de travailler correctement » qu'avec GNOME 2. Avec GNOME 2 c'était beaucoup plus flexible de ce côté-là.

Par exemple, pour ma part, j'aime bien avoir plusieurs fenêtres différentes maximisées sur le même espace de travail. Avec GNOME 2, en un seul clic je vais sur la fenêtre de mon choix. Avec GNOME 3, peut importe la méthode, ça demande plus d'étapes.

Ma mère et ma petite sœur n'ont jamais utilisé plus d'un espace de travail, bien que je leur ai déjà expliqué plusieurs fois, que c'est vraiment pratique, etc. Rien à faire. Avec GNOME 3, si tu n'utilises qu'un seul espace de travail, c'est l'enfer, là où avec GNOME 2 c'est encore gérable.

J'avoue que je considère assez fortement de rester sur gnome-panel+metacity plutôt que de passer à gnome-shell+mutter. Et si un jour ça n'est plus maintenu je créerais un fork sans hésiter

De nouveau, si le mode fallback te convient bien, pourquoi créer un fork ? Il « suffit » de continuer à maintenir gnome-panel et metacity, quand les développeurs décideront de les abandonner.

Commentaire de Linus :

While you are at it, could you also fork gnome, and support a gnome-2 environment?

Ce qu'il faudrait plutôt, c'est régler toutes les régressions de gnome-panel et de continuer à le maintenir¹. Je sais qu'il y a certaines applets manquantes, par exemple (mais certaines applets sont externes au projet GNOME, donc pour ça on ne peut pas leur en vouloir). Je ne sais pas où en est GNOME 3.1 à ce niveau-là, mais la version 3.0 apportait quand même pas mal d'améliorations de gnome-panel par rapport à GNOME 2, notamment le placement des applets (qui partait souvent en c... cacahouète avec GNOME 2).

Bon un autre problème, même avec le mode de fallback (gnome-panel au lieu de gnome-shell), c'est qu'il manque énormément d'options de configuration. gnome-tweak-tool règle partiellement ce problème, mais ça devrait aller mieux avec GNOME 3.2.

Et j'oublie aussi le passage à GTK+ 3 où les marges internes des widgets sont devenues trop grandes.

Donc pour moi ça ne sert pas à grand chose de forker GNOME 2. Mais c'est clair que le mode fallback ne devrait pas avoir de régressions.

¹ J'avais lu que les développeurs de GNOME comptent encore maintenir gnome-panel pendant encore quelques temps, mais pas indéfiniment.

Oui si je n'avais pas trouvé l'astuce, j'aurais sans doute demandé de changer l'adresse e-mail de l'ancien compte.

Pour empêcher certaines personnes de se réinscrire, une autre solution est d'avoir une liste noire. Et de corriger la petite faille qui consiste à rajouter « +qqch » avant le @.

Ce que j'aurais bien aimé, c'est qu'en fermant mon ancien compte, l'adresse e-mail utilisée soit de nouveau disponible. Ce qui est plus logique je trouve, puisqu'un compte fermé ne sait pas être réouvert.

Pour ma part, ce que je voulais c'était un changement de pseudo, mais ça pourrait arriver à d'autres personnes se disant un jour « je ne reviendrai plus jamais ici », mais que quelques années plus tard ils reviennent quand même, et en essayant de se réinscrire, ils doivent utiliser une autre adresse e-mail.

Pour le petit hack, en toute logique ça ne devrait pas être permis.

En Belgique on parle plutôt de guindaille.

Dans l'entretien avec Éric Dumazet :

[...] De manière générale, est‐ce que tu regardes les systèmes BSD pour les comparer avec Linux ?
[...] je ne regarde pas le code de FreeBSD : je préfère que les développements Linux soient « self contained », pour éviter des contaminations pouvant poser problème de droits d’auteur.

Je trouve ça dommage, pcq la pile réseau des systèmes BSD est réputée meilleure et plus performante (malheureusement je n'ai pas de lien, et peut-être que maintenant ce n'est plus le cas).

De plus, à moins que ça soit couvert par des brevets (ce qui m'étonnerait), s'inspirer d'un code sous licence BSD ne doit surement pas poser de problèmes de droits d'auteur.

Bon en fait le jeu de mot est contradictoire avec la phrase, donc on peut préciser : pour Red-Hat, par exemple.

Dû au contrat avec Microsoft, je dirais plutôt que « Satan l'habite ».

Oui la plupart des gens confondent. Sur wikipédia on peut lire :

C'est donc une « coupure de l'esprit », pas au sens d'une « double personnalité », comme il est parfois entendu, mais au sens d'une perte de contact avec la réalité

RMS non plus n'a pas de téléphone portable. Pour lui, c'est le rêve de Staline, c'est-à-dire contrôler (encore plus) le peuple.

Il y a eu une présentation aux RMLL cette année sur Kivy.

Et il faut dire que c'est assez impressionnant !

Ici ce qui sortira (enfin, on l'espère), c'est Debian GNU/Hurd, pas Hurd lui-même. Ce n'est pas pcq une distrib intègre un logiciel en version alpha que ce logiciel devient miraculeusement stable.

Bon je suis sûr que les devs Debian feront tout leur possible pour stabiliser un maximum Hurd, mais ça ne veut pas dire que le projet Hurd compte sortir une version 1.0.

Pour moi, l'intérêt est plutôt d'avoir une installation plus facile et plus officielle du Hurd, d'en faire un petit coup de pub, et donc espérer avoir plus de contributeurs.

43 / 250 * 100 % = 17,2 % de confs en anglais, c'est bien ce que je disais.

Mais c'est vrai que 43 confs en anglais, c'est quand même pas mal, mais on ne sera certainement pas intéressé par tout (sans compter le fait que certaines sont en parallèles).

Oui, je ne dis pas le contraire. Les intervenants peuvent venir des quatre coins du monde, ce qui fait qu'il y a quand même quelques confs en anglais, mais des visiteurs ça m'étonnerait qu'il y en ai aussi des quatre coins de monde.

Je ne connais pas exactement le pourcentage des confs qui sont en français, mais je ne pense pas me tromper en disant que c'est plus de 75%. Ça ne doit certainement pas donner envie à un allemand, un espagnol ou à un anglais de venir comme simple visiteur. Et encore moins à un américain.

Tiens c'est marrant quand on passe RMLL en anglais (LSM) on évite justement le mot mondial…