Développement > Utilitaires > Vérifications > Vérification des sources 

Cette fonction est réservée (et utile) aux développeurs.
Le lancement en batch est possible.

Le language de développement X3 est extrèmement flexible et permet d'exécuter du code souvent sans préjuger du type de données utilisé, en générant a posteriori des sous-programmes qui ne seront contrôlés qu'à l'exécution. Autant cette flexibilité est utile pour accroître l'efficacité et la généricité du code, autant elle a pour contrepartie la possibilité d'écrire des programmes qui ne provoqueront des erreurs qu'au moment de l'exécution.

Le but de ce traitement est de pallier cette flexibilité en détectant un certain nombre d'erreurs de programmation. En agissant ainsi en amont de la mise en service, on améliore la qualité.

Ce traitement permet de lancer diverses séries de contrôle dans un dossier :

  • vérification des sous-programmes et fonctions : elle traite principalement de l'appel de sous-programmes dans les sources (existence, nombre et cohérence des paramètres...).
  • vérification des classes [F] et [M] : elle permet principalement de vérifier l'existence des tables, écrans et champs dans les sources.
  • autres vérifications : elle permet divers contrôles dans les sources.

Les contrôles sont subdivisés en 2 parties :

  • Les erreurs : Elles sont suceptibles de générer un arrêt produit.
  • Les anomalies : Elles relèvent du non respect des normes ou d'un manque de précision pouvant induire des erreurs lors de l'éxécution du traitement.

Le traitement génère deux fichiers trace (un pour les erreurs, un pour les anomalies).
Le fichier des anomalies porte le même nom que celui des erreurs avec le suffixe W (pour Warning).

Gestion de l'écran

L'écran présente le dossier courant.

Ecran de saisie

Présentation

Saisie des paramètres souhaités

 

Champs

Les champs suivants sont présents dans cet onglet :

Bloc numéro 1

choix du dossier à traiter.
pour des questions de performances, il est recommandé de traiter le dossier courant.

Type de contrôle

  • Sous-programmes et fonctions (champ VERIFCALL)
  • Classes [F] et [M] (champ VERIFVAR)

vérification des classes [F] et [M].

ce choix permet principalement de vérifier l'existence des tables, écrans et champs dans les sources.

  • Autres (champ VERIFAUT)

autres vérifications.

ce choix permet divers contrôles dans les sources.

Critères

  • Source(s) (champ NOMSRC)

sélection d'un traitement.

sélection de tous par *, d'un seul par son nom ou de plusieurs par début*.

  • Module (champ CHXMODULE)

choix d'un module (via un écran liste)
seuls les traitements de ce module seront contrôlés

  • champ LIBMODULE

 

  • Erreur (champ CHXERREUR)

choix d'une erreur particulière (via un écran liste).
cette sélection est possible si un seul contrôle est demandé.

  • champ NUMERR

 

Tri

  • Module (champ PARMODULE)

Enchaînement par module
Cela permet d'obtenir les erreurs (et anomalies) triées par module.

Trace

  • Sur poste client (champ TRACE)

Fichier de trace.

Il est possible de l'enregistrer directement sur le poste client (case à cocher).
Son nom est modifiable dans ce cas.

 

Liste des erreurs et anomalies recherchées

vérification des sous-programmes et fonctions.

Erreurs recherchées :
  • Dbgaff trouvé.
  • Traitement inexistant.
  • Sous-programme (ou fonction) inexistant.
  • Erreur lors d'un appel par GOSUB.
  • Variable globale VAR inexistante.
  • Paramètre de type différent sur appel de Sous-programme (ou fonction).
  • Nombre de paramètres différent sur appel Sous-programme (ou fonction).
  • Goto à une étiquette située dans un autre traitement.
  • Appel d'une étiquette par un Call.
  • Etiquette inexistante.
Anomalies recherchées :
  • Fonction ayant un type d'argument non renseigné dans le dictionnaire ASUBPROG.
  • Fonction ayant un type d'argument (du End) dans le dico différent de celui du traitement.
  • le sous-programme (ou fonction) a l'argument n° N non déclaré.
  • Variable globale VAR déjà déclarée avec un type différent.
  • Sous-programme (ou fonction) avec un descriptif vide (documetation).
  • Paramètre [=VALEUR] de type différent sur appel de Sous-programme (ou fonction).
  • Paramètre de type différent entre dico et déclaration du sous-programme (ou fonction).
  • Paramètre ayant un passage par adresse/valeur différent entre dico et déclaration du sous-pro. (ou fct).
  • Nombre de paramètres différent entre dico et déclaration du sous-programme (ou fonction).
  • le sous-programme (ou fonction) a l'argument n° N qui a un nom différent lors de la définition du type.

vérification des classes [F] et [M].

Erreurs recherchées :
  • Source non référencé dans le dictionnaire des traitements.
  • Variable écran inexistante [M:ABV]CHP
  • Variable table inexistante [F:ABV]CHP
  • Variable inexistante [ABV]CHP dans les tables du LNK
  • Table non trouvée
  • Longueur d'abréviation trop longue (> 4)
Anomalies recherchées :
  • Variable inexistante [G:ABV]CHP

Autres vérifications

Erreurs recherchées :
  • Sous- prog (ou fct) fini et For sans Next
  • Sous- prog (ou fct) fini et If sans Endif
  • Sous- prog (ou fct) fini et Case sans Endcase
  • Sous- prog (ou fct) fini et While sans Wend
  • End trouvé dans une boucle For [Read]
  • Return trouvé dans une boucle For [Read]
  • Documentations de point d'entrée inexistante.
Anomalies recherchées :
  • Sous-programme (ou fonction) ne contient aucun code
  • Sous-programme (ou fonction) a un tableau en paramètre passé par valeur
  • Return trouvé dans un Sous-programme (ou fonction)
  • Message d'erreur imprécis, à compléter par : "(" + [L]COMPTEUR - num$([L]STAT) + ")".
  • #@ est une instruction obsolette
  • Instruction evalue inutile sur un dim de champ.

Balises pour masquer certaines erreurs

Certaines erreurs sont complexes à analyser, d'autres correspondent à des cas particuliers.
Pour cela, vous disposez de balises (dans les traitements) pour les masquer.
L'intérêt est de ne pas polluer les comptes rendus par de 'fausses' erreurs récurrentes.

Le but de ces balises n'est pas, par une utilisation généralisée, de masquer toutes les erreurs en quelques CHECK.
Il est de traiter les cas particuliers.


mode d'emploi :

Première phase : Analysez les sources sans placer de balise.
Relancez la vérification autant de fois que nécessaire pour obtenir le nombre d'erreurs le plus petit possible.

Deuxième phase : Placez les balises souhaitées puis analysez les sources jusqu'à obtenir le résultat souhaité (aucune erreur !).

Troisième phase : Adaptez vos balises en fonction des erreurs survenues sur d'autres traitements.
Par exemple, un source marqué comme inutilisé ne devra plus l'être si un autre traitement fait appel à un de ses sous-programmes.


précisions :

Le CHECK IGNORE_SOURCE est plutôt prévu pour ne pas contrôler un source en cours de développement (trop d'erreurs temporaires).
Le CHECK UNUSED_SOURCE est prévu pour vérifier qu'un source n'est plus utilisé. Il pourra alors être supprimé dans un second temps.
Les CHECK IGNORE_BEGIN et CHECK UNUSED_BEGIN sont faits pour cibler une partie de traitement (jusqu'au #CHECK ..._END).
Le CHECK IGNORE_WRSEQ sert à ne pas analyser les instructions Wrseq (cas des sources générateurs).

Il faut privilégier un CHECK UNUSED_SOURCE plutôt qu'un UNUSED_BEGIN (dès le début) sur un traitement :
Si un autre traitement lui fait appel (Call From), l'erreur précisera alors que le traitement appelé est marqué comme non utilisé.

Liste des différentes balises :


#CHECK FILE_DECLARE <file> [<abrev>]
Pour déclarer une table ayant été ouverte dans un autre traitement avec une abréviation non standard
Ne déclarer qu'une seule table par ligne
A placer en début de ligne (avant celles utilisant cette abréviation).

#CHECK MASK_DECLARE <masque> [<abrev>]
Pour déclarer un masque écran ayant été ouvert dans un autre traitement avec une abréviation non standard
Ne déclarer qu'une seul masque par ligne
A placer en début de ligne (avant celles utilisant cette abréviation).

#CHECK IGNORE_SOURCE
Pour ne pas analyser un source.
A placer en début de traitement

#CHECK IGNORE_BEGIN
A partir de cette ligne, les instructions suivantes du traitement ne sont pas analysées.
A placer en début de ligne (avant celles à ne pas analyser).

#CHECK IGNORE_END
Pour arrêter le CHECK IGNORE BEGIN.
A placer en début de ligne

#CHECK IGNORE_LINE
Pour ignorer une seule instruction.
A placer en fin de ligne comme un commentaire

#CHECK IGNORE_WRSEQ
A partir de cette ligne, les lignes contenant un Wrseq sont ignorées.
A placer en début de ligne

#CHECK WRSEQ_END
Pour arrêter le CHECK IGNORE_WRSEQ.
A placer en début de ligne

#CHECK UNUSED_SOURCE
Pour ne pas analyser un traitement obsolète.
A placer en début de traitement

#CHECK UNUSED_BEGIN
A partir de cette ligne, les instructions suivantes du traitement ne sont jamais analysées.
A placer en début de ligne (avant celles à ne pas analyser).

#CHECK UNUSED_END
Pour arrêter le CHECK UNUSED BEGIN.
A placer en début de ligne

#CHECK MIGRATE_SOURCE
Reconnaissance d'un traitement de migration. A partir de cette ligne, certains contrôles seront ignorés.
A placer en début de ligne (avant celles à ne pas analyser).
Erreurs masquées par ce CHECK : n° 109

Tâche batch

Cette fonction peut être lancée en batch. La tâche standard AVERIFSRC est prévue à cet effet.

Messages d'erreur

Il n'y a pas de message d'erreur autre que les messages d'erreur génériques.

Tables mises en oeuvre

SEEREFERTTO Reportez-vous à la documentation de Mise en oeuvre