v4.5
SanityCheck est maintenant carbonisé pour fonctionner sous MacOS X. Il reste toutefois utilisable sous les systèmes Mac 8.6 et 9.xx si CabonLib 1.6 est installé.
La compatibilité avec les changements effectués au sein de la gestion des menus de 4D 2003 est assuré.
La vérification des nouvelles structures de 4D 2003 est opérationnelle.
Support des plugins ".4CX" et ".4DX" dans le même dossier.
Contrôle amélioré des variables non initialisées.
Gestion des alias améliorée.
Ensembles de "caractères parasites" (plusieurs ensembles possibles désormais).
Bascule optimisée des groupes d'éléments de rapports (onglet Rapport du dialogue des préférences).
Positionnement des fenêtres enregistré.
Navigation rapide au sein du logiciel (touches Tab et Esc).
Messages d'aide sous MacOS X.

Analyse

SanityCheck analyse environ 400 types différents de problèmes / solutions:
o vérification de syntaxe
o vérification des fichiers de structure endommagés
o vérification des fichiers de ressources (dossiers 4DX)
o vérification des propriétés des PICTs pour repérer les images endommagées
o vérification des références croisées des ressources ET objets
o vérification de tous les objets principaux de votre fichier 4D.

Fonctionnalités propres aux composants

o vérification et analyse des composants
o liste complète des composants avec leurs éléments respectifs de composition, disponible dans le menu Spécial
o modèle disponible dans l'explorateur SanityCheck, permettant l'affichage détaillé de la ressource de type "mod4"
o détection des dommages éventuels d'un composant
o détection de la compression d'objets non-composants (détection de l'encryptage/compression incorrect des objets).

Externes SanityCheck

o supporte désormais les externes (format propre à SanityCheck). Cette API a été créée pour commencer à répondre à l'épineuse question des conventions d'écritures (noms de variables, d'objets) dans 4D :
* API régulièrement mise à jour
* API supportant les noms d'objets : Analyse des noms d'objets
* VariableNamer, une simple externe SanityCheck sera mise à jour avec l'API
* VariableNamer vérifie seulement les noms de variables, cependant, tous les noms d'objets (tables, formulaires, etc.) sont accessibles via l'API.

Respect des dossiers Mac4DX et Win4DX des dossiers "système"

o la version 4 de SanityCheck supporte les externes situées dans les dossiers "système" ou dans "Library:Applications support:4D" (sous MacOS X).

Recherche dans les commentaires

o support de la recherche sur les commentaires via l'explorateur

Vérification des paramètres d'appel

o vérification du nombre de paramètres passés entre la méthode d'appel et la méthode appellée.
La méthode "COMPILER_" de définition des méthodes est aussi analysée par rapport aux appels rencontrés de ces méthodes.

Vérification des variables non typées / en double

o détectiion des variables déclarées et inutilisées, ainsi que des variables définies plusieurs fois.

Détection des objets sans feuille de style

o les objets ne faisant référence à aucune feuille de style sont détectés, très utile lors du développement d'une base de données multi-plateformes car il devient aisé d'obtenir la liste des objets n'utilisant pas de feuille de style, ayant généralement pour conséquence des effets visuels indésirables

Affichage des éléments non supportés

o le fichier de log de SanityCheck affiche maintenant les options “désactivées” de la session, utile pour se rappeler quels éléments étaient désactivés pour une session donnée.

Détection de la longueur limite des variables de formulaires

o Note Technique (http://www.4d.com/support/tips00-395.html) de Tim Tonooka, Août 2000, stipulant qu'il existe une limite à 30 caractères pour les noms de variables de formulaires
o détection des variables à 31 caractères par SanityCheck à partir de la V4

Autres implémentations mineures

* détection des “erreurs” mentionnées par 4D Tools quand un formulaire d'entrée ou de sortie n'est pas sélectionné. Ce n'est pas forcément une erreur, mais 4D Tools le considère en tant que tel, aussi SanityCheck en fait état.
* détection des ":" manquants sur les instructions “Au cas ou”
* détection des méthodes manquantes pour: EXECUTER SUR SERVEUR, EXECUTER SUR CLIENT, APPELER SUR ERREUR, APPELER SUR EVENEMENT, NOUVEAU PROCESS, APPELER SUR A PROPOS.

Réparations

SanityCheck répare votre fichier de structure (toutes versions natives Macintosh et Windows). Ces réparations sont automatiques si elles sont sélectionnées, vous pouvez aussi effectuer vos propres réparations avec des modèles. Pour plus d'informations, référez-vous au chapître "Définir les préférences de SanityCheck".

Plus particulièrement, les éléments suivants sont réparés :

o appel erroné à une méthode base (Sur démarrage, etc.)
o énumération erronée pour un champ
o référence erronée à une méthode table (trigger)
o un champ de sous-table pointe vers la mauvaise sous-table
o une sous-table n'a pas de champ parent
o formulaires orphelins
o numéro erroné de modèle de formulaire
o nom erroné de modèle de formulaire
o le modèle de formulaire n'a pas de données
o référence formulaire erronée dans une méthode (méthode formulaire ou objet)
o nombre d'énumérations erronées
o nom d'une énumération erronée
o pointeur vers une énumération erronée (la liste n'existe pas)
o nom de bulle d'aide erroné
o pointeur vers données de bulle d'aide erronées (la bulle d'aide n'existe pas)
o pointeur vers une méthode erronée (le nom de méthode existe, mais aucune méthode n'existe)
o objets non liés à une table
o nombre d'images erronées
o pointeur vers image erronée ou image endommagée (effacement de l'image)
o zone de mots de passe fortement endommagée
o fonction permettant de détruire complètement les mots de passe, supprimant ainsi tous les problèmes de mots de passe

Effacement des mots de passe

Vous pouvez maintenant effacer complètement vos mots de passe et groupes de 4D. À n'utiliser qu'en cas de problèmes très sérieux rencontrés dans la zone des mots de passe et avec précautions. Pour plus d'informations référez-vous au chapître Effacer le système de mots de passe.

Modèles de mots de passe

Vous pouvez maintenant modifier les données internes de vos mots de passe avec SanityCheck, utile lorsque quelque chose est endommagé et génère un comportement anormal de 4D. Pour plus d'informations, voir le chapitre Utilisation du modèle de mots de passe.

Interface moderne

Nouvelle apparence Platinium

Icônes interactives sur la fenêtre principale

La zone est analysée si l'on clique dessus, sinon elle est évitée. Ceci est bien sûr interactif, vous pouvez changer en cours de fonctionnement.

SanityCheck vérifie maintenant le Bitmap de votre fichier de structure. Cela permet d'intercepter les problèmes latents.

Ajout d'un navigateur

SanityCheck inclut une interface puissante utilisable pour explorer les "entrailles" de votre fichier de structure:
o effacement d'objets (soyez attentif en utilisant cette fonction)
o visualisation en hexadécimal
o visualisation de certains objets (vérification de CC4D, TP4D, FI4D, TF4D)
o liens hypertextes vers d'autres méthodes, dictionnaire de données, etc.

Pour plus d'informations, voir le chapitre Comment utiliser le navigateur de SanityCheck.

L'explorateur

SanityCheck inclut un puissant outil de références croisées semblable à 4D Insider pour explorer le fichier de structure:
o visualisation instantanée du code ou d'informations sur la structure
o recherche sur les données croisées
o les références croisées du fichier de structure sont déterminées lors de l'analyse
o l’analyse avec les références croisées est plus lente de 15% à 30% (pourcentage variable) que l'exécution normale de SanityCheck
o l'analyse avec les références croisées nécessite plus de mémoire que sans (environ 100Ko de mémoire supplémentaire par Mo de structure)
o l'analyse avec les références croisées permettra d'intégrer de nouvelles fonctions dans le futur

Pour plus d'informations, voir le chapitre Comment utiliser l'explorateur SanityCheck.

Fichier Log hypertexte

Le fichier de Log de SanityCheck inclut des références hypertextes vers de nombreux éléments reportés, ce qui permet de passer aux procédures et de voir les erreurs dans le code.

Paramétrages améliorés

o conservation par base
o interactif – les changements effectués pendant l'analyse se répercutent sur l'analyse en cours (seulement si vous enregistrez les paramétrages)
o interface sur une page unique
o les codes ASCII des caractères parasites sont visibles si l'écran est agrandi
o déplacement des éléments reportés d'une liste vers une autre
o fenêtre de paramétrage redimensionnable pour voir davantage d'éléments reportés à l'écran

Préférences

Effacer la liste des derniers fichiers.

Nouveaux éléments reportés

SanityCheck v4.5 reporte maintenant de nouveaux éléments. Pour la liste complète, référez-vous au chapitre Éléments reportés.

Voici quelques-uns des nouveaux éléments spécialement intéressants :

o ajout d'un code erreur pour les points-virgules oubliés dans : CHERCHER([Fichier];&[Fichier]Champ)
o recherche des divisions par une constante de valeur 0
o génération d'une erreur de syntaxe pour : APPLIQUER A SELECTION([WIP];i=1)
o génération d'une erreur de syntaxe pour : si(i:=1)
o champs non indexés dans les CHERCHER ou TRIER
o détection des bulles d'aide, énumérations, images, formulaires, modèles de formulaires orphelins
o détection des modèles de formulaires endommagés
o détection des barres de menus améliorées (incluant l'affichage des références aux STR#)
o détection des bitmaps endommagés
o détection détaillée de l'endommagement des mots de passe (déterminer le problème, le résoudre, avant que le client ne le fasse)
o détection du typage de constante erronée
o détection des formulaires 4D v6 endommagés
o analyse des méthodes base (Sur démarrage, etc.)
o analyse des feuilles de style
o vérification des noms de variables
o analyse des retypages éventuels de variables
o mesure de la complexité des méthodes (échelle McCabe) **
o analyse de la portée des variables **
o analyse de la durée de vie des variables **
o vérification des paramètres d'appel aux méthodes
o analyse des composants
o détection des objets compressés / encryptés n'appartenant à aucun composant

Echelle de complexité McCabe

Ne serait-il pas intéressant de savoir automatiquement où, dans tout de votre code, vous êtes le plus susceptible d'avoir des anomalies ?

La complexité de McCabe est un algorithme très simple qui peut être appliqué à n'importe quel langage de programmation pour identifier rapidement des zones de "complexité" en votre code. Il est fort probable que du code complexe est plus susceptible d'avoir des anomalies que du code moins complexe.

Le concept est très simple: ajoutez simplement tous les "aiguillages" que votre méthode peut contenir (par exemple, chaque "si" est un embranchement dans le code, qui génère un nouvel "aiguillage"). Le nombre résultant est la complexité. Bien que ceci semble presque trop simple pour être utile, vous serez étonnés de constater comment il peut être employé pour identifier très rapidement des sous-programmes compliqués.

L'algorithme est également très simple. Vous ajoutez simplement les points de décision:

1 Commencez par une complexité de 1 (la "racine" de votre méthode)

2 Pour chaque "Si", "Tant que", "Boucle", "Repeter" et ":" (élément d'un "Au cas ou"), la complexité de la méthode est incrémentée de 1 (c'est un nouvel "aiguillage" potentiel les traitements du code).

3 Chaque "ET" ou "OU" dans le cas d'un "Si", "Tant que", "Boucle", "Repeter" et ":" ajoute également 1à la complexité (chaque OU ou ET est un "aiguillage" différent dans le code, influant sur le résultat de cette comparaison).

Additionnez tout cela et vous obtenez un nombre. De nombreuses possibilités s'offrent à vous en manipulant ce nombre (divisez-le par le nombre de lignes, par exemple) ou bien d'autres opérations à tenter de manière à le minimiser.

SanityCheck calcule seulement ce nombre car il est très significatif en effectuant une analyse relativement pertinente.

Avertissements avec le code 4D

Quelques modèles de programmation dans 4D font une utilisation intensive du "Au cas ou", et si vous avez de longues méthodes de "Au cas ou", par exemple pour l'analyse de chaînes de caractères de code d'erreur, vous pouvez terminer vers le haut avec "une complexité élevée" pour cette méthode. C'est quand-même correct. Le but de l'analyse de complexité est d'apporter une aide à la localisation des zones "à risque". Employez la complexité de McCabe pour identifier ces portions de code de manière à considérer si vous voulez ou non restructurer votre code.

Comment rendre son code moins complexe ?

La réponse simple est de factoriser votre code. Par la factorisation, vous créez plusieurs méthodes pour accomplir la même tâche que la méthode initiale. Habituellement, la méthode initiale devient une "boucle-maîtresse" qui appelle les nouvelles méthodes pour accomplir certaines des "tâches secondaires" de la méthode initiale devenue appelante.

En choisissant les endroits corrects pour créer de nouvelles méthodes vous constaterez que le code est beaucoup plus lisible (moins complexe) et plus facile à maintenir.

Il existe beaucoup d'ouvrages traitant du sujet de la complexité du code et de sa factorisation. "Code complete" (Steve McConnell, de Microsoft Press) en est un excellent exemple.

Portée d'une variable

Une autre manière de déterminer la complexité d'une méthode consiste à compter le nombre de lignes de code entre chaque référence à une variable.

Examinons le code de l'exemple 1 :

Exemple 1 :
$nbrTables:=1;
Tant que (RechercheFichierSuivant($nom))
{
...action...
...action..
...action...
...action...
...action...
$nbrTables:=$nbrTables+1
}

La portée de la variable "$nbrTables" est de 8. Il est à noter qu'il n'y aucune raison particulière à l'incrémentation de la variable "$nbrTables" en fin de boucle.

Restructurons notre boucle de manière à obtenir :

Exemple 2 :
$nbrTables:=1;
Tant que (RechercheFichierSuivant($nom))
{
$nbrTables:=$nbrTables+1
...action...
...action..
...action...
...action...
...action...
}
La portée de la variable "$nbrTables" descend à 3.

Ce que nous pouvons surtout remarquer ici, c'est la relation directe qui existe entre les nombres générés (8 et 3) et la lisibilité du code

Les références à la variable "$nbrTables" sont maintenant regroupées au même endroit du code, ce qui en simplifie la compréhension.

Durée de vie d'une variable

La durée de vie vous indique l'envergure de la première référence de la variable à la dernière référence de la variable. En d'autres termes, il vous indique la "durée de vie" de la variable dans la méthode.

Comme dans les exemples ci-dessus, on peut facilement voir pourquoi il est avantageux de réduire ce nombre, car il tendra à "regrouper" vos variables ensemble et, de fait, à faciliter la lecture (ainsi que la mise à jour) de votre code.

Un avertissement et un conseil simple

Quand vous restructurez simplement votre code pour réduire la complexité, la portée ou la durée de vie d'une variable, vous devez faire très attention à ne pas changer la fonctionnalité du code.

C'est une bonne raison pour utiliser votre outil d'analyse de code (SanityCheck dans le cas présent) pendant le développement, de manière à prendre de bonnes habitudes au plus tôt.