Je ne sais pas dans quelle mesure ça reflète un aspect de ma personnalité, mais je me rend compte que je suis particulièrement strict au niveau de la présentation. Même quand j'écris du code rapidement, c'est à dire pas très proprement, chaque bloc sémantique est séparé du reste par exactement une ligne vide, le jeton d'ouverture du bloc ("{") est à la fin de la ligne qui l'ouvre, sauf lorsqu'il s'agit d'une fonction, auquel cas il est sur une ligne tout seul. La déclaration des variables à lieu au début du bloc dans lequel elles sont utilisées, etc.
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 Yusei (Mastodon) . En réponse à la dépêche Critères de personnalité d'un code. É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.