Conventions syntaxiques : Différence entre versions

Version du 15 juillet 2014 à 10:16

introduction

Cette page à pour vocation de rassembler les différentes règles de rédaction du programme ESM. Étant donnée le nombre important de collaborateurs attendu pour l'élaboration de ce programme il convient de s'accorder au préalable sur une même façon de coder. Le choix du langage de programmation c'est tourné vers le python.

Les conventions adoptées qui suivent sont très largement inspirées des recommandations issue du site de python. Ces recommandations sont proposées au travers de PEP (Python Enhancement Proposal : proposition d'amélioration de Python). Pour toute zone de flou, n'hésitez pas à vous y référer et à enrichir ce wiki.

Conseil généraux

Traduction de la PEP20, issue d'openclassroom.

• Le beau est préférable au laid.

• L'explicite est préférable à l'implicite.

• Le simple est préférable au complexe.

• Le complexe est préférable au compliqué.

• Le plat est préférable à l'imbriqué. Moins littéralement, du code trop imbriqué (par exemple une boucle imbriquée dans une boucle imbriquée dans une boucle…) est plus difficile à lire.

• L'aéré est préférable au compact.

• La lisibilité compte.

• Les cas particuliers ne sont pas suffisamment particuliers pour casser la règle;

• Même si l'aspect pratique doit prendre le pas sur la pureté. Moins littéralement, il est difficile de faire un code à la fois fonctionnel et « pur ».

• Les erreurs ne devraient jamais passer silencieusement;

• à moins qu'elles n'aient été explicitement réduites au silence.

• En cas d'ambiguïté, résistez à la tentation de deviner.

• Il devrait exister une (et de préférence une seule) manière évidente de procéder;

• Même si cette manière n'est pas forcément évidente au premier abord, à moins que vous ne soyez Néerlandais ; % il faudrait peut-être indiquer que c'est une blague ?

• Maintenant est préférable à jamais.

• Mais jamais est parfois préférable à immédiatement.

• Si la mise en œuvre est difficile à expliquer, c'est une mauvaise idée.

• Si la mise en œuvre est facile à expliquer, ce peut être une bonne idée ;

• Les espaces de noms sont une très bonne idée (faisons-en plus !).

Convention de nommage

Variables, fonctions et méthodes

Le nom est entièrement écrit en minuscules et les mots sont séparés par des signes soulignés (_).

nom_de_fonction.

Constantes

Les constantes doivent être écrites entièrement en majuscules, les mots étant séparés par un signe souligné (_).

NOM_DE_MA_CONSTANTE.

Arguments

Modules

Classes

==

Nom de fonction

Il faudra aussi adopter une convention de nommage en plus d'une meilleure lisibilité, d'une collaboration plus efficace entre les programmeurs, il apparait qu'un intérêt peut être la vérification simplifié du programme en vue d'une meilleure sécurité voir EAL [1] et [2].

Le nom des fonctions devra:

• Etre explicite
• Etre en anglais
• Les espaces seront remplacer par des underscore "_"
• Aucune majuscule ne devra apparaitre

index esm

• [3] conseil openclassroom

• [4] doc site de python