Principes de conception, les pratiques exemplaires et modèles de conception pour C (ou la programmation procédurale en général)? [fermé]

Question

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

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

Answer 1

cacher l'information -. Comme embrassée par Parnas ( Principes de base du logiciel )

Une gestion attentive des en-têtes et la visibilité:

• Tout dans un fichier source qui peut être caché du monde extérieur devrait être; seule l'interface externe documentée devrait être exposée.
• Tout ce qui est exposé est déclaré dans un en-tête.
• Ce en-tête est utilisé lorsque la fonctionnalité est nécessaire (et où elle est définie).
• L'en-tête est autonome - quand vous en avez besoin, vous l'utilisez, et vous n'avez pas à vous soucier de « ce que les autres en-têtes dois-je également inclure » parce que l'en-tête assure qu'il fonctionne en incluant tout ce dont il a besoin pour le faire fonctionner.

• L'en-tête est auto-protégé -. Il n'a pas d'importance si elle est incluse plusieurs fois

  #ifndef HEADER_H_INCLUDED
  #define HEADER_H_INCLUDED
  ...rest of header contents, including other #include lines if necessary
  #endif /* HEADER_H_INCLUDED */
  

• ensembles de conception des fonctions pour travailler sur des « objets » (généralement des structures) - et d'utiliser ces fonctions plutôt que de fouiller les entrailles de la structure du code qui l'utilise. Pensez-y comme l'encapsulation auto-imposée.

Answer 2

Il y a un bon, libre, livre en ligne, intitulé Programmation orientée objet avec ANSI-C , qui couvre le thème de l'écriture de code orienté objet dans C. a MISRA-C est un bon ensemble de règles. Il est destiné principalement pour les c embarqués, mais il peut être utile dans d'autres domaines.

Je me considère comme un codeur OO, et je fais beaucoup de travail avec-C intégré. Le meilleur conseil que je peux donner, en particulier pour les grands projets, est de ne pas exagérer. Création d'un cadre complet OO sur le dessus de la norme ANSI C peut être très tentant, mais il faut beaucoup de temps et d'efforts pour y arriver. Le colombophile vous obtenez, plus vous passerez le débogage de votre cadre au lieu de travailler sur le réel projet. L'approche de la tâche avec une tête claire, et une bonne connaissance solide de YAGNI . Bonne chance!

Answer 3

Mes trois conseils:

• les tests unitaires d'écriture. Ils vous aideront à zéro dans une conception que les suites de votre problème que vous avancez. Beaucoup mieux que de compter (uniquement) sur la pensée prémédités.
• Avoir un détecteur de fuite de mémoire (il y a toutes sortes de bibliothèques là-bas) installé et en cours d'exécution depuis le premier jour. Cette impression de bibliothèque toutes les fuites dès que le programme / sorties de tests. Cela vous permettra d'attraper une fuite dès que vous introduisez, rendant ainsi sa fixation beaucoup moins douloureux.
• Ecrire le code POO en C. pas si difficile. Bien qu'il soit possible d'imiter la méthode dominante, je vous suggère de commencer avec l'émulation d'objets simples. Même ce mécanisme simple peut vous donner un grand kilométrage.

Voici un exemple:

typedef struct Vector {
  int size;
  int limit;
  int* ints; 
} Vector;

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;
}

Answer 4

POO est une méthode pas une technologie. Donc, mon premier conseil est la pensée d'arrêt comme la programmation procédurale.

Pour point de e.James, vous ne voulez pas essayer de recréer un langage orienté objet ou prétendre que vous avez les capacités de celle-ci. Vous pouvez toujours faire toutes les bonnes choses en s'accrochant à quelques principes simples:

1. Tester tout lecteur.
2. En ce qui varie et encapsuler.
3. Conception d'interfaces.

Answer 5

C SEI CERT Norme de codage offre Bonne ensemble de règles et de bonnes pratiques communes ainsi que les choses que vous devriez essayer d'éviter d'utiliser.