Utiliser les identificateurs, la syntaxe et les variables

Effectué

Avant de pouvoir commencer à travailler avec des variables et des fonctions, vous devez d’abord connaître certains concepts importants. Les identificateurs, la syntaxe et les variables sont des notions centrales des langages de programmation tels qu’AL.

Un identificateur désigne le nom d’un élément de programmation, tandis qu’une variable détermine l’emplacement de stockage des données en mémoire. Vous pouvez utiliser un identificateur pour attribuer un nom à votre variable afin de pouvoir l’utiliser.

La syntaxe décrit les règles grammaticales régissant l’utilisation de ces identificateurs. La syntaxe des identificateurs est déterminée par le langage d’application et certaines meilleures pratiques.

Quelques règles grammaticales définissent l’utilisation des identificateurs. Au sein d’un objet, tous les identificateurs doivent être uniques. Par conséquent, dans un objet, vous ne pouvez pas déclarer deux variables ayant le même identificateur (ou nom).

Lorsque vous définissez une variable à l’aide d’un identificateur, le premier caractère est de préférence un trait de soulignement ou une lettre. Lorsque vous utilisez un caractère spécial ou un espace dans l’identificateur, vous devez placer ce dernier entre des guillemets doubles.

Bien que le langage d’application ne respecte pas la casse, il ne distingue pas les lettres majuscules et minuscules dans les identificateurs. Nous vous recommandons de créer des identificateurs à l’aide de PascalCase. PascalCase impose de commencer le nom de la variable par une lettre majuscule. Si votre nom est un mot composé, le deuxième mot doit également commencer par une lettre majuscule. Par exemple, dans le cas d’une variable destinée à stocker le nom d’un client, vous pouvez utiliser CustomerName, qui est un exemple de notation PascalCase.

Avant de travailler avec des variables, vous devez les déclarer, ce qui signifie que les variables doivent :

  • avoir un identificateur,

  • avoir une étendue,

  • avoir un type de données,

  • être initialisées.

Votre variable doit également avoir une étendue qui définit là où vous pouvez y accéder et l’utiliser.

Une variable peut être définie avec une étendue globale ou locale. Si vous définissez votre variable avec une étendue globale, elle sera alors disponible dans tout l’objet. De ce fait, sur chaque déclencheur, cette variable sera disponible partout où vous souhaitez écrire des instructions de code. Lorsque l’étendue est locale, vous ne pouvez accéder à cette variable que dans le déclencheur spécifique de la procédure où elle a été déclarée.

Exemple de variables d’étendue globale et locale.

Dans l’exemple précédent, la variable Counter est déclarée avec une étendue globale et peut être utilisée dans chaque déclencheur et fonction de la table MyTable. La variable CustomerName est définie dans le déclencheur OnInsert ; par conséquent, elle a une étendue locale. La variable ne peut être utilisée que dans ce déclencheur et ne peut pas être appelée à partir d’un autre déclencheur. Définir toutes vos variables avec une étendue globale peut être plus facile, mais ces variables pourront ensuite être utilisées dans chaque déclencheur. La variable pourra alors être modifiée dans chaque déclencheur, ce qui risque de générer des résultats indésirables ou inattendus. Par conséquent, lorsque vous déclarez des variables, choisissez avec soin la définition de l’étendue.

Il existe également des variables définies par le système, qui sont définies et gérées automatiquement par ce dernier. Leur étendue est également définie par le système. Les variables Rec et xRec sont des exemples de variables définies par le système. Rec donne accès à l’enregistrement en cours, tandis que xRec donne accès à l’enregistrement précédent (par exemple, avant une mise à jour).

Une variable est toujours associée à un certain type de données. Il peut s’agir notamment d’un entier, d’un texte, d’un code, d’une date ou d’une option. Lorsqu’une variable est créée en mémoire, elle est initialisée, ce qui signifie qu’elle obtient une valeur de départ par défaut avant que vous ne lui affectiez une valeur. Cette valeur par défaut dépend du type de données de la variable.

Pour les variables associées à un type de données numérique, une valeur nulle est utilisée pour l’initialisation. Les variables String sont initialisées avec une chaîne vide. La valeur par défaut d’une variable booléenne est False.

Jusqu’à récemment, chaque variable devait être déclarée sur sa propre ligne. Dans les objets plus volumineux, cela conduisait à des pages de déclarations de variables, même si la plupart d’entre elles étaient du même type.

Pour réduire le défilement, améliorer la lisibilité et faciliter la visualisation et la déclaration de types apparentés, il est désormais possible d’ajouter plusieurs déclarations de variables du même type sur une seule ligne.

Déclarez plusieurs variables du même type dans la même ligne, en utilisant une virgule pour séparer les noms de variables.

Par exemple :


var
        myInt, nextInt, thirdInt : Integer;
        isValid, doCheck : Boolean;

Variables protégées

Le mot-clé protected peut être utilisé pour rendre les variables accessibles entre les tables et les extensions de table et entre les pages et les extensions de page.

Si vous voulez exposer seulement certaines variables comme étant protégées, vous devez créer deux sections de déclarations de var. Voir la syntaxe ci-dessous.


protected var
        myInt: Integer; // protected var

var
        myLocalInt: Integer; // local var

L’exemple ci-dessous illustre comment déclarer et utiliser une variable protégée.


page 50100 MyPage
{
    SourceTable = Customer;
    PageType = Card;

    layout
    {
        area(Content)
        {
            group(General)
            {
                field(Name; Name)
                {
                    ApplicationArea = All;
                }
            }
            group(Advanced)
            {
                Visible = ShowBalance;

                field(Balance; Balance)
                {
                    ApplicationArea = All;
                }
            }
        }
    }

    protected var
        [InDataSet]
        ShowBalance: Boolean;
}

pageextension 50101 MyPageExt extends MyPage
{
    layout
    {
        addlast(Content)
        {
            group(MoreBalance)
            {
                Visible = ShowBalance; // ShowBalance from MyPage

                field("Balance (LCY)"; "Balance (LCY)")
                {
                    ApplicationArea = All;
                }
            }
        }

    }

    actions
    {
        addlast(Navigation)
        {
            action(ToggleBalance)
            {
                ApplicationArea = All;
                trigger OnAction()
                begin
                    ShowBalance := not ShowBalance; // Toggle ShowBalance from MyPage.
                end;
            }
        }
    }
}

Directives pour placer le code AL

Nous recommandons les directives suivantes pour le code AL :

  • En général, vous écrivez le code dans des codeunits plutôt que sur l’objet sur lequel il opère. Cela favorise une conception propre et permet de réutiliser le code. Elle permet également de renforcer la sécurité. Par exemple, les utilisateurs n’ont généralement pas d’accès direct aux tables contenant des données sensibles, telles que la table Écriture comptable, et ils n’ont pas non plus la permission de modifier les objets.

  • Si vous placez le code qui s’applique à la comptabilité dans un codeunit, donnez à ce dernier l’accès à la table et donnez à l’utilisateur l’autorisation d’exécuter ce codeunit. De cette façon vous ne compromettez pas la sécurité de la table et l’utilisateur peut y accéder.

  • Si vous devez placer du code sur un objet plutôt que dans un codeunit, placez ce code aussi près que possible de l’objet auquel il s’applique. Par exemple, placez le code qui modifie les enregistrements dans les déclencheurs des champs de table.

Réutilisation du code

La réutilisation du code rend le développement des applications à la fois plus rapide et plus facile. Plus important encore, si vous organisez votre code AL comme suggéré, vos applications seront moins sujettes aux erreurs. En centralisant le code, vous ne créerez pas involontairement des incohérences en effectuant le même calcul à plusieurs endroits, par exemple dans plusieurs déclencheurs dont l’expression source est le même champ de table. Si vous devez modifier le code, vous risquez soit d’oublier certains de ces déclencheurs, soit de commettre une erreur en modifiant l’un d’entre eux.