Réponse.

En Visual Basic, la programmation procédurale permet de structurer clairement le code grâce à la réutilisation des sous-programmes (Sub, Function) pour minimiser la duplication et améliorer la lisibilité.

Historique de la question

À l'origine, la programmation en VB s'est développée autour de l'utilisation de grands blocs de code à l'intérieur de formulaires et de modules. Cela a conduit à une duplication de la logique et a compliqué le débogage. La séparation en procédures et fonctions a constitué un passage à une architecture plus modulaire.

Problème

Les applications mal structurées contiennent du code identique à différents endroits, ce qui rend la maintenance, la correction des erreurs plus difficiles et réduit la réutilisabilité.

Solution

Utiliser des procédures (Sub) et des fonctions (Function) avec des arguments et des valeurs de retour. Une bonne pratique consiste à extraire la logique répétée dans des méthodes distinctes, en respectant le principe DRY (Don't Repeat Yourself).

Exemple de code :

' Gestionnaire appelant une fonction réutilisable
Sub btnCalculate_Click(sender As Object, e As EventArgs)
    Dim result As Double = CalculateDiscount(100, 0.2)
    MessageBox.Show($"Remise : {result}")
End Sub

' Fonction réutilisable
Function CalculateDiscount(total As Double, rate As Double) As Double
    Return total * (1 - rate)
End Function

Caractéristiques clés :

• Réutilisation du code via des méthodes et fonctions communes.
• Simplicité de la maintenance future du code.
• Décomposition claire de la logique.

Questions pièges.

Peut-on déclarer des procédures et des fonctions avec le même nom en Visual Basic si seuls les types de valeurs de retour diffèrent ?

En Visual Basic, le nom d'une procédure ou d'une fonction doit être unique dans son domaine de visibilité, et la surcharge uniquement par le type de valeur de retour n'est pas possible. La surcharge est uniquement supportée par les signatures des paramètres.

Exemple de code :

' INCORRECT - erreur de compilation
Function GetValue() As Integer
    Return 1
End Function

Function GetValue() As String
    Return "Test"
End Function

Si un paramètre est déclaré comme Optionnel, est-il obligatoire de spécifier une valeur par défaut ?

Oui, pour les paramètres Optionnels, il est obligatoire de définir une valeur par défaut.

Exemple de code :

Function Sum(a As Integer, Optional b As Integer = 0) As Integer
    Return a + b
End Function

Peut-on utiliser Exit Sub/Exit Function pour sortir non seulement de la procédure actuelle, mais aussi des méthodes parente ?

Non, Exit Sub/Exit Function ne sort que de la procédure actuelle. Pour contrôler le flux au niveau des procédures externes, il faut utiliser des structures de contrôle de flux comme If/Return ou la gestion des exceptions.

Erreurs typiques et anti-patterns

• Duplication de logique métier au lieu de l'extraire dans des méthodes distinctes.
• Utilisation de procédures avec un grand nombre de paramètres et une lisibilité faible.
• Utilisation incorrecte de variables globales pour échanger des données entre les procédures.

Exemple de la vie réelle

Cas négatif

Dans un projet, le calcul de la remise est réalisé par un fragment de code distinct dans plusieurs gestionnaires d'événements sur différents formulaires. Lors de la modification de la formule, il faut corriger le code à chaque endroit manuellement.

Avantages :

• Résultat rapide lors du prototypage.

Inconvénients :

• Difficile à maintenir.
• Risque d'erreurs lors des modifications.
• Plus de code à maintenir.

Cas positif

Extraction du calcul de la remise dans une fonction distincte CalculateDiscount et utilisation de celle-ci à tous les endroits nécessaires via des appels.

Avantages :

• Modification facile en un seul endroit.
• Moins de probabilité d'erreurs.
• Amélioration de la lisibilité et testabilité.

Inconvénients :

• nécessite du temps pour la décomposition et la structuration du code.