IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Langages de programmation Discussion :

Apprendre 23 principes pour écrire du code lisible [Tutoriel]


Sujet :

Langages de programmation

  1. #1
    Community Manager

    Avatar de Malick
    Homme Profil pro
    Community Manager
    Inscrit en
    Juillet 2012
    Messages
    9 119
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Sénégal

    Informations professionnelles :
    Activité : Community Manager
    Secteur : Conseil

    Informations forums :
    Inscription : Juillet 2012
    Messages : 9 119
    Points : 83 898
    Points
    83 898
    Billets dans le blog
    15
    Par défaut 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 :


    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

    Retrouvez les meilleurs cours et tutoriels pour apprendre la programmation
    Vous avez envie de contribuer au sein du Club Developpez.com ? Contactez-nous maintenant !
    Vous êtes passionné, vous souhaitez partager vos connaissances en informatique, vous souhaitez faire partie de la rédaction.
    Il suffit de vous porter volontaire et de nous faire part de vos envies de contributions :
    Rédaction d'articles/cours/tutoriels, Traduction, Contribution dans la FAQ, Rédaction de news, interviews et témoignages, Organisation de défis, de débats et de sondages, Relecture technique, Modération, Correction orthographique, etc.
    Vous avez d'autres propositions de contributions à nous faire ? Vous souhaitez en savoir davantage ? N'hésitez pas à nous approcher.

  2. #2
    Membre régulier
    Profil pro
    Inscrit en
    Juin 2009
    Messages
    27
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Juin 2009
    Messages : 27
    Points : 73
    Points
    73
    Par défaut Merci
    Merci de la traduction.
    Plein de "bon sens" mais ça fait du bien de lire ce style de truc

  3. #3
    Membre expérimenté

    Homme Profil pro
    Retraite
    Inscrit en
    Octobre 2005
    Messages
    477
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 72
    Localisation : France, Aude (Languedoc Roussillon)

    Informations professionnelles :
    Activité : Retraite
    Secteur : Industrie

    Informations forums :
    Inscription : Octobre 2005
    Messages : 477
    Points : 1 332
    Points
    1 332
    Billets dans le blog
    1
    Par défaut
    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....

  4. #4
    Membre expérimenté

    Homme Profil pro
    Retraite
    Inscrit en
    Octobre 2005
    Messages
    477
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 72
    Localisation : France, Aude (Languedoc Roussillon)

    Informations professionnelles :
    Activité : Retraite
    Secteur : Industrie

    Informations forums :
    Inscription : Octobre 2005
    Messages : 477
    Points : 1 332
    Points
    1 332
    Billets dans le blog
    1
    Par défaut
    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.

  5. #5
    Community Manager

    Avatar de Malick
    Homme Profil pro
    Community Manager
    Inscrit en
    Juillet 2012
    Messages
    9 119
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Sénégal

    Informations professionnelles :
    Activité : Community Manager
    Secteur : Conseil

    Informations forums :
    Inscription : Juillet 2012
    Messages : 9 119
    Points : 83 898
    Points
    83 898
    Billets dans le blog
    15
    Par défaut
    Salut,

    Citation Envoyé par JPLAROCHE Voir le message
    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.
    Vous avez envie de contribuer au sein du Club Developpez.com ? Contactez-nous maintenant !
    Vous êtes passionné, vous souhaitez partager vos connaissances en informatique, vous souhaitez faire partie de la rédaction.
    Il suffit de vous porter volontaire et de nous faire part de vos envies de contributions :
    Rédaction d'articles/cours/tutoriels, Traduction, Contribution dans la FAQ, Rédaction de news, interviews et témoignages, Organisation de défis, de débats et de sondages, Relecture technique, Modération, Correction orthographique, etc.
    Vous avez d'autres propositions de contributions à nous faire ? Vous souhaitez en savoir davantage ? N'hésitez pas à nous approcher.

  6. #6
    Membre expérimenté
    Profil pro
    chercheur
    Inscrit en
    Avril 2004
    Messages
    830
    Détails du profil
    Informations personnelles :
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : chercheur

    Informations forums :
    Inscription : Avril 2004
    Messages : 830
    Points : 1 430
    Points
    1 430
    Par défaut
    23 principes, c'est beaucoup trop ...
    Ce qui s'énonce clairement se conçoit bien ( Le hautbois)

  7. #7
    Membre chevronné

    Profil pro
    Conseil - Consultant en systèmes d'information
    Inscrit en
    Février 2004
    Messages
    758
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations professionnelles :
    Activité : Conseil - Consultant en systèmes d'information

    Informations forums :
    Inscription : Février 2004
    Messages : 758
    Points : 2 085
    Points
    2 085
    Par défaut
    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.

  8. #8
    Expert éminent sénior
    Profil pro
    Inscrit en
    Décembre 2007
    Messages
    6 803
    Détails du profil
    Informations personnelles :
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations forums :
    Inscription : Décembre 2007
    Messages : 6 803
    Points : 32 044
    Points
    32 044
    Par défaut
    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.
    Les 4 règles d'airain du développement informatique sont, d'après Michael C. Kasten :
    1)on ne peut pas établir un chiffrage tant qu'on a pas finalisé la conception
    2)on ne peut pas finaliser la conception tant qu'on a pas complètement compris toutes les exigences
    3)le temps de comprendre toutes les exigences, le projet est terminé
    4)le temps de terminer le projet, les exigences ont changé
    Et le serment de non-allégiance :
    Je promets de n’exclure aucune idée sur la base de sa source mais de donner toute la considération nécessaire aux idées de toutes les écoles ou lignes de pensées afin de trouver celle qui est la mieux adaptée à une situation donnée.

  9. #9
    Expert éminent sénior
    Avatar de Mat.M
    Profil pro
    Développeur informatique
    Inscrit en
    Novembre 2006
    Messages
    8 347
    Détails du profil
    Informations personnelles :
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : Novembre 2006
    Messages : 8 347
    Points : 20 347
    Points
    20 347
    Par défaut
    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.

Discussions similaires

  1. 12 règles à respecter pour écrire un code JavaScript professionnel
    Par Victor Vincent dans le forum Général JavaScript
    Réponses: 20
    Dernier message: 27/11/2016, 11h32
  2. Développeurs : Conseils professionnels pour écrire du code lisible !
    Par Mingolito dans le forum Humour Informatique
    Réponses: 0
    Dernier message: 20/06/2016, 23h45
  3. Réponses: 6
    Dernier message: 15/01/2008, 19h51
  4. Réponses: 1
    Dernier message: 17/04/2007, 14h07

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo