Question bonnes pratiques du codage...? Le sujet est résolu

Y compris Power BI, Power Query et toute autre question en lien avec Excel
Avatar du membre
galopin01
Passionné d'Excel
Passionné d'Excel
Messages : 5'620
Appréciations reçues : 68
Inscrit le : 18 septembre 2008
Version d'Excel : 2010 / 2016
Téléchargements : Mes applications

Message par galopin01 » 13 août 2018, 10:56

Ausecour a écrit :
13 août 2018, 10:16
Je recommande tout de même de renommer les contrôles en gardant ComboBox devant par exemple, c'est vrai que c'est plus pratique ensuite quand tu codes pour pouvoir savoir qu'est ce que tu manipules.
... Quand on comence a être atteint d’Alzheimer peut-être... si on ne peut pas se souvenir que tb sont les Textbox, cbo les Combos et cmd pour les buttons.
Pour ma part comme je déteste le noms à rallonge qui ne permettent pas de voir la totalité d'une ligne dans un écran, je m’abstiens de participer quand c'est codé comme ça !
A+
VBA pour Excel? Pensez D'ABORD en EXCEL avant de penser en VBA...
j
jmd
Fanatique d'Excel
Fanatique d'Excel
Messages : 10'033
Appréciations reçues : 200
Inscrit le : 8 décembre 2007
Version d'Excel : 365 + PowerBI

Message par jmd » 13 août 2018, 10:59

c'est sans doute ce que voulait dire Ausecours :wink:
mais il n'est pas rentré dans ce "détail"

si on met CMD pour bouton, c'est bien, mais il faut un tuto commun à tous.
au fait, en cmd ou CMD :mrgreen:
Apprenez les fonctions d'Excel.
Exemple "Mettre sous forme de tableau", TCD, "Récupérer des données".
Apprendre les fonctionnalités "récentes".
Avatar du membre
Ausecour
Membre impliqué
Membre impliqué
Messages : 2'394
Appréciations reçues : 261
Inscrit le : 31 mai 2018
Version d'Excel : 2010 FR, 2013 FR

Message par Ausecour » 13 août 2018, 11:03

galopin01 a écrit :
13 août 2018, 10:56
Ausecour a écrit :
13 août 2018, 10:16
Je recommande tout de même de renommer les contrôles en gardant ComboBox devant par exemple, c'est vrai que c'est plus pratique ensuite quand tu codes pour pouvoir savoir qu'est ce que tu manipules.
... Quand on comence a être atteint d’Alzheimer peut-être... si on ne peut pas se souvenir que tb sont les Textbox, cbo les Combos et cmd pour les buttons.
Pour ma part comme je déteste le noms à rallonge qui ne permettent pas de voir la totalité d'une ligne dans un écran, je m’abstiens de participer quand c'est codé comme ça !
A+
Personnellement je prends ce que me donne Excel pour les noms, je me contente juste de rajouter un peu de texte pour rendre le nom du contrôle plus clair, si ça ne tient pas en largeur sur l'écran je fais un coup de "_" dans la ligne à un moment jugé utile :)

Je préfère également déclarer mes variables de façon lisible en mettant as string, as double, etc plutôt que les % et autres caractères.
Plus un sujet a un titre précis, des explications claires, et un fichier Excel bien préparé, plus il a de chances d'avoir une réponse qui répond au besoin, mettez toutes les chances de votre côté :bien:
"100% des gagnants auront tenté leur chance" :trfl:
M
MFerrand
Fanatique d'Excel
Fanatique d'Excel
Messages : 17'203
Appréciations reçues : 445
Inscrit le : 20 juillet 2015
Version d'Excel : 2010 FR

Message par MFerrand » 13 août 2018, 12:30

Bonjour,

Si je puis faire un petit complément personnalisé, qui porterait plutôt sur ce en quoi j'aurais tendance à déroger au type de convention que tu cites (et qu'il est en tout état de cause bon de connaître). Si d'ailleurs on regarde un lot de procédures d'origines diverses, respectant plus ou moins ces conventions, il sera rare que l'on ne trouve pas des éléments plus personnalisés qui signent en quelque sorte un style d'écriture de code... Lorsque je lis certaines macros citées par tel ou tel demandeur, dans beaucoup de cas (et c'est croissant dans la mesure où l'on se cotoie...) je n'ai pas besoin de chercher à savoir qui l'a écrite au départ, le style parle, et éventuellement si elle a été modifiée par la suite (rupture de style)...

Pour ce qui est de la lecture, le facteur déterminant de lisibilité demeure l'indentation, assortie de l'organisation des procédures dans les modules.
Par indentation j'entends très précisément : déclaration de procédure à la marge et retrait systématique d'une tabulation du code de la procédure, seules restent à la marge les étiquettes de branchement (que VBA ramène d'ailleurs automatiquement à cet emplacement) et que l'on distinguera donc au premier coup d'oeil s'il y en a. J'admets la variante consistant à laisser à la marge les déclarations de variables (bien qu'elle me gêne parfois un peu) dès lors qu'elle interviennent comme prévu toutes en début de procédure, avant tout code exécutable. On obtient donc un alignement de base en retrait d'une tabulation, à partir duquel d'autres retrait mettront en évidence le code placé à l'intérieur d'instructions composées (type With... End With, For... Next, If... [ElseIf]... [Else]... End If, Select Case... End Select, etc.).
Pas de ligne sautée interrompant le mouvement de l'oeil. Pas de commentaires, ralentissant la lecture, sauf à titre de balises découpant des parties distinctes de code.
Par contre une ligne sautée entre procédures dans le module est indispensable pour qu'on puisse les distinguer.

Là l'ordre conventionnel est : Déclarations, Procédures Function, Procédures Sub. Pour les déclarations, il y a intérêt à le respecter car certaines ne fonctionneront pas si non situées en tête de module. Si Procédures Property, je les place à la suite des déclarations dans l'ordre Property Get, Property Let, Property Set.
Pour les modules spécifiques de documents (feuilles, classeurs, userforms), je considère qu'il est le plus sage de laisser VBA placer les procédures d'évènements, c'est ainsi qu'on les retrouvera le plus vite. Et si l'on ajoute d'autres procédures, les placer en tête de Module à la suite des déclarations, zone répertoriée sous le nom de (General) dans ces modules.

Si en 25 ans je n'ai pas trop varié dans la façon d'écrire et organiser le code, parce que les premiers modèles qui m'ont inspiré respectaient globalement ces règles, la pratique et l'expérience lors de la reprise de code écrit antérieurement m'ont conduit à des ajustements pour tenter d'obtenir la situation me permettant de travailler le plus efficacement...
Je n'oserais prétendre que la situation qui me paraît la meilleure en ce qui me concerne doit valoir pour tout le monde ! Cependant, dans la mesure où elle s'est bâtie sur des règles conventionnelles que je n'ai pas inventées et qui demeurent au coeur de mes modalités de travail depuis mes débuts, il me semble que cela tend à valider l'intérêt de respecter quelques règles de base, et les essayer devrait permettre de se rendre compte si elles permettent de mieux travailler sur du code, plus efficacement et plus vite...

Pour ce qui est des variables, je prendrais un peu plus de distance avec les conventions citées, pour deux raisons. La première est qu'une fois nommée une variable, on va souvent l'utiliser pas mal de fois dans le code, donc l'écrire, et plus un nom est long plus cela prendra de temps à l'écrire maintes fois. Je suis donc partisan de noms courts (comme de façon générale de toute méthode permettant de moins écrire sans toutefois nuire à la compréhension immédiate).
La seconde est qu'il y a un lien avec le contexte d'utilisation, et la compréhension relative aux noms donnés n'est pas indépendante d'une variable à l'autre mais forme un système dans lequel la compréhension résulte tout autant de l'interdépendance des noms donnés.
Et dans la mesure où au-delà de 3 caractères, je commence à trouver qu'un nom de variable est long, je n'applique pas de préfixage des variables (2 ou 3 caractères en plus !) (ce qui ne vaut toutefois pas pour les modules de Classe, où l'on est hors contexte utilisateur, et où l'identification de la classe plaide en faveur du respect de règles plus rigoureuses), mais respecte certaines règles personnelles assez souples mais qui dans un contexte donné d'utilisation ne me semblent pas nuire à une compréhension immédiate.
Exemples : mes variables numériques Integer ou Long (NB- je n'utilise jamais Byte car ne pouvait être déclaré dans la première version de VBA (VBA4) pour Excel, et comme les tests faits ont montré qu'elle était particulièrement peu rapide, cela n'incite pas à l'utiliser...) sont le plus souvent à un caractère (lettre toujours minuscule), parfois à 2 (2e lettre en Majuscule établissant éventuellement un lien entre deux variables, ou une lettre répétée marquant un lien d'utilisation avec la variable portant cette lettre) ; utilisation préférentielle de certaines lettres selon la désignation : a, m, j ,s pour un ensemble année, mois, jour, semaine, k utilisé selon le cas en Integer pour un numéro de colonne, en String pour un caractère, en Variant pour une clé de dico...

Je ne vais pas poursuivre plus avant, mais il apparaît qu'un lien signficatif de désignation peut être parfaitement établi avec des noms très courts, tout aussi bien qu'avec des noms nettement plus longs, et je dois dire qu'ayant à l'occasion travaillé sur du code semblablement personnalisé mais sur des bases différentes des miennes, on parvient à s'assimiler assez rapidement l'économie du système et on s'y meut ensuite parfaitement à l'aise...

En espérant ne pas m'être trop longuement étendu... :wink:
Bonne journée.

edit avant de lâcher, vu le nombre de post intervenus... ;;)
Là où je déroge vraiment à ce qui paraît être un consensus (quasi donc) général, ce sont les commentaires !
Les commentaires ne sont jamais suffisants (même quand leur volume dépasse largement le volume du code), pour fournir toutes les explications nécessaires, et en ce qui me concerne ça m'empêche vraiment de lire le code !
Ce qu'on trouve le plus souvent c'est un paraphrasage censé indiquer la signification de la ligne, l'alternative, c'est d'apprendre VBA..., car de plus, s'il y a une subtilité elle a toute chance de ne pas être identifiée par le commentaire afférent ! Un exemple que j'ai eu vu de ce genre de choses : un demandeur n'arrivant pas à interpréter une ligne pourtant commentée, dont le commentaire ne faisait qu'indiquer ce que faisait la ligne, ce qui était d'ailleurs évident et se passait aisément de commentaires, seulement pour la lire (et l'interpréter), s'agissant d'une ligne de calcul, il fallait savoir que comportant une expression booléenne dans le calcul, celle-ci allait renvoyer -1 si True... Une fois l'explication fournie, hors commentaire, le demandeur n'avait plus de difficulté à interpréter le calcul !
Bref ! Je ne les trouve utiles que comme balises dans certaines procédures, sous forme d'un mot ou d'une expression aussi courte que possible, qui permet d'aller directement à cet emplacement...
Si je dois reprendre un code ancien fait par moi (je mettais quelques commentaires à mes débuts), je sais que je ne ferai pas l'économie d'une analyse dès lors que le code est un peu complexe et repose sur de multiples procédures, pour retrouver les centres de gravité de l'ensemble.
Les commentaires ne m'ont jamais rendu service, c'est pourquoi je m'en abstiens désormais, et les quelques fois (rares) où j'émets une procédure commentée à l'usage d'un demandeur (à sa demande), si je dois la lire à nouveau quelques temps après, je suis obligé de supprimer les commentaires pour y parvenir !
Je précise toutefois que je ne me trouve pas avare d'explications lorsqu'on m'en demande, je les fournis à part, et elles dépassent toujours largement le volume de code objet de l'explication.

Cordialement.
Répondre Sujet précédentSujet suivant
  • Sujets similaires
    Réponses
    Vues
    Dernier message