Convertir du WLangage en Go : méthode, équivalences et pièges

Go est une cible de choix pour les applications WinDev orientées services, outils internes ou backends : compilé, statiquement typé, déployable en binaire unique sans runtime. La syntaxe est plus stricte que le WLangage, mais la traduction est directe une fois qu’on a compris deux idiomes fondamentaux : l’absence d’exceptions et les valeurs de retour multiples.

Prérequis : exporter le code en format texte

Enregistrez vos projets en format texte dans WinDev (option de compatibilité Git). Vous obtenez des fichiers WLangage lisibles, base idéale pour une conversion assistée par IA. Notre guide de préparation : migrer depuis WinDev.

Équivalences de base WLangage → Go

L’idiome Go le plus dépaysant : la gestion d’erreur

WLangage utilise les exceptions et les procédures d’erreur (QUAND EXCEPTION DANS). Go n’a pas d’exceptions : chaque fonction qui peut échouer retourne une valeur d’erreur en second paramètre. C’est verbeux mais explicite — et c’est ce qui rend le code Go si facile à tracer en production.

QUAND EXCEPTION DANS
  OuvreConnexion(sConnexion)
  HExécuteRequêteSQL(reqSQL)
FAIRE
  Erreur("Connexion échouée : " + ErreurInfo())
FIN

db, err := sql.Open("postgres", dsn)
if err != nil {
    return fmt.Errorf("connexion échouée : %w", err)
}
_, err = db.Exec(query)
if err != nil {
    return fmt.Errorf("requête échouée : %w", err)
}

Accès aux données : de HFSQL à database/sql

Le parcours de fichier HFSQL — l’idiome central du WLangage — se traduit en requête SQL explicite via le package standard database/sql, ou via un ORM comme GORM pour les projets CRUD denses.

POUR TOUT Commande
  OÙ DateCmd >= DateDébut
  ET Statut = "Validée"
  Total += Commande.MontantHT
FIN

rows, err := db.Query(`
  SELECT MontantHT FROM Commande
  WHERE DateCmd >= $1 AND Statut = 'Validée'`, dateDebut)
if err != nil { return err }
defer rows.Close()
for rows.Next() {
    var montant float64
    rows.Scan(&montant)
    total += montant
}

Pièges classiques de la conversion WLangage → Go

• Pas d’exceptions — des erreurs retournées — chaque appel susceptible d’échouer doit être suivi d’un if err != nil. Les conversions automatiques par IA oublient parfois ces vérifications : la revue humaine est indispensable.
• Typage strict sans conversions implicites — WLangage convertit silencieusement un réel en entier. Go refuse : var x int = 3.14 est une erreur de compilation.
• Variables déclarées mais non utilisées — Go refuse de compiler si une variable locale est déclarée mais jamais lue. Le code WLangage en est souvent plein.
• Le contexte HFSQL implicite — position courante, filtres actifs, HLitSuivant : tout devient des requêtes SQL explicites.
• Variables globales de projet — en Go, elles deviennent des paramètres passés explicitement ou des dépendances injectées via struct.
• Pas d’héritage — Go n’a pas d’héritage : on compose des structs. La traduction n’est pas mécanique et demande une réflexion architecturale.

Go comme cible pour les services extraits de WinDev. Go brille particulièrement quand l’application WinDev est en réalité un outil interne, un service de traitement ou un backend d’API. Pour les applications de gestion CRUD avec IHM riche, C# / Blazor ou Python / Django restent souvent plus adaptés.

Concurrence : goroutines vs WLangage

WLangage gère la concurrence via les threads et tâches asynchrones (LanceTâche, MutexVerrou). Go expose un modèle plus simple avec les goroutines et les channels, qui se prête naturellement à la parallélisation de traitements HFSQL lourds.

var wg sync.WaitGroup
for _, id := range ids {
    wg.Add(1)
    go func(fid int) {
        defer wg.Done()
        traiterFacture(fid)
    }(id)
}
wg.Wait()

Un projet de conversion WLangage → Go ? Audit gratuit — contact@wxit.fr.