Qualité logicielle - présentation du code

Tous les sites qui traitent des automatismes industriels.
Laurent
Générateur de blocs fonctions
Générateur de blocs fonctions
Messages : 104
Inscription : 20 oct. 2015, 11:16
Localisation : Oise et Ile-de-France / France

Qualité logicielle - présentation du code

Message par Laurent »

Bonjour,

dans le cadre d'une refonte de nos standards de programmation, on doit traiter d'un aspect particulier : les principes de présentation du code.

On s'inspire des recommandations PLCOpen, qui proposent quelques principes en la matière :
  • En Ladder, les bobines doivent être alignées à droite des réseaux,
  • on ne place pas d'éléments de test après une bobine,
  • on déconseille l'emploi des expressions ST en Ladder et en FBD.
En langage ST, on a déjà une base, traitant du style d'indentation du code, de l'emploi des espaces avant et après les opérateurs, la casse de caractères pour les noms de variables, les constantes, les fonctions / DFB...

Et vous, quelles bonnes pratiques appliquez-vous dans la présentation du code
  • en langage Ladder,
  • en langage FBD,
  • en langage SFC
Je cherche les bonnes idées en matière de positionnement des blocs, les connexions entre le blocs, le placement des commentaires, etc.

Merci pour vos retours !
Laurent
Avatar de l’utilisateur
lerieur
Générateur de blocs fonctions
Générateur de blocs fonctions
Messages : 148
Inscription : 27 nov. 2015, 22:04

Re: Qualité logicielle - présentation du code

Message par lerieur »

Pour ma part, même si rien n'est formalisé, il y a des règles que j'applique.
Tout d'abord, ce sont les commentaires.
Ne pas hésiter à mettre des détails.
C'est tout bête mais ça peut être précieux.
Genre, indiquer dans le commentaire d'une entrée sa signification à 1 ou à 0, par exemple "présence pièce sur convoyeur A (1=pièce présente).

On met des commentaires sur les variables, mais aussi sur les sections et les réseaux.
Quand on peut mettre des commentaires en clair, il ne faut pas se priver.
Les abréviations c'est bien, mais ça peut rendre le programme difficile à relire pour quelqu'un d'autre.

Pour l'écriture du programme, c'est l'homogénéité.
Par exemple, sur une sortie TOR, la commande en mode manuel en haut du réseau, en dessous la commande automatique, et cela pour toutes les sorties.

Pour le ladder, je privilégie la règle d'une seule sortie par ligne.
Je ne suis pas fan des SET/RESET non plus, plus difficile de retrouver la cause d'un dysfonctionnement quand plusieurs équations peuvent en être la cause.
Optimisation du code: on évite les doublons d'instructions. Quand une condition est commune à des branches en parallèle, on la met une fois, devant et on diverge vers les différentes branches juste après.

Pour le langage FBD, j'essaye de conserver une présentation assez claire, un rangement ordonné des blocs pour faciliter la lecture du programme.
La théorie, c’est quand on sait tout et que rien ne fonctionne. La pratique, c’est quand tout fonctionne et que personne ne sait pourquoi. Ici, nous avons réuni théorie et pratique : rien ne fonctionne ... et personne ne sait pourquoi !
Répondre