Apprendre 23 principes pour écrire du code lisible

Chers membres du club,

J'ai le plaisir de vous présenter ce guide d'Artur Smiarowski :

Apprendre 23 principes pour écrire du code lisible

Citation:

---

Lire le code d’autrui peut être déroutant. Des heures peuvent s’écouler pour résoudre des problèmes qui auraient pu être corrigés en quelques minutes.
Dans cet article, Artur Śmiarowski souhaite partager des conseils sur comment écrire un code qui sera plus facile à comprendre et à maintenir.
Cet article est long, n’hésitez pas à aller directement aux parties qui vous intéressent.

---

Bonne lecture ;)

:fleche: Retrouvez les meilleurs cours et tutoriels pour apprendre la programmation

Merci de la traduction.
Plein de "bon sens" mais ça fait du bien de lire ce style de truc :)

Merci , cela ma permis de mieux comprendre , les définitions de pointer mieux harmonisés , les printf %u et non pas %d et quelques const à mettre en place dans les appels de fonction , et j'ai mis en place ccpcheck avec geany ... logique était bonne.
sur plus 8000 lignes 2 heures pour tout remettre en place , 2h pour replonger dans la doc.

je cherchais un outil comme ça... Merci ... je vais retourner pour voir et relire vos recommandations.... ;)

par principe je durci le compilateur GCC avec des options qui empêche d'avoir des variables inutilisées, les parenthèse etc....

Je voudrais aussi dire par expérience venant du monde industriel ayant fait de la gestion d’entreprise et du system pendant plus de 40ans. et remercier l'auteur de l'article qui m'a donnée l'idée de vous écrire ce petit mot.

Je voudrais seulement signaler que pour faire du code lisible......

Prenons un exemple , la gestion de stock

c’est quelque chose de connue les grands principes sont dans les livres par exemple chez Gilbert jeunes….

Il faut commencer pas réfléchir comment articuler votre base de données, la granulé et ne pas penser à faire un record qui comprend toutes les zones pour géré votre stock

mais:
une entête qui comprendra par exemple
les zones fabrication appro-fournisseur , stock réel, stock dispos, stock encours , stock livraison , stock facturer , stock rebus , stock demande de livraison …...

des lignes article détail , qui vous permettrons d’avoir pour un même article des conditionnements différent, une liaison avec la commande de fabrication , la date de fabrication pour la traçabilité, le numéro de fabrication pour la traçabilité …..

on voit bien que ce n’est pas possible et pas bon de raisonner sur une ligne.
(dans tout ça je n’ai pas abordé le faite qu’il y a un M. BD qui gère le dictionnaire de référence pour faire les fichiers afin d’avoir la même nomenclature pour le n° de client dans tous les fichiers ou il sera question du n° de client par exemple et non comme j’ai vue une fois le n° numérique des fois alpha et pas de la même longueur un truc immonde dans la même application )

Maintenant j’en vient aux mouvements et là, ça devient important pour le développement.
Dans les suivit de mouvement une sorte de log (MVT)
le n° de mouvement la quantité (sortie / entée etc ) la clef complète qui permet de relier le fichier entête et le fichier détail ect…

dans mon expérience*:
j’ai pris l’option de faire des modules qui converse entre eux et indépendant un peu comme la théorie des ensembles ou l’on verrait chaque module résoudre sont problème et indépendant des autres tout en étant articulé par une base de données qui définit le programme a exécuter en fonction des opérations fonctionnel à faire ce qui donne:
entrée de commande
a) création = un mvt demande de fabrication (dans l’imprimerie une commande est égale a une fabrication l’article appartenant au client est unique)
b) modification = un mvt annulation demande de fabrication , et un mvt = nouvelle demande de fabrication (bien entendu qu’il est impossible de modifier la commande alors qu’elle est pointer comme étant en phase de production etc.… je ne rentre dans le pourquoi mais pour appuyer la modularité )
ces 3 mvt donne lieu a une modification dans l’entête de l’article zone demande de fabrication
et je ne parle pas des prévisions de matière de la réalisation des demandes de livraison des livraisons retour client etc.

tout cela pour dire que l’on peut faire des programmes de 10 000 lignes mais oui il y a un MAIS la MAINTENANCE, et l’ÉVOLUTION et de la SÉCURITÉ (journaliser commit rollback ) ces 10 000 lignes qui font tout et qui dans le temps font que ce n’est pas gérable dans l’industrie ou c’est toujours pour hier …. Alors la solution est de granuler vos programmes pour si il y a lieu( ça peu arriver) corriger un bug , modifier le comportement , ajouter un ou des modules, on voit par là toutes les perspectives…..
on comprends tout de suite l’indépendance entre la vie de la commande et la vie du stock etc...

et de par là on ce voit et on ce doit de penser comment articuler ce projet qui comporteras des modules qui communique entre eux et cela fait parti du développement même si ça ne gère pas le stock….
ceci n’est qu’un exemple pour vous dire qu’il faut mettre aplat votre projet pour le faire coller à la réalité et encore je n’ai pas parlé des normes que vous initialiseriez afin que votre apparence soit la même dans toutes les interfaces qui seront dans l’entreprise ( ex la même touche de fonction qui fait exit idem pour update ou creat etc. les couleurs etc... ) . Et qui de plus devront être intuitive pour l’utilisateur afin que l’outil informatique (traitement de l’information mécanique) soit réellement un outil et non pas un casse tête intellectuel mais qui colle à la peau de l’entreprise et là vous verrez votre patron prendre beaucoup d’intérêt à vous avoir …..

ps( théorie des ensembles la base de données est gérer par les programmes modulaire qui eux mêmes sont articulé par la base de données et les données doivent circuler entre elles et la boucle est faite je n'ai fait ni référence à Merise ni OO mais plutôt la Méthode AXIAL rodp "relationnel-objet-data-path" qui comprend les deux précédentes faite pour faire du L4G )

voilà ce n’est pas possible en si peu de lignes de tout résumer mais je souhaite que çà vous aiguille.
Bien penser son projet c’est 50% de bien écrire son projet le reste relisez les précautions , je ne rajouterais qu’une seule chose à la présentation faite relire vos programmes et tester par d'autre et dialoguer …. ce tenir a jour dans l'évolution du langage et ne pas hésiter a remettre son tablier pour réactualiser les applications.

Salut,

Citation:

---

Envoyé par JPLAROCHE

Je voudrais aussi dire par expérience venant du monde industriel ayant fait de la gestion d’entreprise et du system pendant plus de 40ans. et remercier l'auteur de l'article qui m'a donnée l'idée de vous écrire ce petit mot.

---

Merci également à vous pour ce retour d'expérience fort utile. :ccool:

23 principes, c'est beaucoup trop ...

J'ai souri en lisant le paragraphe sur l'inutilité d'avoir une généricité sur le code d'accès à la base de donnée. C'est souvent la question que je pose à ceux qui n'en démordent pas de la couche d'abstraction aux données : comparez le coût en développement (très important), par rapport à l'utilité de cette abstraction? Pour ma part, en 20 ans (Java/DotNet/JS); jamais eu besoin de changer une BDD. Utilité : zéro. ;)

C'est quand même beaucoup une question de contexte. Tous ces points sont souvent vrais, mais il faut connaitre son domaine d'application, et vérifier que ça s'applique bien. La "couche d'accès aux données", moi, je l'ai vu très utile dans un SI monstrueux(3000 programmeurs), parce-qu'au final, les accès aux données étaient confiés à des spécialistes qui optimisaient vachement bien, et nous les programmeurs nous occupions du reste. C'était certes plus couteux en termes de temps d'intervention(2 personnes travaillent toujours plus lentement qu'une seule), mais la performance était absolument décisive. et confiée à des spécialistes qui ne faisaient que ça.

Et, évidemment, cet exemple est hyper spécifique, et faux dans la plupart des cas. Ou le conseil générique qui est donné sera préférable(et d'ailleurs, je l'applique dans mon métier actuel).

Le typage fort, je suis à 100% pour, mais plein de cadors ne sont pas d'accord. Ce débat n'est pas clos, même si je suis du coté de l'auteur.

Citation:

---

Apprenez les modèles de conception et quand ne pas les utiliser

---

d'accord mais ça c'est une chose qui se fait plutôt à la conception du projet et du code en amont.