Bonnes pratiques pour le développement
Un article de Haypo.
(Différences entre les versions)
| Version du 19 janvier 2007 à 14:44 (modifier) Haypo (Discuter | Contributions) m (Bonnes pratique pour le développement déplacé vers Bonnes pratiques pour le développement) ← Différence précédente |
Version actuelle (28 mai 2008 à 15:01) (modifier) (défaire) Haypo (Discuter | Contributions) |
||
| (2 révisions intermédiaires masquées) | |||
| Ligne 1 : | Ligne 1 : | ||
| [[Catégorie:Programmation web]] | [[Catégorie:Programmation web]] | ||
| {{Retour|Programmation|Retour à la programmation}} | {{Retour|Programmation|Retour à la programmation}} | ||
| + | |||
| + | [[Image:Wtfm.jpg|framed|right|The only valid measurement of code quality: WTFs/minute]] | ||
| + | [[Image:Bug3.jpg|thumbnail|400px|Bug vs Feature]] | ||
| Cette page liste des bonnes pratiques pour le développement de logiciel. La première version est issue d'[https://linuxfr.org/~pap_furax/23503.html un journal linuxfr de ''Papa Furax'']. | Cette page liste des bonnes pratiques pour le développement de logiciel. La première version est issue d'[https://linuxfr.org/~pap_furax/23503.html un journal linuxfr de ''Papa Furax'']. | ||
| Ligne 9 : | Ligne 12 : | ||
| ** Générer la documentation à partir du code source | ** Générer la documentation à partir du code source | ||
| ** etc. | ** etc. | ||
| - | * Activer la détection de tous les avertissements (ex: avec gcc, utiliser -Wall -Wextra | + | * Activer la détection de tous les avertissements (ex: avec gcc, utiliser -Wall -Wextra voire -Werror) et surtout les corriger |
| ** Voir également utiliser des outils dédiés : splint et Valgrind (langage C), pylint et pychecker (Python), etc. | ** Voir également utiliser des outils dédiés : splint et Valgrind (langage C), pylint et pychecker (Python), etc. | ||
| * Indenter le code source | * Indenter le code source | ||
Version actuelle
The only valid measurement of code quality: WTFs/minute
Cette page liste des bonnes pratiques pour le développement de logiciel. La première version est issue d'un journal linuxfr de Papa Furax.
- Utiliser un gestionnaire de version du code source (ex: Subversion)
- Automatiser un maximum de chose, exemples :
- Lancer automatiquement des tests (« tests unitaires »)
- Générer la documentation à partir du code source
- etc.
- Activer la détection de tous les avertissements (ex: avec gcc, utiliser -Wall -Wextra voire -Werror) et surtout les corriger
- Voir également utiliser des outils dédiés : splint et Valgrind (langage C), pylint et pychecker (Python), etc.
- Indenter le code source
- Ne pas écrire de fonction de plus de 300 lignes
- Si une fonction est plus longue, on peut forcément la redécouper
- Limiter le nombre d'arguments d'une fonction (ex: 5 maximum)
- Écrire de la documentation
- Écrire des tests (tests unitaires, tests fonctionnels, fuzzing, etc.)
- Utiliser des conventions de : nommage des variables, fonctions, classes et constantes, langue du code source (l'anglais pour un logiciel libre, si vous souhaitez recevoir des contributions...)
- Éviter la redondance : factoriser le code, réutiliser du code, recherche les bibliothèques existantes avant de réinventer la roue
Autres bonnes pratiques :
- Utiliser un outil de gestion des bogues
