PRINCIPES DE PROGRAMMATION EN C

1. PRINCIPES DE PROGRAMMATIONEN C .

2. OBJECTIFS • .

3. REGLES DE CODAGE • OBJECTIFS • POURQUOI DES REGLES • LES REGLES POUR QUEL LANGAGE • VUE GLOBALE • REGLES DIVERSES

4. DES REGLES POURQUOI ? • LISIBLE • STRUCTURER • MAINTENABLE • PORTABLE • EVITER LES PROBLEMES

5. DES REGLES POUR QUELS LANGAGES • C, la référence • PASCAL, le compromis avec le passé • VAX, BSO, OREGON • ASSEMBLEUR, un combat dépassé • ADA, pour les pros • C++, la nouvelle référence

6. LES QUALITES VISEES • faible couplage externe • forte cohésion interne • bonne décomposabilité • bonne composabilité • bonne compréhensibilité • non ambiguïté • portabilité • testabilité

7. FAIBLE COUPLAGE ET FORTE COHESION

8. BONNE DECOMPOSABILITE

9. BONNE COMPOSABILITE

10. NOTATION COD-CNN/X • CATEGORIE C • S REGLE DE STRUCTURATION • P REGLE DE PRESENTATION • D REGLE SUR LES DONNEES • I REGLE SUR LES INSTRUCTIONS • G REGLE GENERALE • O REGLE DE PROGRAMMATION ORIENTEE OBJETS • OBLIGATION X • O REGLE OBLIGATOIRE • T|R REGLE RECOMMANDEE • F REGLE FACULTATIVE

11. CHOIX DES REGLES • DANS LES NORMES DE DEVELOPPEMENT OU LE PLAN DE DEVELOPPEMENT • EN COMPLETANT LA GRILLE ANNEXE • EN FONCTION DES NIVEAUX, FUTURE NOTATION [12 ]COD-CNN • 1,2,3 EN SOULIGNE : OBLIGATOIRE • 1.,2,3 EN NORMAL : RECOMMANDEE • 1,2,3 REMPLACE PAR UN ESPACE : FACULTATIF

12. CHOIX DES REGLES • (G01/O) Une dérogation à une règle de codage doit faire l'objet d'une justification. Une dérogation à une règle de codage doit être accompagnée de mesures complémentaires pour compenser la perte de qualité.

13. CONCEPTION PRELIMINAIRE • ARCHITECTURE LOGIQUE • ARCHITECTURE DYNAMIQUE • ARCHITECTURE PHYSIQUE

14. ARCHITECTURE PHYSIQUE • METHODE STRUCTUREE : DECOMPOSITION EN MODULES FONCTIONNELS • METHODE OBJET : DECOMPOSITION EN OBJETS • COMPOSANT = MODULES FONCTIONNELS OU OBJETS

15. ARCHITECTURE PHYSIQUE • Décomposition en composants • Spécification des composants

16. L'ARTICLE • DONNEE = • CONSTANTE • ou TYPE • ou VARIABLE • ou TRAITEMENT • SOUS-PROGRAMME (FONCTION/PROCEDURE) • ou TACHE • ou MACRO

17. COMPOSANT = MODULE • GROUPE/ENSEMBLE D'ARTICLES • A FORTE COHESION INTERNE • A FAIBLE COUPLAGE

18. PROPRIETE D'UN ARTICLE • (S01/O) Tout article doit avoir une définition unique à laquelle tous les utilisateurs se réfèrent. • > DEFINITION DANS DES FICHIERS INCLUS • > OU GERE PAR LE LANGAGE (EX ADA) • > OU GERE PAR UN OUTIL (EX OSCAR) • (S02/F) La propriété d'un article est donnée à un composant et un seul. • > DEFINITION GLOBALE/EXPORTABLE DANS UN SEUL COMPOSANT • > REFERENCE EN EXTERNE/IMPORTE DANS LES COMPOSANTS UTILISATEURS

19. COMMENT REGROUPER LES ARTICLES • POUR AVOIR BEAUCOUP D'ARTICLES LOCAUX • POUR AVOIR PEU D'ARTICLES GLOBAUX/EXPORTABLES

20. S03 = SOLUTION IDEALE A S01+S02 • (S03/F) Chaque composant est constitué d'une interface et d'un ou de plusieurs corps. Chaque élément comporte une interface. Ces interfaces contiennent les déclarations accessibles de l'extérieur. UTILISATEURS INTERFACE CORPS UTILISATEURS UTILISATEURS

21. SEPARATION INTERFACE/CORPS EN C/C++ M1.H M2.H #include M1.H #include M2.H M1.C M2.C

22. SI M2 UTILISE M1 M1.H M2.H #include M1.H #include M2.H M1.C M2.C #include M1.H

23. TYPE GLOBAL M1.H M2.H typedef definition m1_type; #include M1.H #include M2.H M1.C M2.C #include M1.H m1_type variable;

24. VARIABLE GLOBALE M1.H M2.H extern m1_type m1_variable; #include M1.H #include M2.H M1.C M2.C #include M1.H m1_type m1_variable; m1_variable = 4;

25. FONCTION GLOBALE M1.H M2.H [extern] void m1_fnc(void); #include M1.H #include M2.H M1.C M2.C #include M1.H void m1_fnc() { } m1_fnc();

26. IMPORTATION DANS L'INTERFACE • (S05/T)L'interface d'un composant ne doit faire référence à l'interface d'un autre composant que si les déclarations de l'autre composant lui sont nécessaires pour ses propres déclarations. #include M1.H M2.H M1.H typedef definition m1_type; typedef m1_type m2_type[10]; M1.C M2.C #include M1.H #include M2.H #include M1.H m1_type variable;

27. COMMENT EVITER LES INCLUSIONS MULTIPLES M1.H M2.H #ifndef M1 #ifndef M2 #define M2 #define M1 #include M1.H typedef definition m1_type; typedef m1_type m2_type[10]; #endif #endif M1.C M2.C #include M1.H #include M2.H #include M1.H

28. COMMENT ACCELERER LA COMPILATION M1.H M2.H #ifndef M1 #ifndef M2 #define M2 #define M1 #ifndef M1 #include M1.H #endif typedef definition m1_type; typedef m1_type m2_type[10]; #endif #endif M1.C M2.C #include M1.H #include M2.H #ifndef M1 #include M1.H #endif

29. SEPARATION INTERFACE/CORPS EN PASCAL • UTILISABLE EN OREGON, DIGITAL, BSO • PROBLEME : SYNTAXES INCOMPATIBLES DE DECLARATION D'INTERNES ET D'EXTERNE • SOLUTION : UTILISER DEUX VERSION D'INTERFACE • M1.DEF -> M1.REF • GENERER LE SECOND A L'AIDE D'UN OUTIL TRANSDEFREF

30. SEPARATION INTERFACE/CORPS EN PASCAL trans_def_ref trans_def_ref M1.DEF M1.REF M2.DEF M2.REF include M1.DEF include M2.DEF M1.C M2.C include M1.REF

31. SEPARATION INTERFACE/CORPS EN ADA • IMPOSEE PAR LE LANGAGE M1.ADS M2.ADS M1.ADB M2.ADB • with M1

32. UTILISATION DE PLUSIEURS LANGAGES • (S04/T)En cas d'utilisation de plusieurs langages, un composant utilisé doit posséder une interface dans le langage du composant utilisateur. M2.DEF M1.H M1.REF M1.C #include M1.H M2.PAS include M2.DEF include M1.REF

33. UTILISATION D'ASSEMBLEUR • (S09/T)les sous-programmes assembleurs globaux doivent respecter les conventions de passage des paramètres du langage évolué utilisé. M2.H M1.inc M1.h M1.ASM include M1.inc M2.C #include M2.h #include M1.h

34. INTERFACE • DEFINITION DES ARTICLES EXPORTABLES/GLOBAUX DU COMPOSANT • ISSUS DE LA CONCEPTION PRELIMINAIRE • PEUT ETRE ECRIT DES LA CONCEPTION PRELIMINAIRE • PEUT ETRE INCLUS EN ANNEXE DE LA CONCEPTION PRELIMINAIRE • (P01/O) le cartouche d'une interface est imposé

35. INTERFACE : LES RUBRIQUES D'ENTETE • NOM DU COMPOSANT • MEMORISATION DE LA DEFINITION • CODE D'IDENTIFICATION • REUTILISABILITE • DESCRIPTION • DEROGATION • AUTEUR • HISTORIQUE • VISIBILITE/COMPOSANTS IMPORTES

36. INTERFACE : LES EXPORTATIONS • (S06/O) Seuls les articles (constante, variable, type, fonction) potentiellement utilisables par plusieurs composants peuvent être exportés. • DECLARATIONS DE CONSTANTES • DECLARATIONS DE TYPES • DECLARATION DE VARIABLES • DECLARATION DE PROTOTYPE DE FONCTIONS • DECLARATION DE MACROS-FONCTIONS

37. LE(S) CORPS : LES RUBRIQUES • (P06/F) le format du cartouche d'un corps de composant est imposé • NOM DU COMPOSANT • IMPORTATION DE L'INTERFACE • HISTORIQUE • COMPOSANTS IMPORTES

38. CORPS : LES DEFINITIONS • DONNEES EXPORTABLES • CONSTANTES LOCALES • TYPES LOCAUX • VARIABLES ET CONSTANTES LOCALES • FONCTIONS LOCALES

39. LES CONSTANTES • MACRO : #define les réserver pour les définitions de dimension (ex tableau) • (D01/T)Les constantes d'objets complexes doivent être définies comme des variables mais avec le préfixe const qui en interdit toute modification • ex : extern const float Pi; • (D02/F)Pour les listes d'états possibles, la définition d'un type énumération est préférable à celle des autres constantes. • ex : enum phase { repos, actif, en_panne };

40. LES MACROS ATTENTION DANGER • (P02/O)les noms de macros (constantes ou fonctions) doivent être écrites en majuscule, les autres identificateurs devant comporter au moins un caractère minuscule. • ELLES NE SONT PAS MASQUABLES PAR DES DECLARATIONS LOCALES

41. LES MACROS ATTENTION DANGER • (P05/O) Les arguments des macro-fonctions doivent être protégés par des parenthèses pour éviter des erreurs à l'expansion, • SAUF PROTECTION PAR DES PARENTHESES IL Y A RISQUE D'ERREUR A L'EXPANSION • (S07/T)L'utilisation de macros doit être justifiée par la criticité temps d'un composant.

42. LES TYPES GLOBAUX • LES ASSOCIER A UN COMPOSANT • REGROUPER LES FONCTIONS AGISSANT SUR CE TYPE DANS CE COMPOSANT typedef struct complexe /* définition de l'objet mathématique complexe */ { double réel; /* partie réelle */ double imaginaire; /* partie imaginaire */ }complexe;

43. LES VARIABLES GLOBALES • LIMITER LES VARIABLES GLOBALES • LES REGROUPER DANS DES STRUCTURES • (P03/F)Le premier caractère d'une variable exportable sera en majuscule, tous les autres caractères devant être en minuscule. Une variable locale sera entièrement constituée de minuscules.

44. LES FONCTIONS • (P04/O) Une déclaration (prototype) est obligatoire pour un sous-programme, dans une interface : - Elle doit être précédée par une description du sous-programme.. - Tous les arguments doivent être nommés et renseignés avec au moins une ligne par argument. (sauf la partie variable dans le cas d'un nombre variable d'arguments) et le type de l'argument (entrée, sortie, entrée/sortie, valeur de retour)

45. LES FONCTIONS ex de prototype : /* addition de deux complexes */ complexe complexe_add( complexe source1, /* entrée : opérande source */ complexe source2 /* entrée : 2é opérande source */ ); /* retour : résultat de l'addition */

46. LES FONCTIONS • (I01/O) Dans un prototype de fonction - Le type 'void *' doit être réservé à la manipulation de bloc binaire de bas niveau. - Le prototype d'une fonction sans argument doit s'écrire : void fnc(void);

47. LES FONCTIONS • (P07/F) Le format du cartouche par sous-programme est imposé. • NOM • DESCRIPTION • FONCTIONS APPELEES • DONNEES EXTERNES UTILISEES

48. LISIBILITE • A. PROGRAMMATION STRUCTUREE • B. BOUCLES • C. PARENTHESAGE • D. REGLES DE NOMMAGE • E. REGLES DE TYPAGE • F. COMPLEXITE • G. ASSEMBLEUR • H. MOTS RESERVES • I. RACCOURCIS D'ECRITURE

49. PROGRAMMATION STRUCTUREE • (P08/O)Le code et le pseudo-code doivent être structurés et commenté, ses structures doivent être mises en évidence par des indentations.

50. PROGRAMMATION STRUCTUREE • (P09/T) consignes de structuration du code et du pseudo-codestructuration - l'instruction de fin de bloc doit être alignée sous l'instruction de début de bloc, - le bloc d'instruction doit être décalé (indentation), - chaque bloc doit comporter au minimum un commentaire, - une ligne comporte au plus une instruction, - les expressions longue doivent être évitées ou réparties sur plusieurs lignes.