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

C Discussion :

Bien écrire en C


Sujet :

C

Vue hybride

Message précédent Message précédent   Message suivant Message suivant
  1. #1
    Membre Expert
    Avatar de Gruik
    Profil pro
    Développeur Web
    Inscrit en
    Juillet 2003
    Messages
    1 566
    Détails du profil
    Informations personnelles :
    Âge : 42
    Localisation : France

    Informations professionnelles :
    Activité : Développeur Web

    Informations forums :
    Inscription : Juillet 2003
    Messages : 1 566
    Par défaut Bien écrire en C
    BIEN ECRIRE EN C
    Bonjour,

    Ce topic a pour but d'essayer de proposer un ensemble de règles de bonne conduite pour écrire du C propre, lisible, maintenable.
    Se fixer et clarifier des règles permettrait justement de nous aider à répondre à la question "quelle est la meilleure écriture pour ce que j'ai à faire?".
    Cela permettrait aussi en cas de relecture de mieux savoir pourquoi on a procédé de telle manière.

    Ces règles peuvent prendre en compte un paramètre de rigueur et proposer une solution moins stricte si on considère que la rigueur demandée peut dans certains cas être trop contraignante (à voir).
    On peut prendre l'Echelle de Goret d'Emmanuel Delahaye et le topic du Çaymal comme base.

    Tout utilisateur du forum de developpez.com peut contribuer, les règles pouvant être discutées dans ce topic (à éviter) ou dans des topics dédiés. J'éditerai alors au fur et à mesure ce topic ci pour y ajouter les règles débattues.
    Le fondement même de ce topic (c'est à dire, ce que je suis en train d'écrire), son organisation, les rubriques, etc.. peuvent également être discutés.

    Cela va de soi mais en toute circonstance, ne nous énervons pas et restons courtois.

    Voici une proposition de plan, dites moi si il vous convient :

    A) La forme
    Evoquons ici l'aspect mise en page.

    indentation, aération, taille du code, identificateurs, commentaires...

    B) Les sources et la compilation séparée
    Car tout gros projet est forcement modulaire et on sait pas forcément comment le segmenter.

    taille des sources, static, quoi mettre dans les headers, variables globales, qui peut utiliser qui, makefile (à voir)..

    C) Le langage C
    Parlons de la bonne utilisation des outils du C et de ses fonctionnalités avancées qui premettent de faire du code meilleur, plus élégant.

    structures de controle, types, enums, consts, constantes symboliques, macros...

    D) La librairie standard du C
    Pour utiliser correctement les fonctions de la stdlib.

    E) L'aspect optimisation
    Car faire plusieurs fois le même traitement à la machine peut être considéré comme crade.

    F) La vie, l'univers et le reste
    Rubrique fourre-tout, car je peux pas prévoir à l'avance avec exactitude ce qu'on pourrait mettre

  2. #2
    Membre Expert
    Avatar de Gruik
    Profil pro
    Développeur Web
    Inscrit en
    Juillet 2003
    Messages
    1 566
    Détails du profil
    Informations personnelles :
    Âge : 42
    Localisation : France

    Informations professionnelles :
    Activité : Développeur Web

    Informations forums :
    Inscription : Juillet 2003
    Messages : 1 566
    Par défaut
    (post réservé, ne pas supprimer svp)
    (encore 6 comme ça, mais je peux pas poster à moins de 30 secondes d'interval)

  3. #3
    Membre Expert
    Avatar de Gruik
    Profil pro
    Développeur Web
    Inscrit en
    Juillet 2003
    Messages
    1 566
    Détails du profil
    Informations personnelles :
    Âge : 42
    Localisation : France

    Informations professionnelles :
    Activité : Développeur Web

    Informations forums :
    Inscription : Juillet 2003
    Messages : 1 566
    Par défaut
    (post réservé, ne pas supprimer svp)

    2/7

  4. #4
    Membre Expert
    Avatar de Gruik
    Profil pro
    Développeur Web
    Inscrit en
    Juillet 2003
    Messages
    1 566
    Détails du profil
    Informations personnelles :
    Âge : 42
    Localisation : France

    Informations professionnelles :
    Activité : Développeur Web

    Informations forums :
    Inscription : Juillet 2003
    Messages : 1 566
    Par défaut
    (post réservé, ne pas supprimer svp)
    3/7

  5. #5
    Membre Expert
    Avatar de Gruik
    Profil pro
    Développeur Web
    Inscrit en
    Juillet 2003
    Messages
    1 566
    Détails du profil
    Informations personnelles :
    Âge : 42
    Localisation : France

    Informations professionnelles :
    Activité : Développeur Web

    Informations forums :
    Inscription : Juillet 2003
    Messages : 1 566
    Par défaut
    (post réservé, ne pas supprimer svp)
    4/7

  6. #6
    Membre Expert
    Avatar de Gruik
    Profil pro
    Développeur Web
    Inscrit en
    Juillet 2003
    Messages
    1 566
    Détails du profil
    Informations personnelles :
    Âge : 42
    Localisation : France

    Informations professionnelles :
    Activité : Développeur Web

    Informations forums :
    Inscription : Juillet 2003
    Messages : 1 566
    Par défaut
    (post réservé, ne pas supprimer svp)
    5/7

  7. #7
    Expert confirmé

    Inscrit en
    Novembre 2005
    Messages
    5 145
    Détails du profil
    Informations forums :
    Inscription : Novembre 2005
    Messages : 5 145
    Par défaut
    Il est important de se rendre compte qu'il y a reellement deux categories distinctes:
    • les conventions de codage
    • des regles de bonnes pratiques
    plus ou moins floues.

    Dans le premier cas, il y a plusieurs bons choix mais a l'interieur d'un projet, il est surtout important d'en faire un et de s'y tenir; on sait qu'il y a une part d'arbitraire. Ca concerne par exemple l'indentation ou la maniere dont sont choisis les identificateurs.

    Dans le second, il y a un choix meilleur qui est generalement meilleur que les autres (par exemple ne pas avoir de fonctions trop longue; celle-ci est interessante parce que tel que formulee, c'est une bonne pratique, si on la formule "ne pas avoir de fonctions de plus de 30 lignes", c'est une convention, ou plus exactement le choix de 30 est une convention, 30 ce n'est pas intrinsequement meilleur que 29 ou 31).

    Il y a une regle de bonne pratique qui est importante et qui dit qu'aucune regle n'est absolue, elles peuvent etre toutes enfreintes pour autant qu'on justifie l'infraction.

    Et il devrait avoir une convention qui indique comment on marque les infractions volontaires et justifiees pour qu'on puisse fixer les autres.

  8. #8
    Membre Expert
    Avatar de Gruik
    Profil pro
    Développeur Web
    Inscrit en
    Juillet 2003
    Messages
    1 566
    Détails du profil
    Informations personnelles :
    Âge : 42
    Localisation : France

    Informations professionnelles :
    Activité : Développeur Web

    Informations forums :
    Inscription : Juillet 2003
    Messages : 1 566
    Par défaut
    Citation Envoyé par Jean-Marc.Bourguet
    Il y a une regle de bonne pratique qui est importante et qui dit qu'aucune regle n'est absolue, elles peuvent etre toutes enfreintes pour autant qu'on justifie l'infraction.

    Et il devrait avoir une convention qui indique comment on marque les infractions volontaires et justifiees pour qu'on puisse fixer les autres.
    Donc tu préconises que pour chaque projet, on fixe les conventions en fonction de la nature du projet et en se basant sur les règles, regles qui ne devraient pas être absolues mais donner une piste de bonne conduite.

    Donc j'ai confondu règle et convention, car ces des conventions que j'aurais préféré établir.

    Je pensais que vouloir établir des règles flexibles revienne au meme que ne pas mettre de regles car on se demanderait alors toujours "est-ce que je peux m'autoriser ceci ou cela?"

  9. #9
    Expert confirmé

    Inscrit en
    Novembre 2005
    Messages
    5 145
    Détails du profil
    Informations forums :
    Inscription : Novembre 2005
    Messages : 5 145
    Par défaut
    Citation Envoyé par Gruik
    Donc tu préconises que pour chaque projet, on fixe les conventions en fonction de la nature du projet et en se basant sur les règles, regles qui ne devraient pas être absolues mais donner une piste de bonne conduite.
    Je suis un peu plus strict que cela, toute infraction doit etre justifiee. Comment? Ca peut etre simplement par un commentaire conventionnel indiquant que l'infraction est voulue, ou un document annexe, ou simplement etre pret lors d'une revue de code a dire pourquoi... on entre a nouveau dans la maniere dont le projet est gere.

    Je pensais que vouloir établir des règles flexibles revienne au meme que ne pas mettre de regles car on se demanderait alors toujours "est-ce que je peux m'autoriser ceci ou cela?"
    Le probleme de regles trop strictes, c'est que si on veut etre quand meme raisonnable, il va falloir en mettre beaucoup et les compliquer. Et on arrive alors a ce que personne ne les connait sauf les deux ou trois qui se sont impliques dans leur redaction, donc personne ne les applique. Je prefere peu de regles simples et un mecanisme plus ou moins strict pour justifier les infractions.

    Donc j'ai confondu règle et convention, car ces des conventions que j'aurais préféré établir.
    Dans un cadre comme celui-ci on peut discutter des bonnes pratiques parce qu'elles ont un interet intrinseque. Les conventions n'ont d'interet que par leur respect. On peut donc fixer un choix de conventions possibles mais il y a un risque de degenerer en discussions sans interet sur le merite de Mots_Avec_Underscore par raport a camelCase.

  10. #10
    Rédacteur
    Avatar de Franck.H
    Homme Profil pro
    Développeur .NET
    Inscrit en
    Janvier 2004
    Messages
    6 951
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 48
    Localisation : France, Haut Rhin (Alsace)

    Informations professionnelles :
    Activité : Développeur .NET
    Secteur : Service public

    Informations forums :
    Inscription : Janvier 2004
    Messages : 6 951
    Par défaut
    D'après moi, le mieux est d'avoir des règles de bases qui serviront pour chaque projets, conventions, règles de codage, etc... comme je le fait moi même dans mes projets, je suis le genre à être plus que strict dans le cas des conventions mises en place !

    Voici, si cela peut aider, une des base de mes conventions pour les boucles, conditions et fonctions:

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    32
    33
    34
    35
    36
    37
    38
    39
    40
    41
    42
    43
    44
    45
    46
    47
    48
    49
    50
    51
    52
    53
    54
    55
    56
    57
    58
    59
    60
    61
    62
    63
    64
    65
    66
    67
    68
    69
     
    La largeur sera de 80 colonnes (+ ou -), règle assez strict vu que certains programmeurs
    éditent leur code avec des programme d'édition en mode console comme VI/VIM/Etc...
    Les tabulation devront obligatoirement êtres des espace au nombre de 3.
    N'hésitez surtout pas à aérer le code, il n'en sera que plus agréable à lire !
     
    Boucles et conditions:
     
    La présentation des boucles et conditions devront être sous cette forme, qui apporte une meilleure lisibilité du code:
     
    switch/if/while/do/for
    {
    }
     
    de même, les différents choix d'un switch devront être sous cette forme:
     
    switch (var)
    {
       case val:
       {
       }
       break;
       ...
       default:
          break;
    }
     
    et les conditions if, même si elle n'exécute qu'une seule instruction, préférez cette
    forme:
     
    if (condition)
    {
    }
    else ou else if (condition)
    {
    }
     
    Cette forme pour les conditions est aussi autorisé:
     
    if (condition1 ||
        condition2)
    {
    }
     
    cela permet une meilleure lisibilité du code s'il y a un grand nombre de conditions à
    tester.
     
     
    Fonctions:
     
    Les fonctions peuvent prendre différents types de formes suivant leur nombres
    d'arguments, voici les formes autoritsées:
     
    type nom_fonction (arg1, arg2, arg_n)
    {
    }
     
    type nom_fonction (arg1,
                       arg2,
                       arg_n)
    {
    }
     
    type nom_fonction (arg, arg, arg_n,
                       arg, arg, arg_n)
    {
    }
     
    Soyez aussi vigilent à laisse des lignes vide entre chaque fonctions aussi, je préconise donc 2 (deux) lignes blanches !
    Rien de bien extraodinaire mais gage de bonne lisibilité du code source !
    Je me sert toujours des mêmes bases, puis d'après le type de projet, je fait l'emrobage autour !
    D'après moi, une des clé majeur pour l'écriture d'un bon code est avant tout d'aérer le code source !
    Mon Site
    Ma bibliothèque de gestion des chaînes de caractères en C

    L'imagination est plus importante que le savoir. A. Einstein

    Je ne répond à aucune question technique par MP, merci d'avance !

  11. #11
    Membre Expert
    Avatar de Gruik
    Profil pro
    Développeur Web
    Inscrit en
    Juillet 2003
    Messages
    1 566
    Détails du profil
    Informations personnelles :
    Âge : 42
    Localisation : France

    Informations professionnelles :
    Activité : Développeur Web

    Informations forums :
    Inscription : Juillet 2003
    Messages : 1 566
    Par défaut
    Citation Envoyé par Jean-Marc.Bourguet
    Le probleme de regles trop strictes, c'est que si on veut etre quand meme raisonnable, il va falloir en mettre beaucoup et les compliquer.
    C'est pour cela que j'avais pensé à proposer une version stricte et une version moins stricte de ces règles, un peu comme si on faisait du XHTML strict ou transitionnal.

    Citation Envoyé par Jean-Marc.Bourguet
    Et on arrive alors a ce que personne ne les connait sauf les deux ou trois qui se sont impliques dans leur redaction, donc personne ne les applique.
    Lol, ok

    Citation Envoyé par Jean-Marc.Bourguet
    Je prefere peu de regles simples et un mecanisme plus ou moins strict pour justifier les infractions.

    Dans un cadre comme celui-ci on peut discutter des bonnes pratiques parce qu'elles ont un interet intrinseque. Les conventions n'ont d'interet que par leur respect. On peut donc fixer un choix de conventions possibles mais il y a un risque de degenerer en discussions sans interet sur le merite de Mots_Avec_Underscore par raport a camelCase.
    Lol, pas bete.

    Ok, je pense finalement que je vais finalement laisser tomber, c'est plus simple si chacun se fait sa propre idée en se basant sur la gorettitude de Emdel
    C'est trop compliqué et ça me convient pas si je dois donner des règles floues et que je veux être exhaustif

  12. #12
    Rédacteur
    Avatar de Franck.H
    Homme Profil pro
    Développeur .NET
    Inscrit en
    Janvier 2004
    Messages
    6 951
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 48
    Localisation : France, Haut Rhin (Alsace)

    Informations professionnelles :
    Activité : Développeur .NET
    Secteur : Service public

    Informations forums :
    Inscription : Janvier 2004
    Messages : 6 951
    Par défaut
    Citation Envoyé par Gruik
    Ok, je pense finalement que je vais finalement laisser tomber, c'est plus simple si chacun se fait sa propre idée en se basant sur la gorettitude de Emdel
    C'est trop compliqué et ça me convient pas si je dois donner des règles floues et que je veux être exhaustif
    Je pense qu'il est possible assez facilement de créer quelques règles de bases concernant l'écriture et la bonne conduite, donner quelques conseils enrobés de quelques exemples de code "Goret" et leur équivalent en beau code !
    Mon Site
    Ma bibliothèque de gestion des chaînes de caractères en C

    L'imagination est plus importante que le savoir. A. Einstein

    Je ne répond à aucune question technique par MP, merci d'avance !

Discussions similaires

  1. bien écrire en c/c++
    Par senvedgi dans le forum Débuter
    Réponses: 24
    Dernier message: 30/11/2012, 01h48
  2. Réponses: 4
    Dernier message: 09/04/2009, 17h48
  3. Programmer encore en VB 6 c'est pas bien ? Pourquoi ?
    Par Nektanebos dans le forum Débats sur le développement - Le Best Of
    Réponses: 85
    Dernier message: 10/03/2009, 14h43
  4. Initialisation (ou bien écrire du code)
    Par boijea dans le forum Langage
    Réponses: 16
    Dernier message: 24/11/2008, 12h40
  5. Conseils pour bien écrire les classes ado.net
    Par azerty53 dans le forum VB.NET
    Réponses: 3
    Dernier message: 15/05/2007, 17h24

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