Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

Vous n'avez pas encore de compte Developpez.com ? L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

Developpez.com

Accueil

Choisissez la catégorie, puis la rubrique :

logo

Accueil :
- éditorial
- charte d'utilisation
- aide
- diaporama
- contributeurs
Rechercher :
 
recherche avancée...
Naviguer :
- par tri alphabéthique :
0-* A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
- par thèmes :
  . Business Intelligence
  . Conception
  . Culture
  . Économie
  . Généralités
  . Gestion de projet
  . Infographie
  . Internet
  . Langages
  . Sécurité
  . Systèmes
  . Télécom
  . Théorie
Contribuer :
- nouvelle définition
- commenter une définition
Partenariat :
- faire un lien
- contact
Statistiques :
- 3079 définitions
- 329 ressources

Définition de lois de Kernighan

fr  np.
Préceptes de bonne programmation de Brian Kernighan, l'un des auteurs du langage de programmation C :

- Exprimez simplement et directement ce que vous avez à l'esprit. (Il n'est point besoin d'une formulation compliquée pour réaliser une tâche simple.)

- Programmer clairement, ne faites pas le malin. (Chercher à écrire un code complexe pour faire croire qu'on est un gourou est le meilleur moyen d'échouer.)

- Recourir de préférence à une expression logique plutôt qu'à une expression conditionnelle. (Les booléens valent mieux qu'une structure de contrôle.)

- Il n'est point de recours abusif aux parenthèses. (Il vaut mieux lever toute ambiguïté grâce au parenthésage que de se tromper. L'excès de précautions n'est pas un mal.)

- A chaque test doit correspondre une alternative. (Tout if doit être accompagné de son else et tout switch doit avoir son default car l'utilisateur a le droit d'être informé de la raison de la non réalisation d'une tâche.)

- Utilisez les bonnes fonctions d'un langage, pas les mauvaises.

- Captez la régularité dans le flux de contrôle, l'irrégularité dans le flux de données. (Une saisie trop régulière est suspecte : un robot tente-t-il d'utiliser le programme ? Une irrégularité dans les données peu dénoter un problème d'intégrité.)

- Chaque fonction ou module devrait se contenter de remplir correctement une et une seule tâche. (La modularité est maître.)

- Les commentaires doivent s'accorder avec le code. (Tout changement dans le code doit être répercuté dans la documentation et les commentaires doivent être tenus à jour.)

- Ne répétez pas le code dans vos commentaires. Chaque commentaire doit être utile. (Les commentaires sont une expliquation en français du code. Et ils sont nécessaires à la relecture.)

- Ne pas commenter un code mauvais, il faut le réécrire. (Documenter permet de s'apercevoir de certaines erreurs d'analyse, ne pas hésiter à refaire le code qui pose problème.)

- Utiliser des constantes symboliques au lieu de nombres "magiques". (Toute valeur dans le code doit être portée par une constante, la maintenance n'en sera que plus facile.)

- Méfiez-vous des effets de bord et de l'ordre d'évaluation des opérateurs. (Parenthèsez au maximum.)

- Les macros ne sont pas des fonctions. (Un code propre, modulaire et portable est la règle.)

- Assurez-vous que la saisie d'informations ne peut pas dépasser les limites de votre programme. (Attention aux buffer overflow.)

- Programmez sur la défensive. (Toujours controler les données de l'utilisateur.)
lois de Kernighanterme -> VAprogrammation (CTX)
Auteur : Hugo Etiévant (cyberzoide) - Le CyberZoïde Qui Frétille
Permalien : Définition de lois de Kernighan du dictionnaire Langages
Date d'ajout : 02/05/2006 Date de dernière mise à jour : 09/05/2006

Envoyer à un ami Imprimer Ajouter aux favoris Dénoncer un abus
Noter cette définition :
logo

Contacter le responsable de la rubrique Accueil

Partenaire : Hébergement Web