Ceci est une ancienne révision du document !
Python
Petit Rappel sur le codage en Python.
Règles générales sur le codage (PEP 20 et PEP 8)
Le rôle de la PEP 20 (PEP pour PYTHON Enhancement Proposal : proposition d'amélioration de PYTHON) est de donner des directives pour coder de la meilleure façon possible.
Énoncée sous forme d'aphorismes plus ou moins compréhensibles, cette PEP est une des briques de base pour tout programmeur PYTHON. Elle concerne cependant surtout l'aspect du code.
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é.
Du code trop imbriqué 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.
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 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 (humour : l 'inventeur du PYTHON est Néerlandais ).
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. S i 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.
Le rôle de la PEP 8 est de donner des directives claires quant à la manière même de rédiger le code. Une fois de plus, ce ne sont cependant que des conseils que vous êtes libre ou non de suivre.
Ci-dessous, une traduction française de ces conseils.
Une indentation doit équivaloir à quatre espaces ( configurez la touche tab).
Il ne faut jamais mélanger espaces et indentations dans le même code.
Une ligne ne doit excéder 79 caractères.
La définition d'une fonction, classe ou autre doit être suivie de deux sauts de lignes.
Il faut utiliser un import par package.
Ces imports doivent toujours être en début de code.
Ils doivent être répartis en trois groupes dans l'ordre suivant, séparés par un saut de ligne
Les bibliothèques standards ;
les bibliothèques tierces ;
les bibliothèques « maison ».
Toujours utiliser des chemins absolus pour l'import de modules.
Toujours utiliser un espace avant et après un opérateur.
Une seule instruction par ligne.
Règles de codage
L'ensemble des règles énoncées ci-après ne constitue en rien une obligation, mais uniquement de fortes recommandations, qui sont respectées par de nombreux programmeurs.
Le respect de ces règles de codage facilite autant le codage que la future maintenance potentielle par des tiers.
Les variables: Le nom des variables ne peut pas commencer par un chiffre. Il ne doit être constitué que de lettres minuscules et les différents mots séparés par des underscores « _ ».
Les fonctions/procédures: Les règles de nommage des fonctions et des procédures sont identiques à celles des variables.
Les propriétés et les méthodes: On utilise les mêmes règles que pour les variables.
Les modules et packages: Les noms des modules et des packages doivent être courts et constitués uniquement de lettres minuscules. De préférence, il faut éviter d'utiliser des underscores et n'avoir un nom ne tenant qu'en un mot, surtout pour les packages.
Le nom des classes: Le nom d'une classe se compose d'un ensemble de mots, collés les uns aux autres, avec la première lettre de chaque mot en majuscule. Exemple : ClassName.
Les exceptions: Les règles de nommage des exceptions suivent les mêmes règles de nommage que les classes.
Installer PIP à la main
Librairie