Gambas France BETA

Connexion

Pas de compte ? Incription

Bonnes Pratiques :

-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 :







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 :


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 Nommage

exemple :

$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 :



====================