Pouvez vous me donnez des idées d'éléments d'un code source qui, selon vous, reflètent la personnalité de son auteur?
Tous les exemples sont les bienvenus, surtout les plus personnels et les plus "tordus" ;)
Aller plus loin
- Code as a form of expression (1 clic)
- Is computer programming art? (1 clic)
# 2 idées
Posté par Baptiste SIMON (site web personnel) . Évalué à 10.
o L'indentation est la preuve même d'ordre que quelqu'un met dans ses idées
o Les commentaires sont aussi une manière d'identifier la clareté, la logique, l'expression de son "moi profond" (LOL).
... :c)
BeTa
[^] # Re: 2 idées
Posté par Cédric Foll . Évalué à 10.
Pauvres programmeurs Pythons ...
On pourrait citer:
-Le choix du nom des variables, des fonctions.
-Le style de programmation (Objets, procédurale, ...) avec la coérence (un gros "main" ou pleins de petites fonctions, des objets bien propre ou un gros objet qui fait tou).
Les algos utilisés (itératifs, impératifs, ...).
Le choix du langage (Perl-> poète, Python -> psychorigide, lisp -> pervers, Ruby -> malin , ...). Non c n'est pas un troll ;-)
[^] # Re: 2 idées
Posté par Baptiste SIMON (site web personnel) . Évalué à 8.
L'indentation est la preuve même d'ordre que quelqu'un met dans ses idées
Pauvres programmeurs Pythons ...
Pauvre de moi ;c)
Quand je l'ai écrit, j'ai failli le mettre... mais bon, j'ai pensé que la majorité des langages n'ayant pas une syntaxe liée à l'indentation, ça pouvait passer à l'ombre... mais les lecteurs de DLFP sont exigeants ;c) c nickel... bien corrigé [+]
[^] # Re: 2 idées
Posté par Nÿco (site web personnel) . Évalué à 3.
diff, CVS/Subversion, générateurs de squelettes/code, warnings à la compile, automake et consorts, etc...
Sinon, il y a aussi le choix tels que les langages, les librairies, l'internationnalisation, l'extensibilité, etc...
[^] # Re: 2 idées
Posté par Fulgrim . Évalué à 7.
[^] # Re: 2 idées
Posté par LupusMic (site web personnel, Mastodon) . Évalué à 5.
C'est vrai que le cobol ou le fortran ne peuvent que donner une indication sur l'âge du développeur :D
[^] # Re: 2 idées
Posté par Blue_Bear . Évalué à 1.
mais malgré tout j'en reste adepte.
[^] # Re: 2 idées
Posté par fabien . Évalué à 10.
A mon avis le fait de ne pas indenter *peux* aussi refleter la precipitation/l'abondance d'idée/le desire de les coder vite (pendant qu'on les a en tete)
perso, il m'arrive de n'indenter qu'apres.. même defois que quelques temps apres...
oui, je sais c'est mâl (tm) "bêêê.."
j'irai jusqu'a dire que le mec qui va mettre une tartine de commentaire pour une fonction/methode interne tout simple de 3 lignes dont le nom lui même dit tout ce qu'il y a a dire (genre : "RAZListeUtlisateursUI")
Et bien il m'arrive de penser qu'ils sont un peu coincés (voir con-con).
je que j'aprecie le plus, c'est pour les petits projets (ou il n'y a qu'un dev) les commentaires du style "Qui: tartanpion"
Bon là je vais me faire descendre par tous les theoriciens du beau code.
a peine hors sujet, j'aime bien cette url :
http://mindprod.com/unmain.html(...) (how to write unmaintainable code) . bien sur que des exemple à ne pas suivre....
[^] # Re: 2 idées
Posté par Fabimaru (site web personnel) . Évalué à 2.
Mais bon, les editeurs de texte sont la pour ca. Avec Emacs: ctrl-x h, esc, ctrl-\ et voila un buffer tout indente !
[^] # Re: 2 idées
Posté par okhin . Évalué à 1.
[^] # Re: 2 idées
Posté par nooky59 . Évalué à 6.
function toto {
code;
}
et
function toto
{
code;
}
Personnelement je préfère la 2ème forme, et je me sens complêtement paumé avec la 1ère vu mon habitude.
Et encore, si je reprends d'anciens codes que j'ai fait, j'indenté comme ceci :
function toto
{
titi
}
Quand je me suis aperçu que les outils de reformatage de code ne connaissaient pas cette syntaxe (ni même dans les tutoriaux, bouquins), j'ai donc adopté celle mentionnée ci-dessus, et maintenant je trouve l'ancienne que j'utilisais imbuvable pour se repérer ;o)
Je trouve que c'est un bon exemple de personnalité.
Idem pour les commentaires ou ceux qui ne commentent pas, et ceux qui vont compacter le maximum de code sur une ligne pour faire une obfurcation naturelle du code ;o)
[^] # Re: 2 idées
Posté par fabien . Évalué à 3.
j'ai jamais compris pourquoi il est tres commun de mettre l'accolade tout de suite apres la fonction :
foobar (prout) {
.. code
}
moi j'aime bien mettre en regards les deux accolades.
tien et aussi,
question : suis-je considéré comme un peingre si j'indente avec un ou deux espaces au lieu du tab ? :)
[^] # Re: 2 idées
Posté par zimmermann jérémie (site web personnel) . Évalué à 4.
if (chose) {
..muche
}else {
..keutru
}
là, par rapport à un code qui ferait:
if (chose)
{
..muche
}
else
{
..keutru
}
le if et le else sont visuellement beaucoup plus distincts... lorsqu'il y en a 3 ou 4 les uns en dessous des autres, celà peut faire la différence...
mais bon je pense qu'il y a une grande part d'appréciation personnelle... comme dans le fait d'utiliser des stylos à encore noire ou à encore bleue, ou du papier petit carreau ou gros carreau pour écrire un texte... (écrire?? c'est quoi déjà?! ;))
[^] # Re: 2 idées
Posté par Amaury Bouchard (site web personnel) . Évalué à -1.
Les blocs de code sont bien visibles.
Si par contre tu indentes avec 3 ou 4 espaces, tu risques de ne rien voir avec l'écriture ci-dessus. Il vaut alors mieux faire :
A noter que la première écriture est plutôt utilisée avec des langages comme le Perl, le Java, le JavaScript, le C++ (enfin, d'après ce que j'ai vu) et le noyau Linux.
La deuxième se rapproche de la norme d'écriture GNU, il me semble.
[^] # Re: 2 idées
Posté par Nÿco (site web personnel) . Évalué à -2.
*** Pourquoi toi, tu codes :
foobar (prout) {
.. code
}
*** Et pourquoi toi, tu codes :
foobar (prout)
{
.. code
}
[^] # Re: 2 idées
Posté par nooky59 . Évalué à -1.
Pour ta questio, bah tu fais 2 fois plus d'effort et tu es moins productif, 2 appuies sur une touche au lieu d'un ;o)
Moi perso, je change la taille de la tabulation à 4, 2 çà a un peu le goût de trop peu, et plus sur des imbrications complexes çà s'étend trop en largeur.
[^] # Re: 2 idées
Posté par fabien . Évalué à 1.
pour les espaces a la place du tab, c'est pas en terme d'effort (encore qu'un espace fait uen seulle touche aussi) mais c'est en terme de rendu. je trouve la tabulation trop grande.
et ton astuce de reduction de la taille du tab, ok mais c'est alors dependant de l'editeur...
[^] # Re: 2 idées
Posté par Sebastien (site web personnel) . Évalué à 4.
> Moi perso, je change la taille de la tabulation à 4, 2 çà a un peu le goût de trop
> peu, et plus sur des imbrications complexes çà s'étend trop en largeur.
<intaigriste>MÉCRÉANT!!!</intaigriste>
Une tabulation DOIT être représentée par 8 caractères. Toujours. On ne change pas la représentation du caractère tabulation. Si on veut une indentation moindre, on utilise des espaces pour cet effet (et on utilise aussi un vrai éditeur qui rends ce changement transparent).
Ne pas confondre le caractère de tabulation et la touche "tab" servant à indenter du code. Ce n'est pas pareil.
seb.
[^] # Re: 2 idées
Posté par fbilhaut . Évalué à 7.
"A huit caractères la tabulation tu régleras."
Justement, "tab" est représenté par *un seul* caractère qui veut dire "j'indente ici". L'intérêt est que chacun est libre de l'interpréter comme il veut (i.e. lui donner la largeur qu'il veut). C'est un peu comme un tag en HTML : il sert à marquer un paragraphe, mais ne dit pas comment il doit être affiché (retrait ou non, espace avec le § précédent, etc). En gros, une tabulation est plutôt porteuse de sens que de forme.
L'intérêt est évident : chacun idente son code en *visualisant* les tabs comme il le souhaite, et les autres peuvent le relire avec la visualisation qui leur convient.
Si seulement tout le monde pouvait comprendre ça et éviter de configurer son éditeur pour transformer les tabs en espaces (donc de longueur fixe), ça aiderait bcp la relecture du code (surtout maintenant qu'on doit souvent "lire" du xml).
[^] # Re: 2 idées
Posté par Wawet76 . Évalué à 5.
Donc des gens normaux qui vont regarder ton code vont se retrouver devant un truc illisible (ligne trop longue), à moins de changer _leurs_ préférences pour lire _ton_ code.
Et si tu changes la taille par défaut de la tabulation, tu vas avoir un truc illisible si tu regardes du code indenté avec un mélange de tabulation et d'espaces (ce qui est le cas avec les conventions du projet GNU et celles de Sun pour le Java)
Donc oui, "A huit caractères la tabulation tu régleras" est quasi-religieux en ce qui me concerne.
Au boulot je code surtout en Java et je me force à respecter à la lettre les conventions définies par Sun pour l'indentation et le nomage (1ere lettre en minuscule pour les méthodes, en capitale pour les classes, etc...)
Pourquoi ?
- Comme quasiment tout le monde à l'intelligence de faire pareil c'est plus facile de relire le code des autres.
- La convention d'indentation de Sun (espace d'indentation de 4 caractères, une tabulation peut remplacer 8 caractères) est ce que fait Emacs par défaut :)
[^] # Re: 2 idées
Posté par Gruik Man . Évalué à 9.
De l'indentation à 8 caractères:
« Tabs are 8 characters, and thus indentations are also 8 characters. There are heretic movements that try to make indentations 4 (or even 2!) characters deep, and that is akin to trying to define the value of PI to be 3. Rationale: The whole idea behind indentation is to clearly define where a block of control starts and ends. Especially when you've been looking at your screen for 20 straight hours, you'll find it a lot easier to see how the indentation works if you have large indentations.
Now, some people will claim that having 8-character indentations makes the code move too far to the right, and makes it hard to read on a 80-character terminal screen. The answer to that is that if you need more than 3 levels of indentation, you're screwed anyway, and should fix your program. In short, 8-char indents make things easier to read, and have the added benefit of warning you when you're nesting your functions too deep. Heed that warning.»
Des conventions du projet GNU:
« Please at least consider the points made here. First off, I'd suggest printing out a copy of the GNU coding standards, and NOT read it. Burn them, it's a great symbolic gesture. »
[^] # Re: 2 idées
Posté par Wawet76 . Évalué à 8.
Corps d'une classe puis corps d'une méthode dans cette classe, ça prends déjà 2 levels d'indentation.
Il reste 1 level "autorisé" pour le code lui même ?
Pour peu que j'utilise un bloc try/catch je n'ai plus le droit d'utiliser la moindre boucle ou le moindre branchement ?
Dur dur.
Je trouve Linus très bon quand il code, mais quand il cause il débite autant de conneries à la minute que les gens qu'il critique.
[^] # Re: 2 idées
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
"La première sécurité est la liberté"
[^] # Re: 2 idées
Posté par Gruik Man . Évalué à 1.
Mais bon, tout de même, que ce dernier a l'élégance d'être parfaitement lisible en 80 colonnes. Et ça, c'est bien(tm)
[^] # Re: 2 idées
Posté par fabien . Évalué à 3.
Si je prend le probleme a l'envers, on juge la qualité du code au fait qu'il fasse plus ou moins que 3 niveaux ? et ce en dehors de tout autre postula ? sans tenir compte même du sujet traité ? ni du language ?...
c'est un peu rapide je trouve.
[^] # Re: 2 idées
Posté par Sebastien (site web personnel) . Évalué à 2.
> Si je prend le probleme a l'envers, on juge la qualité du code au fait qu'il fasse
> plus ou moins que 3 niveaux ? et ce en dehors de tout autre postula ? sans
> tenir compte même du sujet traité ? ni du language ?
Il n'est pas question de parler de qualité en tant que tel, mais bien de prendre en compte une caractéristique importante liée au code: ça doit être édité par des être humains. Et dans ce cadre, il faut prendre en compte les limitations de l'esprit de l'homme: par exemple les niveaux d'imbrications des structures de contrôle[1] ou le nombre de variables gérées au même instant[2] ou la longueur d'un bloc défini.
De nombreuses normes de codage suivent de tels principes: typiquement une fonction ne devrait pas faire plus d'un écran "normal" de longueur (avec une exception pour l'utilisation de structures type switch), ne pas inclure plus de 3-4 niveau d'imbrication dans les structures de contrôle, limiter la portée des variables, etc...
seb.
[1] Au passage, ne pas confondre structures de contrôle et définition.
[2] Il me semble que la limite était estimée à 7 variables simultanées.
[^] # Re: 2 idées
Posté par Sebastien (site web personnel) . Évalué à 4.
> Ah ? Et c'est écrit dans le ciel qu'une tab doit faire 8 "caractères" ?
Non, c'est écrit dans la définition des terminaux. Parfois on n'est pas amené à lire du code qu'avec son éditeur favori et parfois on va se contenter de less/more/cat... Et ces outils ci afficheront toujours le caractère de tabulation comme étant de 8 blancs.
seb.
[^] #
Posté par Guillaume Laurent (site web personnel) . Évalué à 1.
[^] # Re: Critères de personnalité d'un code
Posté par fasthm . Évalué à 2.
La gent féminine, pas la "gente", pas de "e" ! La gent féminine ! Et ça se prononce comme "gens". Pas "jante".
[^] # Re: 2 idées
Posté par rgill . Évalué à 1.
vous ne pourriez pas laisser encore plus de lignes blanches entre les lignes de code, c'est pas très clair :))
l'upload CVS doit être ignoble avec de tels sources :)
[^] # Re: 2 idées
Posté par Wawet76 . Évalué à 1.
Hints : Il faudrait remplacer les retour chariots des posts par des "br" seuls plutot que par des "br + retour chariot"
[^] # Re: 2 idées
Posté par kb . Évalué à 3.
Petite précision : linuxfr.org ne tourne plus sous dacode mais templeet je crois.
[^] # Re: 2 idées
Posté par rgill . Évalué à 1.
d'ailleurs merci aux auteurs de linuxfr pour ce changement, DLFP devenait imbuvable sous daCode (lenteur).
Longue vie à templeet ! (heu ... zauriez pas songé à spip - il gère entièrement la mise en forme avec quelques raccourcis typographiques, et il est sympa ?)
http://www.spip.org(...)
[^] # Re: 2 idées
Posté par Christophe Lucas (site web personnel) . Évalué à 1.
En revanche, à moins de faire des algorythmes très complexes, sinon avoir plus de trois imbrications, alors c'est qu'il y a un problème.
Mais pour plus d'informations: linux/Documentation/CodingStyle.
Ce n'est pas une bible absolue, mais cela peut servir et explique certaine de ces règles.
--
clucas ; http://titux.tuxfamily.org(...)
[^] # Re: 2 idées
Posté par Matthieu Moy (site web personnel) . Évalué à 2.
Euh, y'a encore des gens qui indentent leur code à la main ??
Ou alors, tu voulais dire :
... si je configure mon éditeur pour indenter avec un ou deux espaces ...
[^] # Re: 2 idées
Posté par nooky59 . Évalué à 2.
Même parfois comme çà c'est dur donc il y'a bien les éditeurs qui l'indiquent mais généralement çà ne marche pas très bien dès lors que la portée dépasse la taille de l'écran.
Sinon un bon coup de molette sans bouger le curseur permet de retrouver la portée.
Dans ce même soucis de clarté, je fais toujours un
plutôt qu'un if(cond) instruction;
[^] # Re: 2 idées
Posté par Matthieu Moy (site web personnel) . Évalué à 1.
< troll >
Même vi le fait, c'est dire !
< /troll >
[^] # Re: 2 idées
Posté par nooky59 . Évalué à 1.
Et malheureusement, sur la version Windows de XEmacs, c'est le même délire. Après sous Linux je ne sais pas si çà se comporte mieux.
[^] # Re: 2 idées
Posté par gc (site web personnel) . Évalué à 1.
Waouhh..
Sinon pour info sous Emacs il y a les sexp, indispensable. http://www.gnu.org/manual/emacs/html_node/emacs_282.html(...)
Perso je les utilise avec :
(define-key global-map [(meta left)] 'backward-sexp)
(define-key global-map [(meta right)] 'forward-sexp)
[^] # Re: 2 idées
Posté par Vivi (site web personnel) . Évalué à 1.
[^] # Re: 2 idées
Posté par ukemi . Évalué à 2.
function foo
{
code;
}
est plus pratique pour le brace matching
en effet, avec un éditeur qui permet de jumper jusqu' à la prochaine accolade, si on veut éditer par exemple le nom de la fonction et qu' on utilise la forme avec l' accolade sur la meme ligne, on doit retourner au début de la ligne et c' est reulou
(j' ai été clair ? :/)
[^] # Re: 2 idées
Posté par LupusMic (site web personnel, Mastodon) . Évalué à 0.
[^] # Re: 2 idées
Posté par ukemi . Évalué à 1.
function foo {
code;
}
et que tu arrives sur le premier {, tu dois te taper le retour au début de foo
avec un nom de 3char c' est pas hyper grave mais quand tu as des nom de fonctions plus long, ça peut devenir pénible
mais en fait, ça se voit mieux pour les blocs de structure, genre quand tu veux modifier la condition d' un if (et là on peut arraiver a de grosses et longues conditions a coup de && et || ;)
[^] # Re: 2 idées
Posté par LupusMic (site web personnel, Mastodon) . Évalué à 2.
^W
Selon son éditeur fétiche :D
[^] # Re: 2 idées
Posté par Jean-Marc Leroy . Évalué à 2.
Remonter d'une ligne par rapport à l'accolade : touche flèche-haut
Retourner au début de la ligne : touche Home
Je ne vois pas où est le problème...
Perso je code en tab3 (sauf le html et les langages à balises en général) et j'ai souvent changé de type d'indentation. Dernièrement, je m'en suis tenu à l'indentation par défaut de Eclipse (seul la tabulation a été mise à 3) à savoir :
function nomfonction(plok) {foo();
if(gloups) {
waza();
} else {
squ33k();
}
}
Chacun sa manière de coder, maintenant c'est clair que dans des projets collaboratifs, c'est plus difficile d'imposer aux autres ta manière de coder :D
[^] # Re: 2 idées
Posté par grafit . Évalué à 3.
un ligne de plus ?
en particulier lors de nombreux if/then/else imbriqué, si tu as un petit écran, ben il te faut 2 pages pour voir ton algo en entier...
[^] # Re: 2 idées
Posté par Cyril . Évalué à 3.
alors moi, dans un esprit de portabilité, je fais des espaces (en plus 2 espace c'est sufisant et ça permet de faire du code qui prend pas trop de colonnes quand y'a plusieurs bloques inbriquées
[^] # Re: 2 idées
Posté par okhin . Évalué à 1.
[^] # Re: 2 idées
Posté par jigso . Évalué à 6.
void f ()
{
...
}
Et en Perl :
sub f () {
...
}
Et les deux me vont très bien. C'est grâve docteur ?
Plus sèrieusement ces choix d'indentation m'on été plus ou moins imposés par mon éditeur favori. Comme quoi il peut-être assez délicat de ce baser sur le type d'indentation pour déterminer la personnalité de celui qui code.
Maintenant je pense qu'effectivement l'abscence d'indentation peut être révélateur - et encore, cela peut simplement vouloir dire que la personne n'a pas utilisé un outil très adapté, la plupart des éditeurs s'occupant de faire une indentation automatique.
[^] # Re: 2 idées
Posté par nooky59 . Évalué à 2.
Je ne me laisserai certainement pas imposer l'indentation avec l'accolade en haut d'un éditeur. Soit çà se paramètre, soit je change d'éditeur. SI çà c'est pas de la personnalité et du trait de caractère !!! ;o)
[^] # Re: 2 idées
Posté par jigso . Évalué à 4.
[^] # Re: 2 idées
Posté par nooky59 . Évalué à 1.
Sérieusement, tu as peut être plus de faculté à t'adapter rapidement. Moi quand j'ai mes petites habitudes productives, je n'aime pas qu'on me les bouleversent. Et c'est là où je suis bien content d'avoir le brace matching quand je reprend le projet d'un autre.
[^] # Mes états d'ames...
Posté par jigso . Évalué à 1.
Merci du compliment.
J'aime bien les horoscopes, sondages, test de personnalités qui disent que du bien de moi... ;-)
[^] # Re: 2 idées
Posté par Vincent Zeus . Évalué à 2.
function toto
{
titi
}
Otez de ma vue cette horreur que je ne saurai voir...
[^] # Re: 2 idées
Posté par morge . Évalué à 1.
code;
}
The original notation from Kerningham
[^] # Re: 2 idées
Posté par Yusei (Mastodon) . Évalué à 1.
[^] # Re: 2 idées
Posté par PegaseYa . Évalué à 5.
donc, y'a plus vraiment moyen de trouver de la poésie là dedans...
Sinon,
Y'a un bel outil qui permet de reformater grandement le code:
http://www.gnu.org/software/indent/indent.html(...)
[^] # Re: 2 idées
Posté par tgl . Évalué à 2.
... (and (blabla truc muche) (or (bidule chose fmuh) (sbrong glop (gluglu (plopplop 1) (coincoin 2) (panpan 3))) ...Le problème, c'est que c'est faisable que dans des éditeurs vraiment prévu pour ça, ou alors à la main avec plein d'espaces (pas question de tabs de longueurs fixe ici, on perdrait les colonnes vu que la largeur de l'indentation dépend de la ligne au dessus). On pourrait, pour utiliser une indentation plus systématique à la C, passer partout à la ligne, mais c'est vite vraiment trop long, et moins lisible... Alors du coup, soit l'éditeur doit tout sauver avec des espaces (c'est généralement le cas), soit il doit sauver sans indentation mais en sachant qu'il y a, quand il ouvre un fichier, un décalage au début de chaque ligne qui est à déterminer par rapport à celles du dessus. Là mon vim, il gère pas ça...[^] # Re: 2 idées
Posté par Matthieu Moy (site web personnel) . Évalué à 2.
[^] # Re: 2 idées
Posté par tgl . Évalué à 1.
[^] # Re: 2 idées
Posté par rgill . Évalué à 3.
# Re: Critères de personnalité d'un code
Posté par Pooly (site web personnel) . Évalué à 10.
* les commentaires
* l'indentation (mais ca dejà été proposé)
les commentaires marrants dans le code (cf les jokes du kernel linux :)
de toute façon, dans un projet, il y a toujours des lignes directrices pour la présentation et la manière de coder : choix du nom des varialbes, indentations, etc... voir à ce propos les coding-style du kernel linux :)
[^] # Re: Critères de personnalité d'un code
Posté par zimmermann jérémie (site web personnel) . Évalué à 4.
mais le côté strictement syntaxique, même si il est le plus flagrant à première vue, n'est à mon avis que la partie émergée de l'iceberg!
quid des structures de données, des structures algorithmiques, de la façon dont les erreurs sont traitées, de la façon de communiquer avec l'utilisateur, avec d'autres programmes, etc... ?
ce sont autant de critères à mon avis qui sont tout autant susceptibles d'être personnels à chacun, bien que répondant à des critères fonctionnels, tout comme la syntaxe...
qu'en pensez-vous?
[^] # Re: Critères de personnalité d'un code
Posté par Fulgrim . Évalué à 7.
J'en ai déduit qu'il était sadique, parce que c'est inhumain des programmmes avec des noms de fonctions de ce genre. (je vous parle pas des noms de variables, jamais plus d'une lettre...).
[^] # Re: Critères de personnalité d'un code
Posté par Jean-Marc Leroy . Évalué à 3.
Pourtant je ne voyais pas où était le mal (surtout après avoir vu comment on codait de l'assembleur... des instructions qui tiennent en moyenne en trois caractères....)
# Re: Critères de personnalité d'un code
Posté par Fabien Penso (site web personnel, Mastodon) . Évalué à 10.
En effet pour ma part lorsque je code quelque chose, je m'arrange pour que ce soit aussi beau que possible. Beaucoup de développeurs font en sorte que les lecteurs éventuels de leur source aient, à sa lecture, un sentiment de beauté; qu'ils se disent que le code est vraiment bien tourné, qu'il fait en 10 lignes ce que d'autres font en 100. Que l'idée est géniale, etc.
En bref, c'est un peu comme de l'architecture, lorsque l'on découvre un batiment qui a un intérêt particulier (les matériaux utilisés pour sa création, sa forme, etc), ou bien d'autres arts.
[^] # Re: Critères de personnalité d'un code
Posté par zimmermann jérémie (site web personnel) . Évalué à 7.
le problème est que ce qui paraît évident pour qui a le nez dedans l'est nettement moins pour ceux qui n'imaginent même pas à quoi peut ressembler un code-source!
saurais tu décrire les critères qui te font apprécier la beauté d'un code? la question est d'autant plus difficile et biaisée que l'appréciation du "beau" est du domaine de l'affectif, et non de la technique, ou de quelques règles pré-établies... je pense toutefois que les critères syntaxiques, abondamment évoqués, prennent une part mineure, ou en tout cas superficielle, dans cette appréciation.
ce sont ces éléments qui seront susceptibles de m'aider: qu'est-ce qui rend un code "beau", et par-là même, te fait entrevoir un peu de la personnalité de son auteur, ou de l'état d'esprit dans lequel il était lorsqu'il l'a codé?
j'aimerais beaucoup arriver à faire percevoir cette beauté par des juristes, des économistes... bref des non-geeks :)
merci de votre aide à tous!!
[^] # Re: Critères de personnalité d'un code
Posté par ukemi . Évalué à -1.
[^] # Re: Critères de personnalité d'un code
Posté par tekool . Évalué à 1.
Pour moi, ce qui est beau dans un logiciel, c'est :
- ce qu'il fait
- comment il le fait
- comment il est fait
Résumer ça au code est trop limité même si je pense personnellement que le code, en tant qu'activité, est parfois très proche de la démarche artistique.
[^] # Re: Critères de personnalité d'un code
Posté par LupusMic (site web personnel, Mastodon) . Évalué à 5.
L'art est l'expression de sentiments profonds, qu'on désiré exprimer, sous une forme quelconque. Et réduire ce quelconque à la beauté, c'est réduire d'autant la palette des émotions expressibles dans l'art.
Je ne suis pas un bon programmeur, mais je fais un code agréable à lire. Cependant, puis-je me considérer tel un artiste de l'informatique ? Aucunement, je suis un technicien, un artisant tout au moins, mais non un artiste. Mais là, c'est un problème de définition : beaucoup affirment que tous les écrivains, tous les peintres, tous les chanteur (!) sont des artistes .... mais suffit-il d'être capable de s'exprimer pour être un créateur.
Si oui, alors Bill Gates est le plus grand artiste de l'informatique !
[^] # Re: Critères de personnalité d'un code
Posté par Fulgrim . Évalué à 2.
D'ailleurs j'ai plus souvent entendu parler d'élégance dans les deux cas.
[^] # Re: Critères de personnalité d'un code
Posté par TSelek . Évalué à 6.
Un beau code est un code qui exprime une certaine pureté par rapport au cahier des charges. Si il n'existe pas de spécifications alors on est en plein amateurisme. Autrement dit un code parfait est un code qui ne représente pas le style de son auteur mais au contraire ce quoi vers de bons developeurs devraient converger. par exemple cai chez les éditeurs proprios qui ont des règles de conding fortes qu'on trouvera le plus d'Easter Egg. Ca déplace la problématique vers la rédaction des spécifications. Or si on se place au niveau méthodologique on constate que les spécifications doivent impérativement être cohérentes et completes, ce qui limite là encore le degré de liberté des rédacteurs, sans parler des templates ou des évaluations. De plus l'évolution est au formalisme, même si on a encore du mal à travailler sur des modèles formels d'une façon économiquement rentable. On se déplace alors sur un autre terrain, celui de la meta-modélisation. Par exemple tout ce qui a été fait sur UML et les outils XML, les travaux du w3c ou du groupe Apache qui sont AMHA des vrais oeuvres d'art dans le sens où elles portent le niveau de reflexion au summum de ce qu'on peut faire aujoud'hui hors cadre académique, et leurs principes sont indépendant du Java souvent utilisé. La réflexion la plus productive ne se fait plus au niveau du code mais bien en amont, et plus ça sera fait en amont plus ça sera productif. Autant dire que des outils comme VisualBasic sont des faux gains de productivité.
L'avantage du LL, cai que le developeur est libre et à partir de là peut s'exprimer comme il l'entend, pourvu qu'il s'éclate. C'est une question de plaisir, d'auto-satisfaction, d'appartenance et de reconnaissance. Et pour certains une question morale et éthique. Après on tombe en plein subjectivisme.
On parlait des CC à propos de RedHat, ben sans un minimum de rigueur méthodologique chez les devs, ben ça passera pas.
[^] # Re: Critères de personnalité d'un code
Posté par matiasf . Évalué à 6.
Beau? C'est pas mon soucis. Mon soucis numéro 1 est la lisibilité, la clarté, la simplicité (sans être simpliste !).
La "beauté" d'un fichier source peut-être trompeuse. Un source peut-être beau car bien commenté, avec de solides conventions, etc... bien que la conception soit naze. Lorsque l'on fait un programme, il y a l'expression de besoin du client, et les choix techniques, de conceptes utilisés pour répondre à ce besoin. Pour moi un bon code permet de rapidement comprendre la solution, les conceptes retenuent pour répondre au besoin. En C, les fichiers .h et la séparation claire des outils/conceptes utilisés est primordiale. Les fichiers .h et la définition des structures de données en disent beaucoup plus sur l'"élégance" d'un programme que les fichiers .c, l'indentation, etc...
[^] # Re: Critères de personnalité d'un code
Posté par cauchemar . Évalué à 9.
[^] # Re: Critères de personnalité d'un code
Posté par Lafrite . Évalué à 4.
[^] # Re: Critères de personnalité d'un code
Posté par cauchemar . Évalué à 6.
[^] # Re: Critères de personnalité d'un code
Posté par Tony Flow . Évalué à 1.
Après réflexion, voici les 3 notions qui me font apprécier un code source :
clarté : indentation, nommage des variables & des fonctions, commentaires (point trop n'en faut)
élégance : choix judicieux des structures de données et des enchainements (procédures, boucles, conditions...)
allié avec une apparente simplicité dûe à quelques subtilités techniques (d'où économie de code)
efficacité : bien sur à ne pas oublier ! pleinement fonctionel (satisfaction par rapport au besoin) avec la sensation
d'avoir pensé à tout et de ne laisser aucun bug possible (la magie du rêve ;)
Comme il a été dit dans un autre comentaire, je vois plus le programmeur comme un artisan plutot qu'un artiste (soyons raisonnables) :
du travail bien fait, réalisé avec amour par ces ptites mimines (donc non bill n'est pas un artiste, juste un industriel...).
L'éventuel coté artiste dépendrait de tout le concept entourant le programme, notamment ce qu'il fait au final, pourquoi et comment...
Au niveau de l'appréciation du code, on peut noter cependant un point commun avec l'art : il faut être un connaisseur pour pouvoir
l'apprecier pleinement, à moins de rester béat devant qqchose qui nous dépasse :)
[^] # Re: Critères de personnalité d'un code
Posté par Tony Flow . Évalué à 1.
Donc un code particulièrement réussi peut être admiré et salué au même titre qu'une très belle pièce d'un maitre artisan. Et de plus il est tout à fait imaginable (je crois d'ailleurs que cela a déjà été fait) d'avoir une démarche artistique dans la réalisation d'un code, celui-ci n'étant plus là comme outils ou solution technique, mais comme un concept porteur d'un message quelconque.
# Perl et TIMTOWDI
Posté par Arachne . Évalué à 8.
Ne serait-ce que pour afficher le contenu d'un fichier, on dénombre 7 manières différentes, plus ou moins longues, plus ou moins lisibles, et plus au moins efficaces. Sur un programme de grande taille, ces différences d'implémentation vont se multiplier, et, même avec un maximum de rigueur, la personnalité du programmeur se retrouvera nécessairement dans le code.
Je retrouve dans la programmation, en Perl comme dans d'autres langages, une liberté d'action et un potentiel créateur qui me fait nécessairement penser à l'art. J'en suis même venu à voir le code comme un forme d'art, avec tout ce que ça implique au niveau de la propriété intellectuelle. C'est peut être aussi pour ça que je suis plus musicien qu'artiste. ;)
[^] # Re: Perl et TIMTOWDI
Posté par zimmermann jérémie (site web personnel) . Évalué à 2.
mais ce "feeling" assez intuitif pour qui a déjà ouvert plusieurs bouts de code source côte à côté l'est nettement moins pour qui n'a entendu parler du source que comme un objet théorique, vaguement traîté par le droit, et dont les "industriels" tirent des revenus conséquents...
il est assez facile, donc, pour qui réfléchit à la question de la necessité ou non de faire breveter ce genre d'objets mystiques de passer outre l'aspect artistique pour n'envisager que le côté strictement fonctionnel de la chose!
d'où mon besoin de lister les éléments permettant d'apprécier le côté artistique, expressif, (affectif?) du code, sans pour autant avoir un background d'informaticien...
j'aimerais prouver ça par A+B :)
[^] # Re: Perl et TIMTOWDI
Posté par Baptiste SIMON (site web personnel) . Évalué à 5.
Ca reflete trop la personnalité du programmeur et du coup, c'est susceptible de faire perdre de vue l'objectif final de tout code (selon ma vision) : la réutilisabilité et la portabilité inter-développeurs.
Bref, pour avoir eu besoin, professionellement parlant, de reprendre de "gros" projets en perl, je trouve qu'on pousse l'idée de code-art un peu trop loin. Ca devient trop vite imbitable, voire détestable (j'en suis arrivé là).
Je pense qu'on touche ici à une limite du code-art.
[^] # Re: Perl et TIMTOWDI
Posté par Arachne . Évalué à 1.
Par contre on peut aussi coder du Perl avec rigueur dans un soucis d'optimisation et de réutilisabilité. Je ne pense pas que mon code perl "sérieux" soit difficilé à reprendre.
[^] # Re: Perl et TIMTOWDI
Posté par Christophe BAEGERT . Évalué à 3.
J'ai déjà du reprendre de gros projets en Perl, et en fait, souvent au début on ne comprend rien, quel que soit son niveau, puisque chacun à sa façon de coder.
En fait avant de pouvoir comprendre le source, il faut comprendre la personnalité du codeur, ses manies. Une fois que tu as compris ça, le reste coule ... de source !
[^] # Re: Perl et TIMTOWDI
Posté par Toufou (site web personnel) . Évalué à 1.
[^] # maintenir
Posté par nobotag . Évalué à 3.
Je dirais que le code c'est plus personnel qu'artistique.
A noter que quand on reprend du code , il est rare que ce qu'on remarque , ne soit pas un défaut.
A noter que parfois le défaut est dans celui qui le regarde ;)
La logique industrielle veut quand mème qu'on "partage", donc qu'on indifférencie, normalise plutot que s'approprier
ce qui s'oppose à la personnalisation technique inhèrente à l'activité de l'artiste. mais qu'est-ce qu'un artiste.
L'art c'est le résultat. le logiciel est-il un résultat artistique
le code n'est pas visible, l'art s'adresse à un spectateur, quand mème...
En fait on retrouve dans l'informatique les mèmes clivages que dans le cinema : programmes d'auteurs / logiciels commerciaux.
# Re: Critères de personnalité d'un code
Posté par Benoît Sibaud (site web personnel) . Évalué à 10.
Concernant le code, à peu près tous les éléments peuvent être des indices, la partie difficile étant l'interprétation :
- choix de dépendances
- choix des licences des dépendances
- fichier CR, LF, CR/LF
- nom du fichier : main.cpp ou InternetLurkerTool.c
- extension : par exemple en C++, .h .H .hpp .hxx .C .cpp .cxx ...
- indentation (dont le tout sur une ligne ou pas)
- espaces ou tabulations
- aération du texte
- style de codage : que du while() pas de for() ou l'inverse, ++i ou i++, utilisation de const/unsigned/long/short en C/C++, effort pour la portabilité, #include <iostream.h> ou , (int)toto ou static_cast(toto), etc
- présence de commentaires, surabondance ou pas, pertinents ou pas, détaillés ou pas
- choix de noms de variables/classes/fonctions
- respect de convention de nommage/indentation/etc dans tout le code
- présence de l'en-tête juridique/copyright/licence
- tout le projet dans un même répertoire ou arborescence
etc
[^] # Re: Critères de personnalité d'un code
Posté par Gaétan RYCKEBOER . Évalué à 3.
Un écrivain est un artiste. On ressent, en lisant son oeuvre, une émotion. On imagine. On peut lire son oeuvre à plusieurs niveaux. Même plus. L'écrivain a voulu faire passer une émotion (rejet, beauté...), mais il a surtout accompli une oeuvre réfléchie. Il a ses raisons qui font de son oeuvre une oeuvre artistique. Ben est un artiste. Pourtant, ce n'est pas tant la beauté de son oeuvre qui fait de lui un artiste - une signature en bas à gauche d'un mur d'immeuble n'est pas belle en soi - mais sa démarche.
Maintenant, prenons une lettre de candidature à un poste quelconque. Au travers de l'écrit, on ressentira une personalité, on pourra ressentir une certaine émotion. Mais la démarche qui a conduit l'auteur d'une lettre de motivation n'a rien à voir avec une démarche artistique.
L'art n'a pas besoin de la beauté pour existé, et la beauté n'est pas l'art. Emotion n'est pas art. L'art n'a pas besoin d'être utile pour exister, c'est à ça qu'on le reconnaît.
Pour ces raisons, un code, utile, inutile, n'est pas une oeuvre d'art. A moins d'avoir une démarche artistique derrière. Non pas "faire le plus beau code", ou "le code en le moins de lignes", ça c'est une prouesse technique. 'est beau, on peut en avoir la larme à l'oeil, un programme en C palindrome qui compile sans warning et sert à quelque chose, c'est émouvant. De là à dire que c'est de l'art... non ! Et pourtant, c'est bien ce qui pourrait s'en _rapprocher_ le plus.
Le pinguoin postcript fabriqué à partir du code du kernel linux, ça c'est de l'art. Le code en lui même, non. Du code peut petre beau. Ou moins beau. Au dela, c'est beaucoup s'engager (bien que je le redise, du code peut être une oeuvre d'art... s'il est la résultatnte d'une démarche artistique,s'il a une raison que la raison ignore...).
# Re: Critères de personnalité d'un code
Posté par Nÿco (site web personnel) . Évalué à 3.
Sinon :
http://qslinux.org/docs/cross/coding-stds/standards_toc.html(...)
http://www.linuxjournal.com/article.php?sid=5780(...)
# Re: Critères de personnalité d'un code
Posté par Harry Cover . Évalué à 9.
Dire que "coder" c'est "s'exprimer" est donner une vision idéologiquement orientée d'un travail d'ingénierie pure, ça n'est basé sur absolument rien d'objectif (si ce n'est une vision un peu naive de la vie), donc je ne pense sincèrement pas que tu pourras trouver le moindre argument allant dans ce sens. Mais bon courage quand même.
[^] # Re: Critères de personnalité d'un code
Posté par zimmermann jérémie (site web personnel) . Évalué à 4.
que fais-tu du démomaking? de la Perl Poetry? de l'Obfuscated C Contest? j'en oublie très certainement, mais ce sont-là des formes de programmation qui n'ont rien à voir avec l'ingéniérie, car, que je sâche elles ne construisent rien à proprement parler!
le but est juste d'être joli, ou incompréhensible, ou les deux... le but même du programme est de provoquer des émotions, des sentiments, et non-pas de faire tenir des cailloux les uns sur les autres, ou de tendre un pont entre les 2 rives d'un fleuve...
le problème c'est qu'entre un code qui serait de l'art, "parce qu'il suffit de le dire" et un code qui serait un bête moyen fonctionnel d'arriver à un but, le législateur peut faire basculer le statut de nos outils du tout au tout!!
les conséquences de l'acceptation par tout le monde du code comme un "bête" moyen d'ingéniérie le rangerait au rang de produit matériel, comme des sacs de vis, de boulons, ou des gros tas de parpaings...
je suis d'accord qu'il suffit d'apprécier quelque chose comme de l'art pour considérer que c'en est..
j'aimerais prouver qu'il est facile, sinon nécessaire, de le faire pour le code informatique, afin de préserver la créativité de ceux qui le conçoivent et l'utilisent comme tel, et de ne pas favoriser les interêts commerciaux qui souhaiteraient le voir "marchandisé" comme tout le reste...
[^] # Re: Critères de personnalité d'un code
Posté par reno . Évalué à 4.
Moi quand je codes, je cherches:
1) a ce que ca marche d'abord et avant tout, ce qui n'a rien d'artistique, ni est une forme d'expression (enfin si mais une expression a destination de l'ordinateur).
2) a ce que ce soit lisible, maintenable.
La on peut considerer que c'est une forme d'expression, car c'est une expression soit vers moi-meme dans le future, soit vers les autres.
Mais bon, c'est a peu pres la meme forme d'expression que d'ecrire sans fautes d'orthographe ou de grammaire..
Une bonne analogie est la construction de maison, c'est une forme d'expression|d'art ou pas?
Si tu fais une maison originale, peut-etre mais si tu construis des HLM, bof!
Si tu reorganise du code pour qu'il soit plus lisible et maintenable, ce sont les criteres fonctionnels qui comptent..
[^] # Re: Critères de personnalité d'un code
Posté par Toufou (site web personnel) . Évalué à 0.
L'analogie avec l'architecture me semble vraiment pertinente : c'est un art fonctionnel, pas uniquement pour le loisir comme la peinture, la musique ou ce genre de choses. Dans la grande majorité des cas, on code pour répondre à un besoin (tout comme on construit des batiments pour qu'on puisse les utiliser après), mais on peut en plus y prendre plaisir et essayer d'y mettre un peu de 'poésie', ce n'est pas incompatible. D'ailleurs c'est la difficulté du truc : faire beau et fonctionnel, pas juste l'un ou l'autre.
On considère l'architecture comme un des 7 Arts, alors pourquoi pas le code ?
[^] # Re: Critères de personnalité d'un code
Posté par Obsidian . Évalué à 1.
Oui. D'une manière générale il s'agit d'une oeuvre intellectuelle à la base. La réalisation sur mesure d'un pont, d'un passage à niveau, ou autres réalisations du même type dans le domaine des travaux publics est appelée "Ouvrage d'art".
Maintenant, sans aller jusque là, la rédaction d'un programme s'apparente à la rédaction d'un article de journal où à un autre essai littéraire. Il a des codes à respecter, des règles d'usage, une certaine liberté de mouvement, et tu retrouves le style du programmeur en ses sources. Il m'est même arrivé de désassembler le contenu binaire de ROMs d'un vieux 8 bits, et d'y retrouver selon les routines explorées, deux approches complètement différentes du même problème.
[^] # Re: Critères de personnalité d'un code
Posté par Frédéric Lopez . Évalué à 2.
Tout à fait d'accord.
> que fais-tu du démomaking?
En général, le code des démos n'a aucun intérêt sauf d'un point de vue technique, le but est d'obtenir le maximum de performance quel qu'en soit le prix, pas d'écrire du joli code. Ni du code qui suscite des émotions en le lisant d'ailleurs (ou de frayeur peut-être :). Et puis souvent c'est écrit en assembleur (enfin, ça l'était à une époque) et c'est donc beaucoup plus proche de la machine que de l'humain.
> de la Perl Poetry? de l'Obfuscated C Contest? j'en oublie très
> certainement, mais ce sont-là des formes de programmation qui
> n'ont rien à voir avec l'ingéniérie, car, que je sâche elles ne
> construisent rien à proprement parler!
Peut-être aussi que ces codes n'ont aucun intérêt en tant que code, mais seulement en tant qu'"oeuvre". Et dans ce cas, ce n'est pas vraiment du code étant donné que ça ne sert à rien, sauf à être "beau". Je pense que ton but est plutôt d'expliquer en quoi le code "courant" est une forme d'expression, pas d'expliquer qu'il peut l'être dans certains cas très spécifiques, sinon ça ne sert pas à grand chose. Et je vois difficilement comment tu pourrais justifier ça.
> j'aimerais prouver qu'il est facile, sinon nécessaire, de le faire pour
> le code informatique, afin de préserver la créativité de ceux qui le
> conçoivent et l'utilisent comme tel, et de ne pas favoriser les interêts
> commerciaux qui souhaiteraient le voir "marchandisé" comme tout le
> reste...
Le code peut être "marchandisé" quand il fait partie d'un processus industriel, je ne vois pas le problème. Si c'est au niveau des brevets logiciels que tu t'inquiètes, je pense qu'il vaut mieux rechercher des parallèles entre langage informatique et langage mathématique. Ou entre algorithme et théorème. Il y en aura sans doute plus qu'avec le langage tout court.
[^] # Re: Critères de personnalité d'un code
Posté par Thomas MARTIN (site web personnel) . Évalué à 2.
Tu peux considérer toute production humaine comme de l'art, à partir du moment où elle exprime un sentiment de 'beauté' pour toi.
# http://www.erenkrantz.com/Words/UntitledSnapshot2.shtml
Posté par TazForEver . Évalué à 1.
# Re: Critères de personnalité d'un code
Posté par TazForEver . Évalué à 1.
[^] # Re: Critères de personnalité d'un code
Posté par animal_omega . Évalué à 6.
ce qui est loin d'etre incompatible avec la notion d'art.
# Re: Critères de personnalité d'un code
Posté par Yusei (Mastodon) . Évalué à 3.
Et par voie de conséquence, j'ai un mal fou à lire un code qui n'est pas présenté suivant des règles strictes. Par forcément mes règles à moi, il suffit que je comprenne quelles sont les règles.
Dans le même genre d'idées, les conventions de nommage sont importantes, c'est à dire quelques noms de variables "fourre-tout" (i, j, k, p, widget, object...) pour les traitements temporaires, et pour le reste des noms clairs plutôt que brefs. Pour le nommage des fonctions, préfixe permettant d'identifier dans quel fichier est la fonction (à la gtk_) si on n'est pas en orienté objet, usage cohérent des verbes/substantifs/adjectifs dans les noms...
En dehors de ces basses considérations, il y a les différentes manières d'écrire la même chose, qui dépendent aussi du langage utilisé. J'ai une préférence pour les structures courtes et claires, comme en ruby, un
File.new('toto', 'r').each { |line|
print line;
}
Plutôt qu'une écriture classique avec ouverture de fichier, boucle, fermeture de fichier. Si en pratique c'est la même chose, la version ci-dessus est plus lisible et plus jolie, selon moi (Bien sûr avec la gestion des erreurs c'est moins joli).
Même si je les utilise parfois, j'aime moins les astuces implicites de Perl, qui sont très pratiques si on les connaît, mais rendent le code illisible si on ne les connait pas, comme un while(<>) et l'utilisation de $_...
Pour conclure, je me rend compte que pour moi un bon code est tout sauf artistique, en ce qui concerne la forme, puisqu'idéalement il faut qu'un autre programmeur écrivant le même algorithme obtienne à peu près le même code. Donc pour moi, tout l'art de la programmation réside dans le choix de la méthode la plus élégante (ou la plus optimale, ou...) pour résoudre un problème, mais pas sur la manière de coder cette méthode.
[^] # Re: Critères de personnalité d'un code
Posté par TSelek . Évalué à 2.
Pour moi, ici l'art est d'arriver à quelque chose qui soit le moins contestable possible, le plus lisible et surtout le plus "droit" par rapports aux objectifs. Ruby et les concepts associés, c'est "programmation agile", de la prog Kung Fu comme dans Shaolin Soccer :) Simple, rapide, lisible, redoutablement efficace.
[^] # Re: Critères de personnalité d'un code
Posté par N/A . Évalué à 1.
C'est dommage, ruby c'est sympa effectivement.
Pour en revenir aux styles de programattion, moi j'hésite pas à mettre des blagues ou d'autres trucs à la con dans les commentaires :-)
Au moins, ça me fait rire quand je relis mon code :)
# Et l'inspiration
Posté par Christophe BAEGERT . Évalué à 3.
Personnellement, si je ne sens pas l'inspiration, je ne fais rien. Même s'il faut attendre 3 jours ou 2 semaines pour que l'inspiration arrive, je trainerai sur internet plutôt que de coder.
Par contre quand elle arrive, là, le monde ne compte plus, je code, point. Si ca doit durer 1heure, 3 heures, 4 heures, 5 heures, peu importe, tant que l'inspiration est là je code. Et je sais que le résultat sera bien meilleur que ce que j'aurais pu faire en 2 semaines sans attendre l'inspiration !
[^] # Re: Et l'inspiration
Posté par Jérôme Nègre (site web personnel) . Évalué à 5.
Faut que tu me donnes le truc pour faire passer ça à ton chef ;o)
[^] # Re: Et l'inspiration
Posté par Christophe BAEGERT . Évalué à 1.
# Re: Critères de personnalité d'un code
Posté par prophetix . Évalué à 1.
Perso je prefere les codes clairs et direct tandis qu'il y a des paranos qui arriveront a sortir du code polymorph.
prenons un exemple simple:
newbie: cat /var/log/messages
un peu moins newbie: cat /var/log/messages |tail
encore un meu moins: tail /var/log/messages
et encore un peu moins: dmesg |tail
etc...
On peu en faire l'analogie avec un langage parlé, plus on connait de figure de style et de vocabulaire, plus on peut jouer avec les mots... Bien sûr toute ces langues ont une structure propres et il faut s'y habituer.
la personne raisonnée et ouverte au monde va sortir un code dans un langage universel (c++ <-> anglais), utilisé partout et facilement comprehensible tandis qu'une personne qui veut faire bien, le plus precis possible en detaillant le plus va utiliser l'assembleur. Une personne qui ne veut pas s'embeter a articuler, va utiliser un PHP qui vas comme l'americain lui permettre de parler un peu a sa convenance et bouffer des mots etc...
dans le code lui meme le programmeur va refleter sa personnalité, non seulement avec ses noms de variables, de fonctions, mais rien que dans la structure de ses declaration, les commentaires, la forme globale, le noms des sous fichiers, la structures des fichiers etc...
perso, j'aime bien faire un seul fichier qui gere tout, structuré, vous ne trouverez jamais une declaration de variable en plein milieu du code, definir une fonction au dessus et en dessous du main etc... tout ca pour le coté lisible et pratique de la chose. Une personne qui veut lire mon code, va le faire comme s'il lit un roman et les messages d'avertissement utilisateur ne se limite pas a un simple numero d'erreur mais a un petit clein d'oeil amical a l'utilisateur ("dis moi msieur, tu peux me mailer et me dire ce que tu as fait pour que ca fasse ca? ;)")
# Re: Critères de personnalité d'un code
Posté par Arachne . Évalué à 4.
# Re: Critères de personnalité d'un code
Posté par Samaty Tramo . Évalué à 1.
[^] # Re: Critères de personnalité d'un code
Posté par LupusMic (site web personnel, Mastodon) . Évalué à 2.
[^] # Re: Critères de personnalité d'un code
Posté par Gaétan RYCKEBOER . Évalué à 3.
# Re: Critères de personnalité d'un code
Posté par pthivent . Évalué à 4.
# Re: Critères de personnalité d'un code
Posté par j . Évalué à 2.
Il y a par exemple :
- Le type qui a passé 2 ans à faire un cahier des charges, a modélisé des machins en merise, fait des dessins dans tous les sens, et possède sur papier le détail de chaque classe et de chaque fonction à implémenter. Le premier truc concret qu'il va probablement faire est d'écrire tous les prototypes. Le remplissage avec du code viendra bien après, et la structure (théoriquement) ne changera jamais sans repasser par la case départ.
- Le type qui écrit un truc infect qui fonctionne 10 minutes après, mais avec toutes les valeurs en dur, aucune gestion d'erreur, aucune précaution liée à la sécurité, aucun effort de portabilité, etc. Ces détails seront éventuellement ajoutés bien plus tard, lorsque l'application fonctionnera.
- Le type qui va au contraire toujours prévoir tous les cas de figure possible. Par exemple pour effectuer une simple requete SQL, il va prendre soin de quoter absolument tout, y compris les nombres (on sait jamais, des fois que plus tard, on change le nombre par autre chose), il va systématiquement utiliser des transactions, réessayer plusieurs fois en cas d'erreur, ajouter un cache et des délais exponentiels pour éviter un effet zeno, considérer que n'importe quelle fonction de la libc peut etre bogguée ou ne pas fonctionner exactement comme documentée, etc. Résultat : il va falloir beaucoup plus de temps que le type précédent pour avoir un code "ou y a quelque chose à voir". Mais une fois le truc en prod, il n'aura jamais à s'excuser ("ah euh, ouais, c'est normal, c'est parce qu'il n'y avait plus de place sur le disque") .
- Le type qui suit à la ligne un modèle qu'on lui a enseigné ou qu'il a lu dans un bouquin.
- Le type qui fait un patchwork avec des bouts de code repiqués de-ci, de-là, en y ajoutant des rustines pour qu'ils cohabitent.
etc.
[^] # Re: Critères de personnalité d'un code
Posté par gnumdk (site web personnel) . Évalué à 5.
-Faire que chaque nouveau programme ne réalise qu'une seul fonction
-Utiliser au maximum les commandes et les librairies existantes plutot que de tout réécrire
-Réaliser le plus rapidement un embryon de programme correcte et le modifier graduellement jusqu'a optention du résultat souhaité
# Re: Critères de personnalité d'un code
Posté par Hodj . Évalué à 2.
alphabet : ensemble de signes.
dictionnaire : sous-ensemble fini de l'ensemble des n-uple d'éléments de l'alphabet.
grammaire: façon d'arranger les mots du dictionnaire.
On peut, à mon avis, comparer un source à un article , un roman,une lettre à la tantine ...
Deplus, quand on connait les gents qui ont code sur un projet, on arrive à savoir qui a écrit tel ou tel bout de code d'après la façon dont il a été écrit( un genre de signature du programmeur) de la même façon qu'on reconnait le style d'un auteur, d'un compositeur, d'un peintre ...
[^] # Re: Critères de personnalité d'un code
Posté par _seb_ . Évalué à 2.
# vive les gotos
Posté par barbie_g . Évalué à 0.
remarque: il pue un peu le style linuxfr pour les tags html pre...
[^] # Re: vive les gotos
Posté par j . Évalué à 8.
Il y a par exemple :
- Le gars qui ne veut pas y toucher parce qu'il a entendu dire que ce n'était "pas propre" et il n'a pas cherché plus loin. Pour sortir de deux boucles, il préfère gacher des variables et ajouter des tests.
- Le gars qui l'utilise en toute logique, quand ça convient beaucoup mieux que le reste et que ça évite des acrobaties.
- Le gars qui code (!= programme) et qui sait qu'une fois compilé, un programme est constitué à 70% de "goto" (jmp, bra, beq, jnz, jump, etc) .
- Le gars qui voit ton code source et qui se dit "pourquoi il a pas écrit "return list->item" au lieu de "goto" ?
- Le gars qui explique et démontre au précédent que le code généré par gcc est *exactement* le meme.
- Le gars qui trouve quand dans ton code source, le fait de ne pas mettre d'accollades après le "for" et le "if" rend ton code beaucoup plus difficile à suivre que le "goto" (au moins on sait où il va, alors que le reste, sans indentation, c'est loin d'etre évident) .
- Le demomaker qui abuse des possibilités étendues de "goto" dans GCC (saut vers des pointeurs, comme en assembleur) et qui trouve ca infiniment plus simple que les machins conventionnels.
- Le gars qui s'efforce d'écrire des boucles partout sans se rendre compte que ce n'est rien d'autre qu'un goto.
- Le gars qui dit que c'est impossible de maintenir du code de plus de 10 lignes avec des "goto".
- Le gars qui lui répond qu'il y a pourtant 17785 goto dans le code source de Linux 2.4.20-gentoo-r1.
- Le gars qui répond au précédent que Linux de toutes facons, ca suxx et que BSD ca roulaize.
- Un autre gars qui répond au précédent qui à répondu au précédent qu'il y en a 40044 dans OpenBSD.
- Un troisième gars qui ajoute qu'il ne faut pas confondre goto (qui peut etre extremement "propre") et setjmp/jmplong.
- etc.
[^] # Re: vive les gotos
Posté par fabien . Évalué à 2.
- Le gars qui voit ton code source et qui se dit "pourquoi il a pas écrit "return list->item" au lieu de "goto" ?
- Le gars qui explique et démontre au précédent que le code généré par gcc est *exactement* le meme.
- et le gars qui dit que finalement si ca fait pareil, pourquoi ne pas ecrire "return list->item" au lieu du "goto" (au moins on sais tout de suite ce que ca fait, pas besoin d'aller chercher en bas pour un simple retun)
[^] # Re: vive les gotos
Posté par Matthieu Moy (site web personnel) . Évalué à 1.
Je ne suis donc pas si sur que les deux codes donnent la même chose avec gcc -O3.
[^] # Re: vive les gotos
Posté par j . Évalué à 2.
Le "for" j'ai du mal à comprendre comment il fonctionne, il ne décrit pas une étape simple (il combine un assignement, un test et un saut, et introduit un bloc). J'ai du mal à voir que "list" c'est un test+un saut et à quel moment c'est réalisé. Je ne sais pas si quand "list" est null il va refaire un tour de boucle ou pas.
Pareil, sans les accollades je dois réfléchir un moment avant de comprendre si "goto found" fait partie de la boucle ou pas, idem pour le "return default_item;".
J'aurais naturellement écrit le truc comme ça :
Le résultat est identique. Mais là, je vois immédiatement ce que ça fait, comment ça va etre converti en langage machine, et comment le CPU va l'interpréter. Par contre tu vas probablement trouver ça bizarre, pas intuitif et trop long.
Comme quoi le style reflete vraiment une personnalité.
[^] # vive les for
Posté par barbie_g . Évalué à 1.
gagne!
pour etre precis les if-do-while au lieu d'un for me donne des boutons et je les trouve illisibles.
selon la facon de penser suivante:
en C, for ne sert "a rien", puisqu'on peut le remplacer par while, il donne juste une information semantique au relecteur lui evitant d'avoir a comprendre ce que peut bien etre ce if-do-if-while bizarre. donc je revendique l'usage du for, meme pour une liste chainee.
a la limite, j'aurai compris que tu fasse un while mais pas un do-while, la condition du while etant illisible car a la fois une condition et une incrementation, ce qui n'est pas le cas dans un for.
j'aurai accepte que tu ecrives:
mais a vrai dire, "for(a; b; c) d;" est strictement equivalent a "a; while(b) { d; c; }", donc je trouve plus lisible la forme avec for, parce que je comprends tout de suite que ca veut dire "pour tout element de la liste", ce qui est moins clair avec la forme while.
je pense que le "for" est plus proche de la facon dont on concoit l'algorithme avant de le coder, alors que le for explose en while (ou en do-while) sont plus proche de la facon dont le code s'execute, et donc a perdu une information utile pour la maintenance du code.
c'est un avis que je comprends qu'on ne partage pas forcement...
Comme quoi le style reflete vraiment une personnalité.
entierement d'accord avec toi.
[^] # Re: vive les for
Posté par zoltar . Évalué à 1.
[^] # Re: vive les gotos
Posté par Linux_GTI . Évalué à 6.
if (match(list->item, template_item))
return list->item;
return default_item;
Ou de façon plus lisible :
Je préfère cette dernière forme.
[^] # Re: vive les gotos
Posté par barbie_g . Évalué à 1.
et si j'ai deux boucles for imbriquees, tu m'autorise le goto?
[^] # Re: vive les gotos
Posté par Linux_GTI . Évalué à 8.
[^] # Re: vive les gotos
Posté par Matthieu Moy (site web personnel) . Évalué à 1.
Bon, ça dépends des fois ...
Nottons que dans ces cas là, les languages un minimum modernes fournissent en général un système d'étiquetage de boucle, qui permettent de dire "je veux sortir de la boucle X" plutot que de dire "Je veux aller à la ligne Y" (qui se trouve juste après la boucle X).
Le principe des exceptions permet également de gérer ça proprement, mais il faut voir si l'implémentation est efficace.
[^] # Re: vive les gotos
Posté par 123neveu . Évalué à 8.
- sortie de beaucoup de boucles imbriquées
- gestion d'erreur :
f() {
if (!doit1()) {
goto error ;
}
...
if (!doit2()) {
goto error ;
}
...
...
error:
printf("problème ...")
...
}
[^] # Re: vive les gotos
Posté par barbie_g . Évalué à 2.
(avis perso)
par contre avec le premier... je suis tellement d'accord que j'ai propose un exemple ou le goto est deja present, preventivement a l'apparition ulterieure d'une deuxieme boucle ;-)
[^] # Re: vive les gotos
Posté par 123neveu . Évalué à 8.
# Vrais programmeurs
Posté par Lawrence P. Waterhouse (site web personnel) . Évalué à 6.
Les vrais programmeurs ont horreur de la programmation structurée. La programmation structurée est pour les névrosés contrariés qui nettoient leurs bureaux, taillent leurs crayons, rangent leurs affaires et rentrent à l'heure pour manger.
http://www.leburelain.com/textes/programmeur.htm(...)
[^] # Re: Vrais programmeurs
Posté par Tutur . Évalué à 1.
Malheureusement c'est tellement vrai ce qu'il dise.
# Re: Critères de personnalité d'un code (formation et experience)
Posté par Tutur . Évalué à 1.
Ensuite viennent l'experience. Pas celle que tu as aquise en ecrivant tes programmes, mais celles que tu as aquise en relisant, reutilisant du code d'autres personnes.
Personnelement, je reprend regulierement du code fait par d'autres personnes. Je n'ai jamais remarqué que le code correspond à la personnalité de la personne, mais plutôt de ces connaissances du langage. On utilise les fonctions, procédures, algo que l'on connait. Il est vrai que chaque personnes a son propre style, ses habitudes, ses methodes, etc...
En fait, la methode de coder depend surtout de ce que va devenir le code. Comme je sais qu'on le relit deriere moi et qu'il va resservir, j'essaye de faire claire et simple.
Sinon, à force de relir du code d'autres personnes, on prend les bonnes idées. Et on laisse tomber les mauvaises. C'est en regardant les autres que l'on apprend.
A lire tout les autres commentaires, j'ai vraiment l'impression que chacun parle pour soi:
MOI je code code cela, parce que MOI je prefere que ce soit comme cela.
De plus quand on fait de la qualité, il y a souvent des régles de codages. Il m'est arrivé de verifié que du code vérifie des régles de codages (genre lignes de moins de 70 caractéres, constante en majuscules, nom de procedure comprenant un verbe, nom de la fonction indiquant ce qu'elle produit, etc...). Super chiant, mais tres formateur quand à la meilleur méthode de coder.
Par experience, voici quand même quelque truc pour rendre un programme comprehensible.
-- Des noms qui veulent dire quelques choses. C'est pas toujours le cas.
-- Avoir la même convention de styles pour tout le programme, surtout quand plusieurs personnes travaille dessus.
-- Des procedures/ fonctions de moins de 40 instructions (instructions, pas lignes). Si c'est trop gros, tu decoupes.
-- Un entête pour chaque procedure/fonction comprenant le nom de la procedure, les nom et fonction des paramétres, commentaire en 1 ou 2 lignes (d'ailleurs, s'il faut plus pour expliquer ce que fait la fonction, c'est qu'elle est trop compliqué). En plus ça permet de faire un separation entre les procedure/fonction. C'est pas beaucoup, mais ca permet de mettre les idées au point avant de coder et c'est super quand on relit du code.
-- Le moins de variables globale possibe, c'est toujours chiants de chercher quelle fonctions l'initialise, laquel la modifie, etc...
-- Lorsque tu decrit une procedure fonction, un paramétre par ligne come cela on les voit tout de suite.
ex
procedure TOTO
(
...Paramétre_1 : in T_Type_1;
...Paramétre_2 : in T_Type_2;
)
-- Enfin afin que tout le monde y trouve son compte, 1 indentation = 1 tabulation, comme cela, celui qui veut une indetation de 2, il regle tab = 2, etc...
[^] # Re: Critères de personnalité d'un code (formation et experience)
Posté par matiasf . Évalué à 4.
Bof. Si c'est une fonction fleuve sans imbrication, je vois pas pourquoi spliter la fonction. Des paramètres plus pertinants doivent être utilisés dont le nombre de variables locales utilisées, le nombre d'imbrication, la complexiter etc...
Personnellement, avoir une fonction qui est appelée uniquement une fonction n'améliore pas forcément la lecture. Je préfère une longue fonction fleuve. Si plusieurs actions sont réalisés, mettre un "gros" commentaire. Par exemple :
/*
* Stockage des informations récupérées
*/
et non
// enregistrement
# Re: Critères de personnalité d'un code
Posté par Jiba (site web personnel) . Évalué à 3.
Si tu pars du principe que tu as un code source orienté objet, tu peux voir ce programme comme une "société d'objets" qui intéragissent entre eux. Dans ce cas, la vision que tu as de la société, et ta vision de la "société idéale" influe énormément sur ton code.
Par exemple pourquoi est-ce un hasard si les langages de prog qui n'ont pas de notion de d'attributs privés (Python, Perl) sont issus du monde du logiciel libre ? Les idées libertaires des auteurs de ces langages ont sans doute déteint sur leur code.
Encore + fort : il est difficile de changer la société humaine actuelle pour en faire une "société idéale" ; c'est + facile quand il s'agit d'une "société d'objet" (univers + rigoureux). Les programmeurs idéalistes y arrivent... voilà pourquoi les logiciels libres sont de qualité supérieur aux autres ;-)
[^] # Re: Critères de personnalité d'un code
Posté par cauchemar . Évalué à 8.
Ben dans le libre on est très préoccupé par la sécurité/confidentialité. C'est contradictoire.
En tout cas, j'ai pas la même disposition d'esprit lorsque je code et lorsque j'écris une lettre ... d'amour par exemple.
[^] # Re: Critères de personnalité d'un code
Posté par XHTML/CSS inside (site web personnel) . Évalué à 3.
[^] # Re: Critères de personnalité d'un code
Posté par Matthieu Moy (site web personnel) . Évalué à 2.
J'ai pas l'URL sous la main, et je suis derrière un proxy, mais cherche dans un cours de bernard cassagne. C'est l'histoire de "(char) lie" qui parle à "(char) lotte" et c'est très fort !!
# Re: Critères de personnalité d'un code
Posté par Franck Hanot . Évalué à 1.
La façon d'écrire du code dépend :
.du sujet : on ne code pas un driver bas niveau (C, assembleur, code au kilomètre, performance, efficacité) comme un datawarehouse (algorithmique haut niveau, identification des portions de code de complexité non-linéaire, lisibilité, maintenanbilité etc..)
.de l'environnement : ce n'est pas pareil si on code pour soi ou la communauté, ou pour une entreprise
.du cursus et de l'expérience (ceux qui se forment sur le tas auront plus de mal à produire du code de haut niveau. Je sais, ça va en faire hurler certains).
Le langage utilisé découle des 3 premiers points. Selon, on le choisit ou non, on fait le bon choix de langage et/ou d'environnement de développement ou non.
Or, il y a 2 extrêmes : les langages qui laissent une grande liberté de coder et les langages stricts. Dans la communauté du libre, les premiers sont surtout utilisés car une grandé créativité la caractérise.
Bref, le sujet est énorme, ça dépend du langage, puis au sein du langage de l'état d'esprit de chacun et regard du sujet, de l'environnement et de son expérience.
Le sujet a été abordé sur ce forum par la petite lucarne du C et de l'indentation mais on pourrait parler de la complexité algorithmique, le niveau de documentation non-code, les commentaires, les critères qualité (maintenabilité, perf, lisibilité, scalabilité etc...), le système de versionning.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.