Principes de conception, meilleures pratiques et modèles de conception pour C (ou programmation procédurale en général)?

Existe-t-il des principes de conception, des meilleures pratiques et des modèles de conception connus que l’on peut suivre lors de la conception d’un projet C? Ou des principes de conception utiles pour la programmation procédurale (impérative) en général?

(Je suis un enfant de la «génération orientée object» et je dois concevoir un grand projet C pour la première fois)

    La dissimulation d’informations – telle qu’adoptée par Parnas ( Principes fondamentaux des logiciels ).

    Gestion attentive des en-têtes et de la visibilité:

    • Tout ce qui peut être caché du monde extérieur dans un fichier source devrait l’être; seule l’interface externe documentée doit être exposée.
    • Tout ce qui est exposé est déclaré dans un en-tête.
    • Cet en-tête est utilisé lorsque la fonctionnalité est nécessaire (et où il est défini).
    • L’en-tête est autonome – quand vous en avez besoin, vous l’utilisez et vous n’avez pas à vous soucier des «autres en-têtes que je dois aussi inclure», car l’en-tête garantit qu’il fonctionne en incluant tout ce dont il a besoin travail.
    • L’en-tête est auto-protégé – peu importe qu’il soit inclus plusieurs fois.

      #ifndef HEADER_H_INCLUDED #define HEADER_H_INCLUDED ...rest of header contents, including other #include lines if necessary #endif /* HEADER_H_INCLUDED */ 
    • Concevez des ensembles de fonctions pour travailler sur des «objects» (généralement des structures) – et utilisez ces fonctions plutôt que de contourner les entrailles de la structure dans le code qui l’utilise. Considérez-le comme une encapsulation auto-imposée.

    Il existe un bon livre en ligne gratuit, intitulé Programmation orientée object avec ANSI-C , qui traite de l’écriture de code orienté object en langage C. Une recherche sur Google pour «object orienté C» produit également un certain nombre d’autres exemples et ressources.

    Si votre projet est critique pour la sécurité, MISRA-C est un bon ensemble de règles. Il est principalement destiné au c embarqué, mais peut également être utile dans d’autres domaines.

    Je me considère comme un codeur OO et je travaille beaucoup avec Embedded-C. Le meilleur conseil que je puisse donner, en particulier pour les grands projets, n’est pas de trop en faire. Créer un cadre OO complet au-dessus de C ANSI peut être très tentant, mais il faut beaucoup de temps et d’efforts pour bien faire les choses. Plus vous obtiendrez de fantaisie, plus vous passerez de temps à déboguer votre framework au lieu de travailler sur le vrai projet. Aborder la tâche avec une tête claire et une bonne compréhension de YAGNI . Bonne chance!

    Mes trois conseils:

    • Ecrire des tests unitaires. Ils vous aideront à cibler une conception qui correspond à votre problème au fur et à mesure. Bien mieux que de compter (uniquement) sur la pensée pré-méditée.
    • Avoir un détecteur de fuite de mémoire (il y a toutes sortes de bibliothèques) installées et fonctionnant dès le premier jour. Demandez à cette bibliothèque d’imprimer toutes les fuites dès que le programme / test se termine. Cela vous permettra de détecter une fuite dès que vous l’introduisez, rendant ainsi sa fixation beaucoup moins douloureuse.
    • Ecrivez le code OOP en C. Pas si difficile. Bien qu’il soit possible d’émuler une méthode de substitution, je vous suggère de commencer par émuler des objects simples. Même ce mécanisme simple peut vous donner un bon kilométrage.

    Voici un exemple:

     struct Vector { int size; int limit; int* ints; } Vector* Vector_new() { Vector* res = (Vector*) malloc(sizeof(Vector)); res->limit = 10; res->size = 0; res->ints = (int*) malloc(sizeof(int) * res.limit); return res; } void Vector_destroy(Vector* v) { free(v->ints); free(v); } void Vector_add(Vector* v, int n) { if(v->size == v->limit) { v->limit = v->limit * 2 + 10; v->ints = realloc(v->ints, v->limit); } v->ints[v->size] = n; ++v->size; } int Vector_get(Vector* v, int index) { if(index >= 0 && index < v->size) return v->ints[index]; assert false; } 

    La POO est une méthodologie et non une technologie. Donc, mon premier conseil est de ne plus penser à la programmation procédurale.

    Au sharepoint vue de James, vous ne voulez pas essayer de recréer un langage orienté object ou prétendre en avoir les capacités. Vous pouvez toujours faire toutes les bonnes choses en vous attachant à quelques principes simples:

    1. Testez tout.
    2. Trouvez ce qui varie et encapsulez-le.
    3. Conception aux interfaces.

    La norme de codification SEI CERT C fournit un bon ensemble de règles et de bonnes pratiques communes, ainsi que des éléments que vous devez éviter d’utiliser.