Your SlideShare is downloading. ×
Les bonnes pratiques de programmation
Les bonnes pratiques de programmation
Les bonnes pratiques de programmation
Les bonnes pratiques de programmation
Les bonnes pratiques de programmation
Les bonnes pratiques de programmation
Les bonnes pratiques de programmation
Les bonnes pratiques de programmation
Les bonnes pratiques de programmation
Les bonnes pratiques de programmation
Les bonnes pratiques de programmation
Les bonnes pratiques de programmation
Les bonnes pratiques de programmation
Les bonnes pratiques de programmation
Les bonnes pratiques de programmation
Les bonnes pratiques de programmation
Les bonnes pratiques de programmation
Les bonnes pratiques de programmation
Les bonnes pratiques de programmation
Les bonnes pratiques de programmation
Les bonnes pratiques de programmation
Les bonnes pratiques de programmation
Les bonnes pratiques de programmation
Les bonnes pratiques de programmation
Les bonnes pratiques de programmation
Les bonnes pratiques de programmation
Les bonnes pratiques de programmation
Les bonnes pratiques de programmation
Les bonnes pratiques de programmation
Les bonnes pratiques de programmation
Les bonnes pratiques de programmation
Les bonnes pratiques de programmation
Les bonnes pratiques de programmation
Les bonnes pratiques de programmation
Les bonnes pratiques de programmation
Les bonnes pratiques de programmation
Les bonnes pratiques de programmation
Les bonnes pratiques de programmation
Les bonnes pratiques de programmation
Les bonnes pratiques de programmation
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Les bonnes pratiques de programmation

877

Published on

Bonnes pratiques de codage

Bonnes pratiques de codage

2 Comments
0 Likes
Statistics
Notes
  • Be the first to like this

No Downloads
Views
Total Views
877
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
14
Comments
2
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Les bonnes pratiques de programmation en C++ et C# Hedi NAILY LOGO
  • 2. Problématique LOGO Ecrire un code qui fonctionne? Ecrire un code efficient? Un code maintenable? Un code réutilisable? 2
  • 3. Introduction LOGO Le plus grand soucis des développeurs est de produire un code qui s’exécute, mais la majorité d’entre eux ne veillent pas à ce que le code qu’ils écrivent soit efficient. Pour être un développeur confirmé il faut absolument adopter de bonnes pratiques de programmation. 3
  • 4. Plan 1 Conventions de nommage et d’Indentation 2 Mal Gestion de la mémoire 3 LOGO Le Stack et le Heap 4 5 Bonnes pratique pour éviter les fuites de mémoires et les crash Outils logiciels 4
  • 5. Conventions de nommage LOGO En C++, comme en C#, il convient d’utiliser certains standards pour le nommage des variables, des fonctions, des classes et des projets : Pour les projets, il convient d’utiliser des noms qui reflètent la finalité des projets : ex : BugTracker Pour l’écriture, on utilise le Pascal Casing Pour les namespaces, il convient d‘utiliser le Pascal Casing : Companie.Produit.Module.… 5
  • 6. Conventions de nommage LOGO Pour les classes, les noms qu’on choisit doivent correspondre aux objets qu’elles représentent. Les noms doivent être au singulier. On utilise le Pascal Casing pour l’écriture : public class HelloWorld { ... } 6
  • 7. Conventions de nommage LOGO Les noms des fichiers doivent correspondre aux noms des classes :  En c# : pour la classe HelloWorld HelloWorld.cs  En c++ : HelloWorld.cpp (+ éventuellement HelloWorld.h)  Ne pas utiliser de préfixes comme « C » (CHelloWorld) : inutile. 7
  • 8. Conventions de nommage LOGO  Pour les fonctions : On choisit un identificateur qui exprime une action. Ex : OuvrirFichier(),  Pour les fonction qui retournent une valeur booléene, il convient d’utiliser soit l’affirmation soit la négation, mais pour tout le projet : ex : estVide(), estNonVide() Il existe deux pratiques répandue pour l’écriture : - Pascal Casing: cf ex. Camel Casing : ouvrirFichier() - Séparer les deux mots : ouvrir_fichier() 8
  • 9. Conventions de nommage LOGO Pour les variables on utilise des identificateurs qui reflètent la valeur qu’ils représentent. Il convient d’utiliser comme préfixe une lettre suivie d’un tirait-bas concaténé au nom écrit en Camel Casing : - string l_maVariable;//pour les variables //locales - string m_monAttribut;//pour les attributs //des classes - string p_monParam;//pour les paramètres 9
  • 10. Conventions de nommage LOGO Pour les constantes, on conseille d’utiliser des lettres en majuscule  A éviter :  Ne pas utiliser les abréviations : Utiliser salaire, montant, adresse au lieu de sal, mont et adr.  Ne pas utiliser les identificateurs à un seul caractère (x, y …) sauf pour les boucles. 10
  • 11. Conventions de nommage Casse Exemple Projet Pascal BugTracker Namespace Pascal Microsoft.CSharp Classe Pascal AppDomain Interface Pascal (avec le préfixe « I ») IDisposable Méthode Pascal (action) ToString Namespace Pascal System.Drawing Paramètre " p_ " + Camel Casing LOGO p_monParametre Variable locale " l_ " + Camel Casing l_maVariable Attribut d’une classe m_monAttribut " m_ " + Camel Casing 11
  • 12. Indentation et commentaires LOGO Il convient d’utiliser les tabulations au lieu des espaces (au début des lignes) Utiliser un retour à la ligne après chaque bloc logique de code Les commentaires doivent être au même niveau que le code 12
  • 13. Indentation et commentaires LOGO Exemple : bool SayHello ( string p_maChaine ) { IList<int> l_myList; string l_fullMessage; bool l_maCondition; l_myList = new List<int> {1, 2, 3}; l_fullMessage = "Hello "; l_maCondition = false; Déclaration des variables Initialisation des variables MessageBox.Show ( l_fullMessage + p_maChaine ); if ( !l_maCondition ) { foreach ( var i in l_myList) { i = 1; //remplir la liste par des 1 } return false; } return true; } 13
  • 14. LOGO 2 Mal Gestion de la mémoire 14
  • 15. Les variables LOGO Quand une variable est déclarée, elle n’est pas automatiquement initialisée. Ne pas initialiser les variables peut mener à des bugs. Pour les attributs des classes, on utilise principalement le constructeur pour les initialiser. En c++, on conseille d’initialiser les variables juste après leur définition et pour les attributs au niveau des constructeurs 15
  • 16. Mal gestion de la mémoire LOGO La mauvaise gestion des variables peut entrainer des fuites de mémoire et peut mener à des crash :  Ex : Réallouer la mémoire avant de supprimer : char* str = new char [30]; // donne à str une //adresse mémoire str = new char [60]; // donne à str une nouvelle //adresse  perte définitive de la première //adresse. 16
  • 17. Mal gestion de la mémoire LOGO Exemple,,  char* str1 ; char* str2 ; str1 = new char [30]; str2 = = new char [40]; strcpy(str1, "Fuite de mémoire"); str2 = str1; // impossible de supprimer les 40 //octets maintenant. delete [] str2; // supprime les 30 octets delete [] str1; // Violation d’accès  crash 17
  • 18. Mal gestion de la mémoire LOGO  Utilisation des variables non initialisées void func() { char *pStr = (char*) malloc(512); char c = pStr[0]; } Accès non valide à la mémoire : char *pStr = (char*) malloc(25); free(pStr); strcpy(pStr, "parallel programming"); //invalide dans la mémoire désallouée // Ecriture 18
  • 19. Mal gestion de la mémoire LOGO Mal placement de l’opérateur delete :  int *i; while(Condition) { i = new int; ... } delete i; 19
  • 20. LOGO 3 Le Stack et le Heap 20
  • 21. Le Stack et le Heap LOGO Le heap est l’endroit de la mémoire utilisé pour l’allocation dynamique des variables Ex : int *tab= new int[10]; // on a alloué 40 octets du heap  La mémoire allouée n’est libérée que lorsqu’on la désalloue  La mémoire allouée dynamiquement est accessible via un pointeur   On doit désallouer la mémoire après l’utilisation des variables dynamiques afin d’éviter les fuites de mémoires. 21
  • 22. Le Stack et le Heap LOGO Le stack est la partie de la mémoire où sont stockés les paramètres et les variables locales des fonctions. Sa taille est limitée. Elle se remplit pendant les appels des fonctions et se libère lorsque l’exécution de ces fonctions est terminée. 22
  • 23. Le Stack et le Heap LOGO Fonctionnement du stack  Quand une fonction est appelée l’adresse de l’instruction qui suit l’appel est empilée au stack.  Les paramètres de la fonction sont empilés au stack  Les variables locales sont empilées au fur et à mesure de leur déclaration.  Les instructions de la fonctions s’exécutent.  Vue la taille limitée du stack, la déclaration de variables de grande taille peut aboutir à une surcharge. 23
  • 24. Le Stack et le Heap LOGO La surcharge du stack est appelée Stack Overflow qui signifie que la taille maximale du stack est dépassée, dans ce cas les variables locales et les paramètres sont stockés dans d’autres endroits de la mémoires ce qui aboutit à un crash. 24
  • 25. LOGO 4 Bonnes pratique pour éviter les fuites de mémoires et les crash 25
  • 26. Eviter les fuites de mémoire LOGO Pour éviter le Stack Overflow :  Eviter d’utiliser des variables locales de grande taille.  Supprimer les variables allouée : ex : void Leak() { int k; char *cp = new char('E');// cette variable est //enregistrée dans le stack delete cp; // Obligatoire }  C++ n’a pas de mécanisme pour supprimer les variables automatiquement du stack. 26
  • 27. Eviter les fuites de mémoire LOGO  Eviter les combinaisons : new - delete [] & new [] delete malloc() - delete & new - free()  Exemple : int *vector = new int[10]; ... delete vector;  Ecrire un destructeur pour les classes dont le constructeur alloue de la mémoire.  Ne jamais réallouer la mémoire avant de supprimer (cf diapo 16)  Ne pas déréférencer un pointeur nul  crash (utiliser « if (ptr != null)… ») 27
  • 28. Eviter les fuites de mémoire LOGO  On utilise les Smart Pointers ( lorsque l’objet vers lequel ils pointent est détruit, ces pointeurs ne pointent plus vers son adresse)  QPointer<QWidget> foo = new QWidget(); delete foo; delete foo;  pas de crash  Quand on recourt à l’héritage on doit s’assurer que les classes de base contiennent des destructeurs virtuels.  Déclarer des constructeurs de recopie si les objets à représenter contiennent des pointeurs (s’ils ne contiennent que des éléments simples, le compilateur génère un constructeur de recopie) 28
  • 29. LOGO 5 Optimisation du code 4 29
  • 30. Conseils pour l’optimisation du code LOGO  Eviter les boucles inutiles  for ( i = 0; i < 1000000; i++ ) Fonction1( ); for ( i = 0; i < 1000000; i++ ) Fonction2( );  for ( i = 0; i < 1000000; i++ ) { Fonction1( ); Fonction2( ); }  Si l’ordre des entiers dans une boucle n’est pas important et que le compteur n’a pas besoin d’être obligatoirement incrémenté : on peut transformer :  for ( i = 0; i < 10; i++ ) { ... } en for ( i = 10; i - - ) { ... } 30
  • 31. Conseils pour l’optimisation du code LOGO  Un switch peut être plus utile que plusieurs if..else... : Dans le bloc des ifs, même si la valeur de la variable est en fait le dernier bloc, les premiers devront être exécuté avant. Switch permet de laisser tomber cela et ne vérifie que la où c'est juste.  Minimisez l'utilisation des variables globales.  Déclarez tout (en dehors des fonctions) en static, sauf si ça doit être global  Evitez d'utiliser une fonction comme sqrt( ) dans une boucle, car les fonctions de racines carrées et autres travaillent beaucoup en mémoire. 31
  • 32. Conseils pour l’optimisation du code LOGO  Les tableau à dimension unique sont plus rapide que ceux à double dimension  La multiplication de nombres à virgules flottantes est plus rapide que la division. Utilisez plutôt val * 0.5 que val / 2. ((a / b) > c peut être remplacé par a > (c * b))  L'addition est plus rapide que la multiplication. Utilisez val + val plutôt que val * 2. (Ne pas abusez.) 32
  • 33. Conseils pour l’optimisation du code LOGO  Ne pas utiliser les méthodes virtuelle qu’en cas de réelle nécessité : l’appel des fonctions virtuelles est plus coûteux. 33
  • 34. Réusinage du code LOGO  Permet d’améliorer la lisibilité du code afin de simplifier sa maintenance et sa réutilisabilité  Eviter les appels doubles : if (string.IsNullOrEmpty(Request["location"])) url = (FacadeFactory.GetCatalog()).ValidateUrl(filter.Value, canonicalUrl); else url = (FacadeFactory.GetCatalog()).ValidateUrlByName(Request["location"], canonicalUrl); /* Peut être écrit comme suit: */ var catalog = FacadeFactory.GetCatalog(); if (string.IsNullOrEmpty(Request["location"])) url = catalog.ValidateUrl(filter.Value, canonicalUrl); else url = catalog.ValidateUrlByName(Request["location"], canonicalUrl); 34
  • 35. Réusinage du code LOGO  Simplifier les comparaisons :  if (store.Current == Stores.Starbucks || store.Current == Stores.BarnsAndNobles || store.Current == Stores.Amazon) { //do something } /* peut être écrit comme suit: */ var stores = new[]{ Stores.Starbucks, Stores.BarnsAndNobles, Stores.Amazon }; if (stores.Contains(store.Current)) { //do something } 35
  • 36. LOGO 6 Outils logiciels 4 36
  • 37. Outils logiciels LOGO ReSharper Visual Assist X(refactoring) Refactor for C++ Style cop(nommage indentation) 37
  • 38. LOGO Conclusion 4 38
  • 39. Conclusion LOGO Les bonnes pratiques de programmation permettent non seulement d’écrire un code éfficace mais aussi d’écrire un code efficient dont la lecture, la compréhension et la réutilisabilité est facile. La perfection est atteinte non pas quand n'y a plus rien à ajouter, mais quand il n'y a plus rien à retirer. 39
  • 40. Merci de votre attention Questions? LOGO

×