Programmation (JBI010) Norme de codage (v1.

0)

Le code de conduite léger suivant garantit un Python facilement lisible et modifiable.

code source. Cette norme est basée sur [1], où des règles beaucoup plus détaillées, moti-
Des observations et des exemples peuvent être trouvés. Les notes ci-dessous expliquent ces règles.

Cohérence 1. Soyez cohérent lorsque vous utilisez la liberté que cette norme laisse.

Indentation 2. Indentez toujours systématiquement un multiple de 4 espaces. N'utilisez jamais le caractère TAB.
caractères dans le code source. (Laissez votre éditeur remplacer la touche TAB par des espaces. Jupyter
Le carnet le fait déjà)
Longueur de ligne 3. Limitez toujours la longueur des lignes à un maximum de 80 caractères. (Définissez une marge à droite.)

Lignes vides 4. Utilisez toujours une ligne vide avant et après les cas suivants :

•fonctions (Semaine 3)
Les cours (Semaine 5) sont entourés de 2 lignes blanches au lieu.
Les lignes blanches peuvent être utilisées pour séparer des groupes d'instructions ou d'assignations à
améliorer la lisibilité

Espacement 1 5. Ne jamais écrire d'espace avant et toujours écrire un espace après les suivants
items (unlessat line end):

•, :
Espacement 2 6. Toujours écrire un espace avant et après les éléments suivants (sauf à la ligne)
début/fin) :

•keywords:if for whileetc.

•opérateurs binaires (sauf.):= + - * / % == != < > <= >= && || etc.
Commentaires 7. Toujours expliquer chaque déclaration de variable dans un commentaire.

Docstring 8. Spécifiez toujours chaque entité publique (classes et fonctions) dans un commentaire docstring.

Nommer 1 Les noms de variables, de fonctions et de classes doivent toujours refléter l'utilisation plutôt que l'implémentation.

Nommer 2 10. Utilisez toujours les conventions de nommage associées pour différents objets :

Utilisez des majuscules pour les noms de classes

•utiliser_des_minuscules_avec_les_mots_séparés_par_des_soulignements_pour_les_fonctions_et
noms de variables
UTILISEZ_DES_MAJUSCULES_AVEC_DES_MOTS_SÉPARÉS_PAR_UNS_SOUCIS_POUR_LE_NOM_DE_CON
stants
Indices de type 11. Ajoutez toujours des indications de type aux fonctions en utilisant ':' ou '→'.

c
2010–2019, [Link] 1/5
 Programmation (JBI010) Norme de codage (v1.0)

MAL 1 defRUN() C
: 'est la partie qui fait des choses
2 x1=saisir()Ces lignes sauvegardent l'entrée
3 y1=input()
4 x2=input()
5 y2=input()
6 x3=entrée()
7 y3=entrée()
8 si((x1>x2)ou(y1<y2)):Cette partie vérifie si le rectangle est bien défini
9 imprimer(erreur
10 elif(((x3>=x1)et(x3<=x2))et((y3<=y1)et(y3>=y2))):#Ce chèque
11 imprimer(à l'intérieur
12

13 sinon :
14 imprimer(en dehors) #Si le point n'est pas dans le rectangle, il est en dehors

BON 1 defis_dans_un_rectangle(coord_gauche:float, coord_droite:float,

2 bottom_coord:float, top_coord:float,
3 point_x:float, point_y:float) -> None:
4 Vérifie si un point donné est à l'intérieur d'un rectangle donné
5

6 Imprime soit 'erreur', 'à l'intérieur' ou 'à l'extérieur'

7 """
8 Si le rectangle est mal défini, imprimez 'erreur'
9 si((left_coord > right_coord) ou (bottom_coord < top_coord)) :
10 imprimer("error")
11 Si le point est dans le rectangle, imprimez 'à l'intérieur'.
12 elif(point_x >= left_coord) et (point_x <= right_coord) et
13 (point_y <= top_coord) et (point_y >= bottom_coord) :
14 imprimer(à l'intérieur
15 Sinon, le point est en dehors du rectangle, imprimez 'dehors'.
16 sinon :
17 imprimer(dehors
18

19 Obtenez le rectangle et l'entrée du point

20 rectangle_left =input(’Left side coordinate of the rectangle = ’)
21 rectangle_right =input(’Right side coordinate of the rectangle = ’)
22 rectangle_bottom =input(’Bottom coordinate of the rectangle = ’)
23 rectangle_top =input(’Top coordinate of the rectangle = ’)
24 point_X =input(’X coordinate of the point = ’)
25 point_Y =input(’Y coordinate of the point = ’)
26

27 # Exécutez la fonction avec les paramètres donnés

28 vérifier_rectangle(gauche_rectangle, droite_rectangle, bas_rectangle,
29 rectangle_haut, point_X, point_Y)
c
2010–2019, [Link] 2/5
 Programmation (JBI010) Coding Standard (v1.0)

Remarques
Un code source bien organisé est important pour plusieurs raisons.

Le compilateur peut ne pas se soucier de cela, mais le code source est également lu par d'autres :
développeurs, examinateurs, mainteneurs, enseignants, correcteurs, . . .

C'est un moyen important de prévenir les défauts.

•Cela facilite la localisation des défauts, tant par l'auteur que par d'autres.

Voici quelques informations supplémentaires sur chacune des règles.

Cohérence 1. La constance joue surtout un rôle dans le placement des accolades d'ouverture.
les placer à la fin de la ligne avec l'instruction de contrôle, ou au
début d'une ligne par eux-mêmes directement en dessous de l'état contrôlant -
Un avantage de ce dernier style est que les accolades d'ouverture et de fermeture sont
aligné verticalement. Un inconvénient est que cela prend plus d'espace vertical.

Indentation 2. L'indentation fournit des indices visuels sur la structure de contenance (imbriquement).
Une ou deux espaces d'indentation ne fournissent pas suffisamment de repères visuels.
Certaines normes prescrivent de s'indentation par des multiples de trois espaces (parce que
cela interfère avec les caractères TAB, décourageant ainsi encore plus.
Indenter de plus de quatre espaces est un gâchis et laisse moins de place en vue
de la limite de longueur de ligne (voir aussi la note suivante).

Longueur de ligne [Link] écran peut afficher des lignes plus longues, mais vous n'êtes pas le seul à lire le
code source. De plus, les longues lignes sont difficiles à analyser. Voir aussi la note suivante.

Évitez les lignes longues en introduisant des variables, des méthodes ou des classes auxiliaires (par exemple,
pour regrouper plusieurs paramètres).
S'il est inévitable d'avoir une longue ligne, cassez-la à un endroit approprié et continuez.
sur la ligne suivante.
Bien sûr, la longueur des lignes de code générées peut ne pas être sous votre contrôle.

Lignes vides 4. Les lignes vides fournissent des indices visuels sur le regroupement, à un niveau intermédiaire
(voir également les deux notes suivantes). En plus des situations mentionnées dans la Règle 4, il est
il est bon de délimiter les groupes de déclarations connexes par des lignes vides ; par exemple,
déclarations de variables de boucle nécessaires, la boucle et la finalisation de la boucle. Par
la manière, ce regroupement peut également être rendu explicite par des crochets, définissant un
bloc, peut-être avec ses propres variables locales.
Évitez les longs blocs d'instructions en introduisant des méthodes auxiliaires (Supplément)
fonctions).
Espacement 1 5. L'espacement fournit également des indices visuels sur le regroupement, mais à un niveau inférieur que

c
2010–2019, [Link] 3/5
 Programmation (JBI010) Norme de codage (v1.0)

lignes vides (voir la note précédente ; voir aussi la note suivante). Cette règle concerne
ponctuation.
Les virgules sont utilisées pour séparer les éléments dans les listes, comme les paramètres (à la fois formels.

et actuels), et expressions.
Il ne devrait jamais y avoir plusieurs deux-points sur la même ligne.

Espacement 2 6. L'espacement améliore la lisibilité, notamment lors du balayage rapide du code source.
plutôt que de le lire lentement en détail.
La lisibilité des expressions peut être améliorée par un usage approprié de
parenthèses, et variables et fonctions auxiliaires.

Commentaires 7. Les variables sont introduites pour un but spécifique. Le nom de la variable
devrait refléter cet objectif. Cependant, un nom ne devrait pas non plus être trop long.
De plus, l'objectif implique généralement des relations avec d'autres éléments de
le programme. Un commentaire rend cela explicite. Pour éviter de devoir passer du temps à
effort pour décider d'inclure un commentaire ou non, la règle est simplement de
fournissez-le toujours.
Il est également bon de fournir des commentaires sur des affirmations non évidentes.
Cependant, il existe des commentaires superflus. Ne commentez pas.
l'évidence.

Docstring 8. Les entités publiques sont typiquement des classes, des méthodes, des fonctions et des (non-locales) con-
Les entités publiques peuvent être utilisées n'importe où dans un programme. Par conséquent, leur
l'utilisation devrait être bien documentée. Les commentaires au format docstring ont deux avantages
sur des commentaires ordinaires (non-docstring) :

Ils prennent en charge des fonctionnalités supplémentaires, telles que les balises, pour structurer la documentation.
tion.
•Ils peuvent être extraits du code source et présentés séparément,
comme un document avec des références croisées.

De nombreux environnements de développement intégrés (IDE) Python proposent des ajouts

bénéfices nationaux lors de l'utilisation des commentaires docstring. Les commentaires docstring peuvent être
identifié par les triples guillemets et s'étend souvent sur plusieurs lignes
””” Ceci est une chaîne de documentation ”””

Naming 9. Les variables, les fonctions et les classes sont introduites pour un but spécifique.
le nom de la variable doit refléter cet objectif. Mais les noms peuvent aussi donner
indices visuels pour l'utilisation. Utiliser différents types de noms aide à rapidement
interpréter le code.
Les noms de classe doivent toujours commencer par une lettre majuscule afin que les classes soient faciles à
il a été repéré. Tous les mots supplémentaires dans le nom de la classe doivent également commencer

avec une majuscule. C'est la convention CapWords (par ex. Kitten-

Boutique)

c
2010–2019, [Link] 4/5
 Programmation (JBI010) Standard de Codage (v1.0)

Les fonctions et les variables doivent être écrites en minuscules avec des mots séparés
séparés par des traits de soulignement. Pour les fonctions, il est également permis d'utiliser le camel-

cas, où le premier mot commence par une lettre minuscule mais les autres
les mots commencent par une majuscule (par exemple, boutiqueDeChaton), mais tout en minuscules est pré-

préféré.
• Les constantes sont écrites en majuscules pour rappeler aux développeurs que ces valeurs
ne devrait pas et ne sera pas changé (Ex. MAXVALUE).
Conseils de type 10. Les fonctions n'autorisent souvent qu'un type spécifique de variables à être données comme paramètre.
paramètres. Comme le code est souvent créé dans des groupes (grands), d'autres peuvent ne pas
savoir quels types de variables sont autorisés dans une fonction et lesquels ne le sont pas.
Les indications de type aident les développeurs afin qu'ils n'aient pas à rechercher soigneusement à travers

(complexes) fonctions pour pouvoir utiliser ces fonctions.

En ajoutant des annotations de type ...

•à la fonction, un codeur peut rapidement savoir quel type la fonction retourne

et utilisez la fonction sans exactement savoir quel pourrait être le résultat
sois.
Exemple :
defexemple(var1) -> TYPE:

•aux paramètres, quelqu'un peut rapidement voir quels types les variables
devrait être, avant qu'ils ne puissent utiliser la fonction avec succès.
Le seul paramètre qui n'a pas besoin d'une indication de type est le paramètre 'self'.
This parameter is standard for methods but does not need an explicit
indice de type. (Ceci est utilisé dans les classes).

Exemple :
defexemple(var1: TYPE):

Remarque : Il est entendu que Python pourrait mettre à jour à un moment donné pour changer de type.
indices du volontaire au obligatoire.

References
Guide de style pour le code Python. PEP 8, 2001.
[Link]

c
2010–2019, [Link] 5/5