/* Topic des codeurs [6] */

grim7reaper · Le 22/10/2011, à 19:43

@helly : ta vieille adresse hotmail est toujours active.
Je viens de recevoir un spam de sa part

The Uploader · Le 23/10/2011, à 08:05

grim7reaper a écrit :

C’est que du code…
Jpense pas que remplacer :
int main(void)
{
    std::vector< boost::shared_ptr<Attaquant> > liste_attaquants;

    Attaquant* a = new AttaquantA;
    liste_attaquants.push_back(a);
…
par
int main(void)
{
    std::vector< boost::shared_ptr<Attaquant> > attackers_list;

    Attacker* a = new AttackerA;
    attackers_list.push_back(a);
…
demande un gros effort. OK, les commentaires c’est plus chiant à faire en anglais, mais le code ça va.
Sinon tu codes ton TD en Baguette on Snails

[HS]le fu- : cette année jme retrouve officieusement avec une LV4, ça commence à faire beaucoup ^^'[/HS]

<trolldi>
[prof d'Agile/TDD] De toute façon un commentaire pour expliquer le code ça veut dire que le code n'est pas lisible, est trop compliqué et pas maintenable dans le temps : pas assez d'abstraction, par exemple Et il arrive un moment où on a la flemme de mettre à jour les commentaires... [/prof d'Agile/TDD]

Perso je suis assez d'accord au regard de mon expérience perso. Par contre, je crois si je suis en train de lire du code C archi compliqué (genre celui du x264), y'aura pas assez d'abstraction pour me sauver, les commentaires et/ou une autre forme de doc' (commits) seront indispensable pour comprendre, ne serait-ce qu'un peu. ^^'

</trolldi>

Dernière modification par The Uploader (Le 23/10/2011, à 08:07)

grim7reaper · Le 23/10/2011, à 09:39

The Uploader a écrit :

[prof d'Agile/TDD] De toute façon un commentaire pour expliquer le code ça veut dire que le code n'est pas lisible, est trop compliqué et pas maintenable dans le temps

Et la marmotte…
C’est beau les grandes tirades théoriques, j’en verserai presque une petite larme tellement c‘est touchant de naïveté.

À ce compte‑là, on va dire que les tests ça ne sert à rien : ça veut dire que le code est mal écrit, est trop compliqué et manque de souplesse (bah oui, faut écrire des tests pour vérifier qu’on casse rien donc c’est la faute du code)

C’est facile de toujours rejeter la faute sur le code (surtout quand c’est pas le sien ) : je comprends pas, bah ça vient pas de moi c’est la faute du mec qui sait pas coder (des fois c’est vrai, des fois non).
Généralement, c’est surtout que le gus code différemment de nous (point de vue visuel d’une part, mais parfois aussi niveau raisonnement) et comme comprendre demande un effort (ouh, c’est fatigant ça !) bah on va dire que le code est mal écrit (ou pas assez abstrait, ou trop compliqué, ou…) hein ! C’est plus simple !

Je connais pas ton prof, mais sur ce coup il dit de la merde.
Trop de commentaire c’est mal, des commentaires dans la fonction elle-même ça reste rare (généralement en en-tête ça suffit). Mais pas de commentaire du tout, faut vraiment jamais avoir mis le nez dans du « vrai » code qui ne t’appartient pas pour prôner de telles énormités.

Et puis t’es en retard : trolldi c’était hier !

Dernière modification par grim7reaper (Le 23/10/2011, à 09:42)

helly · Le 23/10/2011, à 10:06

+4 à grim .

grim7reaper · Le 23/10/2011, à 10:08

@helly : t’as vu mon HdP ?
C’est inadmettable

helly · Le 23/10/2011, à 11:01

Ha ?
Ma sœur aussi Oo
Pourtant non, je me suis bien désinscrit cette adresse mail n’existe plus !
Peut être justement pour ça que les spams l’ont reccupérée…
Sinon, je savais même pas que tu avais eu mon adresse hotmail oo !

grim7reaper · Le 23/10/2011, à 11:03

helly a écrit :

Sinon, je savais même pas que tu avais eu mon adresse hotmail oo !

Bah si
Je t’avais même sur Jabber (et je t’avais aidé à configurer vsftpd d’ailleurs, c’était fin janvier 2010 il me semble).

Dernière modification par grim7reaper (Le 23/10/2011, à 11:05)

Pylades · Le 23/10/2011, à 11:12

ArkSeth, c’est normal que blacklist ne soit plus pris en compte dans ~/.config/touhy/deskman/devices.list ?

tshirtman · Le 23/10/2011, à 11:18

Pas besoin d'avoir une adresse mail, ni meme qu'elle existe, pour écrire un mail depuis cette adresse, hein. S'ils savent que cette adresse existe ou a existé, ça leur suffit pour penser que les spams passeront mieux s'ils viennent de cette adresse.

helly · Le 23/10/2011, à 11:34

grim7reaper a écrit :

helly a écrit :
Sinon, je savais même pas que tu avais eu mon adresse hotmail oo !
Bah si
Je t’avais même sur Jabber (et je t’avais aidé à configurer vsftpd d’ailleurs, c’était fin janvier 2010 il me semble).

Et la partie de wesnoth que j’ai allègrement foirée \o/ !

Bon, rien à voir, quelques questions pour mon TD.

D’abord les traits, voir si j’ai bien compris : est ce que m’en servir pour savoir la taille d’une unité c’est bien un bon usage des traits ?
Exemple

template <class C>
struct the_size
{
    static const unsigned int value = 0;
};

template <>
struct the_size <UniteA>
{
    static const unsigned int value = 1;
};

template <>
struct the_size <UniteB>
{
    static const unsigned int value = 2;
};

Que j’applique :

…
std::cout << "la taille d’une unité A est de "<< the_size<UniteA>::value<<'\n';

Ce qui me permet de connaître la taille sans avoir à créer un objet de la classe.
C’est bien à ça que ça sert ou je me trompe ?

Autre chose, je me souviens que pour un constructeur (ou autre), on dit que c’est mieux de faire

Classe(int x, int y):abs(x),ord(y)

Plutôt que

Classe(int x, int y)
{abs = x; ord = y;}

*
Mais avec mes neurones en bouillie, je me souviens plus pourquoi c’est mieux !
On peut me re-éclairer svp ?

grim7reaper · Le 23/10/2011, à 12:01

helly a écrit :

grim7reaper a écrit :
helly a écrit :
Sinon, je savais même pas que tu avais eu mon adresse hotmail oo !
Bah si
Je t’avais même sur Jabber (et je t’avais aidé à configurer vsftpd d’ailleurs, c’était fin janvier 2010 il me semble).
Et la partie de wesnoth que j’ai allègrement foirée \o/ !

Ha oui, aussi

helly a écrit :

D’abord les traits
[…]

D’un point de vue syntaxique c’est correct.
Après, point de vue sémantique, pourquoi ne pas utiliser un membre statique constant ? Ça reviendrai au même, mais en moins compliqué je pense.
Jpense que sortir une classe de trait pour ça c’est un peu overkill (bon après je manque encore un peu d’expérience sur les traits et leurs usages, mais c’est l’impression que ça me donne).

helly a écrit :

Autre chose, je me souviens que pour un constructeur (ou autre), on dit que c’est mieux de faire
Classe(int x, int y):abs(x),ord(y)
Plutôt que
Classe(int x, int y)
{abs = x; ord = y;}
*
Mais avec mes neurones en bouillie, je me souviens plus pourquoi c’est mieux !
On peut me re-éclairer svp ?

FAQ

Pylades · Le 23/10/2011, à 12:51

Y a-t-il un moyen simple de parser du XML en Python ? Un genre de truc un peu comme BeautifulSoup, mais qui permettrait en plus de valider le document si on fournit un DTD et d’écrire un fichier XML.

grim7reaper · Le 23/10/2011, à 12:56

Peut-être lxml.
Elle fait au moins la validation (donc forcément le parsing), pour l’écriture je ne sais (pour l’existence d’une version Python 3, idem je ne sais pas).

Apparemment, libxml2 fait aussi de la validation.

Dernière modification par grim7reaper (Le 23/10/2011, à 12:58)

The Uploader · Le 23/10/2011, à 13:18

t'as pwned mon trolldi.

C'est clair que les commentaires ne sont pas inutiles et sauvent toujours. Perso je crois que le mec il fait trop de Java. Java s'pour les gosses, le C façon x264 sans commentaire t'es foutu.

Sauf quand y'en a à chaque ligne (j'ai fait ça une fois). C'est de la merde à mettre à jour ensuite, et ça nique la lisibilité.

Elzen · Le 23/10/2011, à 13:54

Πυλάδης a écrit :

ArkSeth, c’est normal que blacklist ne soit plus pris en compte dans ~/.config/touhy/deskman/devices.list ?

Ouaip, c'est que t'as mal lu le commentaire sur le changement de config :

moi-même, sur mon site, a écrit :

Pour découper ce fichier : tout ce qui concerne les positions des icônes sur le bureau est à transférer dans deskman/devices.list. En gros, il ne doit contenir que des sections dont le nom représente un chemin d'accès (/dev/XXX ou /mnt/YYY), et qui ne contiennent que les entrée xpos et ypos. Le fichier system/devices.list contient tout le reste de ce qui concerne les points de montage. Enfin, system/vfs.list contient ce qui concerne les supports virtuels (images disques ou infos de périphs réseaux).

Le blacklistage se fait au niveau du moteur, donc dans ~/.config/touhy/system/devices.list

(Ceci dit, j'pourrais éventuellement rajouter une blacklist spécifiqueaux icônes du bureau, pour que le périph soit toujours listé ailleurs, mais juste pas affiché sur le bureau… j'n'avais pas fait parce que j'considérais qu'au pire, tu pouvais juste foutre des coordonnées négatives à l'icône pour pas la voir, mais c'est vrai que ce serait plus propre comme ça. Pour les fichiers, aussi. J'essayerai de penser à rajouter ça pour la prochaine release.)

Rolinh · Le 23/10/2011, à 14:09

Il faut savoir où est le juste milieu. Du bon code, ça doit pouvoir se lire comme un livre (ou presque). Si tu as besoin de trop commenter, c'est que ton code est pourri. En revanche, il peut arriver que certaines parties du code soient un peu plus difficile à appréhender et qu'elles nécessitent un commentaire. Par exemple, dans LinCopier, on fait un mappage en mémoire des fichiers de moins de 8Mb: c'est typiquement le truc qui nécessite d'être commenté afin d'expliquer pourquoi on fait cela.
Normalement, je commente mes fonctions en expliquant brièvement quel sont leur rôle et, le cas échéant, quel sont leur retour.

The Uploader · Le 23/10/2011, à 14:11

Exactement ce que je pense et fait. Je crois que le prof est trop extrêmiste.

Dernière modification par The Uploader (Le 23/10/2011, à 14:35)

tshirtman · Le 23/10/2011, à 14:18

oui, les commentaires ne doivent pas dire ce que fait le code (sauf optimisation rendant illisible, qui sont un cas extrème), mais pourquoi, il le fait.

grim7reaper · Le 23/10/2011, à 14:27

Yep, on en revient à ce que je disais :

/me a écrit :

Trop de commentaire c’est mal, des commentaires dans la fonction elle-même ça reste rare (généralement en en-tête ça suffit). Mais pas de commentaire du tout, faut vraiment jamais avoir mis le nez dans du « vrai » code qui ne t’appartient pas pour prôner de telles énormités.

Trop c’est trop (typiquement le ligne à ligne, sauf en assembleur bien sûr), dans la fonction c’est pour des cas précis (l’exemple de Rolinh en est un, les optimisations de brutes faites dans les codecs en sont d’autres) sinon mettre en en-tête de la fonction une description générale des E/S et du principe de la fonction suffit (si le code est bien fait).

tshirtman · Le 23/10/2011, à 14:28

c'est sans doute la faute à python, mais dans les en tetes, je considère ça comme de la doc, pas comme des commentaire .

grim7reaper · Le 23/10/2011, à 14:33

tshirtman a écrit :

c'est sans doute la faute à python

C’est aussi en Emacs Lisp, et je crois que ce dernier est plus vieux que Python

tshirtman a écrit :

mais dans les en tetes, je considère ça comme de la doc, pas comme des commentaire .

Bah je ne vois pas le souci : c’est de la doc’. D’ailleurs mes commentaires d’en-tête finissent généralement par devenir des commentaires Doxygen.
Les commentaires c’est bien une forme, primitive certes, de documentation.

The Uploader · Le 23/10/2011, à 14:36

tshirtman a écrit :

c'est sans doute la faute à python, mais dans les en tetes, je considère ça comme de la doc, pas comme des commentaire .

c'est aussi le cas en Ruby.

d'ailleurs un équivalent à doctest serait rubydoctest.

Elzen · Le 23/10/2011, à 14:36

En ce qui me concerne, je mets un commentaire par fonction pour expliquer à quoi elle sert et éventuellement quels sont les paramètres attendus (ça dépend si c'est une fonction complètement interne ou pas, dans le second cas, j'en mets pour que la personne qui va s'en resservir puisse savoir rapidement ce qu'il faut ; dans le premier, je n'en mets que si je considère que le rôle de chaque param n'est pas évident en lisant le code). Ça, c'est le minimum.

Pour le code lui-même, je groupe les différentes lignes en fonction de ce sur quoi elles portent, et je mets un commentaire global, un peu comme un titre sur un paragraphe. Gerne ça :

import gtk

# Création de la fenêtre.
win = gtk.Window()
win.set_title("Ma fenêtre")
win.set_icon(my_icon)

# Réglage du comportement.
win.set_keep_above(True)
win.set_decorated(False)
win.stick()

# Affichage.
win.show_all()
gtk.main()

À peu de choses près.

Et puis bien sûr, quand le code ne me semble pas évident à lire, j'mets des commentaires plus précis pour dire ce que ça fait exactement. Si j'suis d'humeur bavarde, je mets aussi des commentaires pour expliciter les tests et les boucles. Si j'suis d'humeur pas bavarde du tout, je n'mets quasiment rien, voire rien du tout (mais j'essaye d'éviter, quand même).

Dernière modification par ArkSeth (Le 23/10/2011, à 14:37)

HP · Le 23/10/2011, à 14:47

Allez, un peu de rails, et comme j'ouvre tous mes fichiers depuis le terminal avec open (script perso utilisent du pygtk), et bien mes documents récents en gardent une trace :

Je pense refaire mon blog en rails… parce que bon, PHP c'est pas ce qu'il y a de mieux… et j'ai besoin de quelque chose de fiable sur l'UTF-8 ; donc, bon, on va pas attendre PHP 6 .

Rolinh · Le 23/10/2011, à 15:03

@ArkSeth: j'espère que, si tu commentes en français, tu évites au moins les accents (pas comme dans ton exemple donc..).

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#976 Le 22/10/2011, à 19:43

Re : /* Topic des codeurs [6] */

#977 Le 23/10/2011, à 08:05

Re : /* Topic des codeurs [6] */

#978 Le 23/10/2011, à 09:39

Re : /* Topic des codeurs [6] */

#979 Le 23/10/2011, à 10:06

Re : /* Topic des codeurs [6] */

#980 Le 23/10/2011, à 10:08

Re : /* Topic des codeurs [6] */

#981 Le 23/10/2011, à 11:01

Re : /* Topic des codeurs [6] */

#982 Le 23/10/2011, à 11:03

Re : /* Topic des codeurs [6] */

#983 Le 23/10/2011, à 11:12

Re : /* Topic des codeurs [6] */

#984 Le 23/10/2011, à 11:18

Re : /* Topic des codeurs [6] */

#985 Le 23/10/2011, à 11:34

Re : /* Topic des codeurs [6] */

#986 Le 23/10/2011, à 12:01

Re : /* Topic des codeurs [6] */

#987 Le 23/10/2011, à 12:51

Re : /* Topic des codeurs [6] */

#988 Le 23/10/2011, à 12:56

Re : /* Topic des codeurs [6] */

#989 Le 23/10/2011, à 13:18

Re : /* Topic des codeurs [6] */

#990 Le 23/10/2011, à 13:54

Re : /* Topic des codeurs [6] */

#991 Le 23/10/2011, à 14:09

Re : /* Topic des codeurs [6] */

#992 Le 23/10/2011, à 14:11

Re : /* Topic des codeurs [6] */

#993 Le 23/10/2011, à 14:18

Re : /* Topic des codeurs [6] */

#994 Le 23/10/2011, à 14:27

Re : /* Topic des codeurs [6] */

#995 Le 23/10/2011, à 14:28

Re : /* Topic des codeurs [6] */

#996 Le 23/10/2011, à 14:33

Re : /* Topic des codeurs [6] */

#997 Le 23/10/2011, à 14:36

Re : /* Topic des codeurs [6] */

#998 Le 23/10/2011, à 14:36

Re : /* Topic des codeurs [6] */

#999 Le 23/10/2011, à 14:47

Re : /* Topic des codeurs [6] */

#1000 Le 23/10/2011, à 15:03

Re : /* Topic des codeurs [6] */

Pied de page des forums