Ce qui me gène profondément dans ton journal, c'est cette notion de "propre". D'une part, c'est un adjectif qui sous-entend que l'opposé serait "sale", ce qui pour quelque chose de virtuel est impossible. D'autre part, c'est un mot qui n'a aucune définition pour du code.
Je suppose que tu veux dire propre = respectant un certain nombre de principes de qualités. Mais tu ne cites pas les principes, on est donc largement dans du subjectif.
Passons un peu dans de l'objectif. Déjà, utilisons des mots sans connotation péjorative, c'est toujours désagréable pour un auteur de voir son travail insulté, d'autant plus quand c'est pas argumentée.
Quelles sont les attributs d'un code logiciel ? Ce qui me vient pour mon code et celui de mon équipe :
1) Lisible: c'est un peu abstrait, mais ça découle des principes suivants:
* règle de nommage cohérent dans toute la base de code
* le nom des fonctions dit ce qu'elles font
* le nom des arguments disent à quoi ils font référence
* des fonctions qui manipulent des arguments de même type utilisent le même nom
* les fonctions/méthodes sont relativement courtes
2) Documenté
* les arguments des fonctions sont expliqués
* les exceptions qui peuvent être générées dans les cas courant sont expliquées
* les valeur de retour standard et exceptionnelles sont expliquées
* le top, c'est quand il y a un exemple
* le tout en étant raisonnable, 10 lignes de doc pour une fonction de 1 ligne, c'est débile.
3) Maintenable
* ça découle des principes sus-cités en partie
* une chose ne doit être faite qu'une seule fois à un seul endroit pour des modifications faciles de comportement
* des abstractions sont construites au bons endroits pour des services rendus (mais cette partie-là est subjective et pas facile à expliquer)
* code livré avec des tests unitaires
4) Testable: on entre dans la zone du code de très bonne qualité
* jeu complet de test unitaire sur tout le code
* jeu complet de tests fonctionnels sur tout le produit
* les tests sont exécutables avec un seul exécutable bien nommé
* les tests ont eux-mêmes les attributs du code de qualité
Je n'ai pas mis que le code devait respecter les canons de la conception objet, car réellement, je ne pense pas du tout que ce soit indispensable. J'aime bien le style fonctionnel qui justement est à l'opposé de l'OOP académique. Et beaucoup de constructions OOP académiques se remplacent en une ligne de Python tellement ce langage est flexible [1].
Je vais plutôt au niveau de mon équipe insister sur le concept de "Loose coupling", couplage léger entre les composants, permettant de faire facilement évoluer un composant indépendamment des autres. Si l'objet répond à cette problématique, très bien. Si le fonctionnel répond mieux, je prend aussi. Si un mixte des deux fonctionne, je prend aussi.
Je suis très attaché aussi au KISS. Pas d'interface générique sur des trucs qui ne le méritent pas, mais par contre, j'encourage les interfaces simplifiées pour favoriser le découplage.
Pour en revenir à ton sujet, ce qui me choque, c'est qu'on a l'impression que "propre", pour toi, correspond uniquement au respect d'un canon de la Programmation Orienté Objet. J'en conclus que du code qui respecte tous les principes plus haut mais pas l'OOP serait pour toi non "propre" ?
Je t'invite réellement, d'une part à ne pas juger le code des gens avec des adjectifs péjoratifs et subjectifs.
Il m'est arrivé comme tout le monde de travailler sur du code externe et d'avoir des reproches à lui faire. Mais contrairement à toi, je vais parler de code inutilisable pour notre projet, inexploitable, difficile à comprendre, difficile à faire évoluer.
Bref, je ne porte pas de jugement de valeur sur la personne, surtout dans un forum public.
Note [1]: pire, certaines constructions académiques comme le Singleton vont à l'opposé du code de bonne qualité, car rendent les choses non-testables.
# C'est quoi propre ?
Posté par Philippe F (site web personnel) . En réponse au journal Du code propre, c'est quoi ?. Évalué à 10.
Ce qui me gène profondément dans ton journal, c'est cette notion de "propre". D'une part, c'est un adjectif qui sous-entend que l'opposé serait "sale", ce qui pour quelque chose de virtuel est impossible. D'autre part, c'est un mot qui n'a aucune définition pour du code.
Je suppose que tu veux dire propre = respectant un certain nombre de principes de qualités. Mais tu ne cites pas les principes, on est donc largement dans du subjectif.
Passons un peu dans de l'objectif. Déjà, utilisons des mots sans connotation péjorative, c'est toujours désagréable pour un auteur de voir son travail insulté, d'autant plus quand c'est pas argumentée.
Quelles sont les attributs d'un code logiciel ? Ce qui me vient pour mon code et celui de mon équipe :
1) Lisible: c'est un peu abstrait, mais ça découle des principes suivants:
* règle de nommage cohérent dans toute la base de code
* le nom des fonctions dit ce qu'elles font
* le nom des arguments disent à quoi ils font référence
* des fonctions qui manipulent des arguments de même type utilisent le même nom
* les fonctions/méthodes sont relativement courtes
2) Documenté
* les arguments des fonctions sont expliqués
* les exceptions qui peuvent être générées dans les cas courant sont expliquées
* les valeur de retour standard et exceptionnelles sont expliquées
* le top, c'est quand il y a un exemple
* le tout en étant raisonnable, 10 lignes de doc pour une fonction de 1 ligne, c'est débile.
3) Maintenable
* ça découle des principes sus-cités en partie
* une chose ne doit être faite qu'une seule fois à un seul endroit pour des modifications faciles de comportement
* des abstractions sont construites au bons endroits pour des services rendus (mais cette partie-là est subjective et pas facile à expliquer)
* code livré avec des tests unitaires
4) Testable: on entre dans la zone du code de très bonne qualité
* jeu complet de test unitaire sur tout le code
* jeu complet de tests fonctionnels sur tout le produit
* les tests sont exécutables avec un seul exécutable bien nommé
* les tests ont eux-mêmes les attributs du code de qualité
Je n'ai pas mis que le code devait respecter les canons de la conception objet, car réellement, je ne pense pas du tout que ce soit indispensable. J'aime bien le style fonctionnel qui justement est à l'opposé de l'OOP académique. Et beaucoup de constructions OOP académiques se remplacent en une ligne de Python tellement ce langage est flexible [1].
Je vais plutôt au niveau de mon équipe insister sur le concept de "Loose coupling", couplage léger entre les composants, permettant de faire facilement évoluer un composant indépendamment des autres. Si l'objet répond à cette problématique, très bien. Si le fonctionnel répond mieux, je prend aussi. Si un mixte des deux fonctionne, je prend aussi.
Je suis très attaché aussi au KISS. Pas d'interface générique sur des trucs qui ne le méritent pas, mais par contre, j'encourage les interfaces simplifiées pour favoriser le découplage.
Pour en revenir à ton sujet, ce qui me choque, c'est qu'on a l'impression que "propre", pour toi, correspond uniquement au respect d'un canon de la Programmation Orienté Objet. J'en conclus que du code qui respecte tous les principes plus haut mais pas l'OOP serait pour toi non "propre" ?
Je t'invite réellement, d'une part à ne pas juger le code des gens avec des adjectifs péjoratifs et subjectifs.
Il m'est arrivé comme tout le monde de travailler sur du code externe et d'avoir des reproches à lui faire. Mais contrairement à toi, je vais parler de code inutilisable pour notre projet, inexploitable, difficile à comprendre, difficile à faire évoluer.
Bref, je ne porte pas de jugement de valeur sur la personne, surtout dans un forum public.
Note [1]: pire, certaines constructions académiques comme le Singleton vont à l'opposé du code de bonne qualité, car rendent les choses non-testables.