-5- Wiki, Création de Projets :
Pourquoi utiliser des normes ?
Raisons :
Il y a plusieurs raisons pour lesquelles il est important d’établir et utiliser des normes de codage.
Et bien qu’elles prennent plus d’importance lorsqu’on travaille en équipe, il est quand même intéressant de les mettre en place lorsqu’on travaille seul.
Voici les principales raisons qui font que l’utilisation de règles de codage est essentiel lors du développement d’un projet.
Une meilleure lisibilité du code :
En effet, appliquer ces règles permet d’écrire, et donc de pouvoir lire, du code plus facilement.
Ce qui découle de cette première raison, c’est une meilleure maintenabilité.
Un code plus lisible, plus commenté, est bien plus facile à modifier, en cas de bugs ou d’ajout de nouvelles caractéristiques.
C’est un gain de temps et d’énergie :
Un respect des spécificités du langage utilisé.
Lorsque des bonnes pratiques sont établies, elles doivent respecter les spécificités du langage avec lequel vous codez.
Donc, suivre ces bonnes pratiques vous permettra de moins faire d’erreurs lors de l’écriture dudit code.
Une meilleure gestion des performances :
Les conventions de codage devraient également être pensées de manière à mieux gérer les ressources physiques d’une machine.
que ça soit au niveau du temps de chargement que des ressources demandées.
Ce sont les principales raisons pour lesquels on devrait appliquer des normes de codage.
Conventions de codage :
Voyons quelques-unes de ces conventions.
Quelques règles qui devraient être utilisées partout et pour tout projet informatique.
L’organisation des fichiers et l’arborescence du projet :
Il est important, dès le commencement d’un projet, de bien réfléchir et définir une arborescence propre.
C’est-à-dire, une organisation des fichiers qui soit adaptée au projet.
Typiquement, lorsqu’on débute dans le développement, on a créé souvent tous les fichiers dans le même répertoire.
Or, il est important de bien séparer les fichiers qui ont des utilités différentes.
Créer des dossiers du genre :
- images :
- font :
- sons :
- modules :
- styles : pour stocker des fichiers de style type CSS.

Cette liste n’est pas complète, on peut y ajouter d'autres.
Mais vous avez compris le principe : le but est ici d’éviter d’avoir des dizaines de fichiers dans le même répertoire.
Le nommage des fichiers :
De même, il convient de nommer correctement ces fichiers.
Un des principes qu’on retrouve, c’est de nommer ces fichiers du même nom qu’on y nomme ce qui est défini.
Par exemple, pour une classe Automobile, on nommera le fichier Autmobile.extension.
Pour un service NetworkService, on appellera le fichier NetworkService.extension.
C’est une règle simple mais importante, car elle permet de comprendre l’utilité d’un fichier rien qu’en regardant son nom.
Le nommage des classes, variables, fonctions, etc. :
Si on doit faire attention à la façon dont on nomme ces fichiers, il est encore plus important de faire attention à la façon dont on nomme ce qui s’y trouve :
classes, fonctions, variables, etc.
Nommage : - Pour une classe, on utilise du camelCase en commençant avec une majuscule : User ;
- Pour une fonction, on utilise du camelCase en commençant avec une minuscule : connectUser ;
- Idem pour une variable : connectedUser ;
- Une constante devrait s’écrire uniquement en majuscule : USER_ID.
Incise : Ne pas oublier de différentier variables globales privées et variables globales public et de mentionner le type de variables.
Pour les variables locales, c'est vous qui voyez en fonction de la taille (nombre de ligne) de vos procédures, mais votre code sera plus facile à lire avec le type de variable mentionné devant le nom de la variable.
Rappel : Convention de Nommageexemple : $sConnectUser, variable globale Private de type String
sConnectUser, variable globale Public de type String
Il y a d’autres règles, mais globalement, ce sont les plus importantes.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
| PUBLIC CONST ENDED AS INTEGER = 6 PUBLIC CONST ERROR AS INTEGER = 7
PUBLIC sText1 AS STRING '<-------------------------------' text 1 à afficher PUBLIC sText2 AS STRING '<-------------------------------' text 2 à afficher
PUBLIC iDesign AS INTEGER '<-------------------------------' indice des Design PUBLIC iDrap AS INTEGER '<-------------------------------' indice des options d'affichage
PUBLIC bTrotteuse AS BOOLEAN '<----------------------------' trotteuse ou non PUBLIC bAuto AS BOOLEAN '<-------------------------------' changement auto de fond d'horloge ou non
PUBLIC hLock AS Stream '<----------------------------------' fichier de verrouillage du démarrage PUBLIC hSon AS Sound '<------------------------------------' le son de l'alarme
PRIVATE $sSigne AS STRING '<------------------------------' signe des opérations
PRIVATE $iSigne AS INTEGER '<------------------------------' décompte des signes
PRIVATE $fNombre AS FLOAT '<------------------------------' nombre affiché
|
Bien sûr, ce n'est pas à la déclaration de vos variables que le problème de lecture, se pose mais bien lors de la lecture de votre code surtout si celui-ci fait quinze pages ; et alors on est content de savoir ce que cette variable, est, et pourquoi, elle est là dans cette partie du code.
Pour vous même, dans six mois vous aurez tout oublié et serez content d'avoir un fil conducteur pour lire votre code.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
| PUBLIC FUNCTION getActiveNetworkInterface() AS STRING
' Procedure to check the Active Network Cards
DIM tmpNIF AS String[] DIM tmpActive, tmpString AS STRING DIM iterator AS INTEGER DIM tmpFile AS File
'get the interface directories tmpNIF = Dir("/sys/class/net")
'check each folder's oper file to see if the interface is up and running FOR iterator = 0 TO tmpNIF.Count - 1 tmpString = "/sys/class/net" &/ tmpNIF[iterator] &/ "operstate"
'check the operational state of each interface
tmpFile = OPEN tmpString FOR INPUT
WHILE NOT Eof(tmpFile) LINE INPUT #tmpFile, tmpActive WEND
CLOSE #tmpFile
'if it's reported as up then return it's name IF tmpActive = "up" THEN RETURN tmpNIF[iterator] NEXT
END
|
L’indentation du code :
L’indentation consiste à ajouter des tabulations ou des espaces à ses lignes de code ; c’est une autre composante importante des règles de codage.
Certains utilisent les tabulations ; d’autres des espaces.
Certains préfèrent utiliser deux espaces ; d’autres quatre.
Ces règles dépendent donc de chacun.
Mais avoir un code bien indenté est essentiel à sa bonne lecture et maintenabilité.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
| SELECT CASE Second(Now) '<-------------------' Déclenchements sonneries CASE 0 SELECT CASE Minute(Now) CASE 0 IF MGlobal.bSonGong THEN FOR i = 1 TO $iHeure WAIT 1.618034 MGlobal.son(MGlobal.sGong2) NEXT ENDIF CASE 15 IF MGlobal.bSonDemi THEN FOR i = 0 TO 0 WAIT 0.618034 MGlobal.son(MGlobal.sGong2) NEXT ENDIF CASE 30 IF MGlobal.bSonDemi THEN FOR i = 0 TO 1 WAIT 0.618034 MGlobal.son(MGlobal.sGong2) NEXT ENDIF CASE 45 IF MGlobal.bSonDemi THEN FOR i = 0 TO 2 WAIT 0.618034 MGlobal.son(MGlobal.sGong2) NEXT ENDIF END SELECT END SELECT
|
Si vous lisez le code au dessus sur un téléphone portable, vous mesurerez à quel point l'indentation est essentiel à une lecture aisée.
Les commentaires :
Souvent oubliés par les développeurs débutants, les commentaires ont pourtant une importance primordiale.
Bien qu’ils n’aient aucune valeur ajoutée au niveau de l’exécution du code – d’où leur oubli – les commentaires sont essentiels à la bonne compréhension d’un morceau de code.
Sans toutefois tomber dans l’excès et commenter chaque ligne de code, il est important de mettre des commentaires pour chaque classe, fonctions, et blocs un peu complexes.
Ça sera utile non seulement pour ceux qui regarderont votre code, mais aussi pour vous-même, quand vous voudrez reprendre votre code après plusieurs semaines sans avoir travaillé dessus.
Optimisation :
Ici, on va plus parler d’optimisation que de vraie convention, mais la taille (en nombre de lignes) d’un fichier et d’une fonction ont également une importance.
On n’aime pas ouvrir un fichier JavaScript de 3000 lignes ni parcourir une fonction de 400 lignes.
Tout simplement parce que comprendre ce que fait cette fonction requiert de la lire entièrement.
Et lire 400 lignes de code sans perdre le fil, ce n’est pas simple !
Comment faire pour les réduire ? En ce qui concerne les fonctions, il est bon, lorsqu’elles deviennent trop imposantes, de les séparer en plusieurs fonctions.
Vous trouverez facilement des redondances, ou des morceaux de code exécutant des fonctions annexes, et donc bons à exporter dans de nouvelles méthodes.
Certains disent même qu’une fonction ne doit pas dépasser, en hauteur, la taille de l’écran.
En ce qui concerne les fichiers, c’est encore plus simple.
Si un fichier possède 40 ou 50 fonctions, il faut en externaliser certaines.
On trouvera facilement des points communs entre certaines méthodes, et on pourra ainsi créer des groupes de fonctions qu’on exportera.
Les parenthèses, point-virgules, etc. :
La dernière bonne pratique que nous allons aborder ici, c’est celle qui concerne l’utilisation des parenthèses, des point-virgules, sauts de ligne, etc.
Par exemple, l’utilisation d’espace avant et après une parenthèse, et le saut à la ligne à la fin d’une condition if.
Cela est totalement arbitraire.
Ou encore, l’utilisation ou non des ‘;’ dans les langages où ils ne sont pas obligatoires, comme JavaScript ou Python.
C’est encore une fois arbitraire.
En conclusion :
On a vu quelques règles essentielles à un code beau, propre et maintenable.
L’utilisation de normes de codage est importante.
Elle permet, via le respect de diverses règles, de garder un code source propre, facile à lire et optimisé.
Ce qui est essentiel, pour maintenir un projet sur le long terme et l'échanger avec d'autres.
====================
Navigation :
<-- Liens du Wiki : <--<-- Accueil du WIKI : <-- <-- Rappels de Programmation <--<-- Création de Projets <--====================
Documentation :
====================