Sortir d'une fonction

Une question en apparence banale, mais en pratique litigieuse, dans le Monde merveilleux de la programmation^® est celle des extrants d'une fonction, à savoir :

• Le nombre :
  • une fonction devrait-elle toujours avoir (au moins) un extrant?
  • est-il raisonnable pour une fonction d'avoir plusieurs extrants?
  • une même fonction devrait-elle contenir plusieurs points de sortie?
• Le lieu :
  • s'il existe des raisons pertinentes pour une fonction de contenir plus d'un point de sortie, quelles sont-elles?
  • s'il est recommandable pour une fonction de n'avoir qu'un seul point de sortie, alors sur quoi cette position repose-t-elle?
• La manière :
  • quand devrait-on privilégier un extrant par voie de valeur de retour et quand devrait-on privilégier d'autres mécanismes?
  • quels sont les mécanismes pour sortir d'une fonction? etc.

La liste de questions ci-dessus n'est pas exhaustive, évidemment. Ce qui suit vise à donner une meilleure compréhension de cet enjeu, incluant une perspective historique, tout en évitant un argumentaire qui serait du ressort de la croyance.

Un seul point de sortie par fonction...?

Plusieurs enseignent, ou ont enseigné, qu'il faut viser un seul point de sortie par fonction. Je suis d'ailleurs de ceux-là : c'est ce qu'on m'a appris, et c'est le principe que j'ai longtemps moussé (et que je mets encore de l'avant aujourd'hui dans bien des cas).

Cela dit, il est parfois sain de se demander d'où viennent certains principes que nous enseignons et que nous appliquons. Certains idées peuvent être valables à une époque, et être moins adaptées à une autre.

Perspective historique

Le crédo selon lequel une fonction ne devrait avoir qu'un seul point de sortie est inspiré d'un texte d'Edsger W. Dijkstra, dans Notes on structured programming, que vous pouvez lire sur http://www.cs.utexas.edu/users/EWD/ewd02xx/EWD249.PDF. Mon ami Dan Saks, un sage, m'a toutefois informé que le texte d'Edsger W. Dijkstra a été précédé de quelques années par un texte, celui-là de Corrado Böhm et Giuseppe Jacopin : Böhm, C. and Jacopin, G., Flow Diagrams, Turing Machines And Languages With Only Two Formation Rules, que vous trouverez sur http://www.cs.unibo.it/~martini/PP/bohm-jac.pdf.

Tiré de cet article :

Dans https://crivelloappendini.wordpress.com/2012/10/05/the-theorem-of-bohm-jacopini/, qui pose un regard sur ce texte, on peut d'ailleurs lire :

Informellement, à l'époque où ces textes ont été écrits, on oeuvrait à la formalisation des programmes. Dans un programme, une unité complexe (une fonction) était présentée comme composée d'unités plus simples; ces unités formaient une séquence d'opérations. Pour construire une telle séquence, chaque opération complexe devait avoir un seul point d'entrée et un seul point de sortie.

Formalisme de la programmation structurée

L'idée avancée dans ces textes est qu'il est possible de démontrer le bon fonctionnement d'un programme si celui-ci est construit à partir de séquences, d'alternatives et de répétitives, et de fonctions qui apparaissent comme des blocs complexes de ces trois éléments (et d'autres fonctions) ayant elles aussi un seul point d'entrée et un seul point de sortie.

Séquence	Alternative	Répétitive

Dans cette perspective, un programme est fait de fonctions qui constituent elles-mêmes des séquences composites :

Vous trouverez un condensé de ces idées sur https://en.wikipedia.org/wiki/Structured_program_theorem.

Intérêt de ce formalisme

L'idée de viser un seul point d'entrée et un seul point de sortie par fonction est un formalisme raisonnable, au sens où ce formalisme aide à raisonner sur le texte d'un programme structuré sur la base de sa forme. En ce sens, on pourrait tracer un parallèle avec l'enjeu (important!) de l'indentation.

TrouverPlusPetit(a,b,c)
   si a < b alors
      plusPetit ← a
   sinon
      si b < c alors
         plusPetit ← b
      sinon
         plusPetit ← c
   Retourner plusPetit

int trouver_plus_petit(int a, int b, int c) {
   int plus_petit;
   if (a < b) {
      plus_petit = a;
   } else {
      if (b < c) {
         plus_petit = b;
      } else {
         plus_petit = c;
      }
   }
   return plus_petit;
}

static int TrouverPlusPetit(int a, int b, int c)
{
   int plusPetit;
   if (a < b)
   {
      plusPetit = a;
   }
   else
   {
      if (b < c)
      {
         plusPetit = b;
      }
      else
      {
         plusPetit = c;
      }
   }
   return plusPetit;
}

Toutefois, il n'est pas toujours pratique d'exprimer des algorithmes en se restreignant à une application stricte de ce formalisme.

Je ne propose donc pas un laxisme face au principe de viser un seul point de sortie par fonction. Comme pour bien des cas de « sagesse traditionnelle » les avantages de respecter ce principe sont nombreux. Je propose d'examiner les raisons pour lesquelles il s'agit d'un principe général, pas d'un dogme.

Divergences raisonnées

Plusieurs sommités de la programmation et du génie logiciel ont tenu des discours semblables au fil des années, mais avec quelques nuances. Parmi les sommités les plus connues, on trouve entre autres Steve McConnell, dans son livre Code Complete, ou Robert C. Martin, dans son livre Clean Code (que je n'ai malheureusement pas lu encore; ce n'est qu'une question de temps). Ce dernier aurait d'ailleurs, selon Waseem Senjer, écrit ceci :

Ceci annonce une vision un peu plus pragmatique que celle à laquelle on aurait pu s'attendre, même par des tenants de code dit « de qualité ».

Viser un seul point de sortie est souvent une bonne idée. Prenons pour exemple un cas à la fois simple mais typique de situations pour lesquelles la paresse pourrait mener certaines ou certains à utiliser plusieurs points de sortie pour une même fonction, sans qu'il n'y ait de réels avantages.

bool est_pair(int n) {
   bool resultat;
   if (n % 2 == 0)
      resultat = true;
   else
      resultat = false;
   return resultat;
}

bool est_pair(int n) {
   bool resultat = false;
   if (n % 2 == 0)
      resultat = true;
   return resultat;
}

bool est_pair(int n) {
   if (n % 2 == 0)
      return true;
   else
      return false;
}

bool est_pair(int n) {
   return n % 2 == 0;
}

Visiblement, il ne faut pas voir une ouverture à la discussion sur le recours raisonné et pertinent aux multiples points de sortie dans une fonction comme une permission accordée pour s'adonner à une programmation laxe et inefficace.

Un cas intéressant pour illustrer l'intérêt de permettre le recours aux multiples points de sortie est la sortie hâtive d'une fonction dans le cas où le résultat d'un calcul est connu avant la fin du parcours d'un substrat.

// sortie hâtive (version lente et douloureuse)
template <class T, int N>
bool contains(T &&x, const T(&arr)[N]) {
   // ... inefficace
   bool result = false;
   for(int i = 0; !result && i != N; ++i)
      if (arr[i] == x)
         result = true;
   return result;
}

// sortie hâtive
template <class T, int N>
bool contains(T &&x, const T(&arr)[N]) {
   for(auto & obj : arr)
      if (obj == x)
         // nous avons notre réponse
         return true;
   return false; // pas trouvé
}

Ce cas faisait partie de l'argumentaire de Donald E. Knuth a mis de l'avant en réponse au texte d'Edsger W. Dijkstra dans Structured Programming with go to Statements, dont l'introduction contient ce qui suit :

Les caractères gras sont de moi.

Le pour et le contre

Il y a plusieurs bonnes raisons d'essayer d'en arriver à un point de sortie unique par fonction. Entre autres choses, cela peut nous épargner de vilains bogues.

#include <iostream>
#include <string_view>
using namespace std;
enum class Color { Red, Green, Blue }; 
auto f(Color c) {
   switch(c) {
   case Color::Red: return "Red"sv;
   case Color::Green: return "Green"sv;
   case Color::Blue: return "Blue"sv;
   }
} // avertissement probable (et justifié) ici
int main() {
   cout << f(Color::Green);
}

Comment régler cet irritant? Plusieurs options sont possibles, même en conservant le point de sortie unique.

enum Color { Red, Green, Blue }; 
auto f(Color c) {
   auto res = "Oops"sv;
   switch(c) {
   case Red: res = "Red"sv;
   case Green: res = "Green"sv;
   case Blue: res = "Blue"sv;
   }
   return res;
}

enum class Color { Red, Green, Blue }; 
auto f(Color c) {
   optional<string_view> res; // initialisé à vide
   switch(c) {
   case Color::Red: res = "Red"sv;
   case Color::Green: res = "Green"sv;
   case Color::Blue: res = "Blue"sv;
   }
   return res;
}

enum class Color { Red, Green, Blue }; 
auto f(Color c) {
   string_view res; // initialisé en tant que chaîne vide
   switch(c) {
   case Color::Red: res = "Red"sv;
   case Color::Green: res = "Green"sv;
   case Color::Blue: res = "Blue"sv;
   default: throw 3; // peu importe
   }
   return res;
}

Si on sacrifie le point de sortie unique, toutefois, il devient possible de couvrir tous les cas (à travers un cas default dans ce cas-ci) tout en épargnant les coûts additionnels qui découleraient de l'initialisation d'un état par défaut :

enum class Color { Red, Green, Blue }; 
auto f(Color c) {
   switch(c) {
   case Color::Red: return "Red"sv;
   case Color::Green: return "Green"sv;
   case Color::Blue: return "Blue"sv;
   default: return "Oops"sv;
   }
}

enum class Color { Red, Green, Blue }; 
optional<string_view> f(Color c) {
   switch(c) {
   case Color::Red: return "Red"sv;
   case Color::Green: return "Green"sv;
   case Color::Blue: return "Blue"sv;
   default: return {};
   }
}

enum class Color { Red, Green, Blue }; 
auto f(Color c) {
   switch(c) {
   case Color::Red: return "Red"sv;
   case Color::Green: return "Green"sv;
   case Color::Blue: return "Blue"sv;
   default: throw 3; // peu importe
   }
}

enum class Color : size_t { Red, Green, Blue };
auto f(Color c) {
   static const string_view names[]{ "Red"sv, "Green"sv, "Blue"sv };
   return static_cast<size_t>(c) < size(names)?
      names[static_cast<size_t>(c)] : throw 3; // peu importe
}

Écrire des fonctions plus courtes : une fonction, une vocation

Un bon truc pour réduire le nombre de points de sortie dans une fonction est, simplement, d'écrire de plus petites fonctions. Viser l'adage selon lequel à chaque fonction, on souhaite une seule et unique vocation. C'est d'ailleurs un idéal qu'il vaut la peine de poursuivre, du moins si votre compilateur est capable d'optimiser les appels de fonctions en réalisant du inlining (c'est plus difficile dans certains langages, mais en C++ l'écriture de petites fonctions peut se faire essentiellement à coût nul).

Ce n'est toutefois pas toujours trivial à réaliser.

bool is_leap_year(int year) {
   bool result;
   if (year % 400 == 0)
      result = true;
   else if (year % 100 == 0)
      result = false;
   else if (year % 4 == 0)
      result = true;
   else
      result = false;
   return result;
}

bool is_leap_year(int year) {
   bool result = false;
   if (year % 400 == 0)
      result = true;
   else if (year % 100 != 0 &&
            year % 4 == 0)
      result = true;
   return result;
}

bool is_leap_year(int year) {
   if (year % 400 == 0)
      return true;
   else
   {
      if (year % 100 == 0)
         return false;
      else
      {
         if (year % 4 == 0)
            return true;
         else
            return false;
      }
   }
}

bool is_leap_year(int year) {
   if (year % 400 == 0)
      return true;
   else if (year % 100 == 0)
      return false;
   else if (year % 4 == 0)
      return true;
   else
      return false;
}

bool is_leap_year(int year) {
   if (year % 400 == 0) return true;
   if (year % 100 == 0) return false;
   if (year % 4 == 0) return true;
   return false;
}

Impacts sur la conception logicielle

Dans les langages où on manipule directement des objets (ce qui inclut C++, mais exclut Java ou C# par exemple), ou encore dans les langages où les objets sont instanciés dynamiquement et manipulés indirectement (Java ou C# par exemple, et C++ de manière occasionnelle) et où on souhaite retourner une référence sur un objet instancié dans tous les cas, le coût des constructeurs est à considérer.

Prenons un exemple comparatif en C# et en C++ pour fins d'illustration (l'équivalent Java est conceptuellement identique à la version C# avec des différences cosmétiques). La version C# utilisera une hiérarchie de deux classes et des mécanismes idiomatiques de ce langage (pour cet exemple, on aurait aussi pu utiliser le Pattern Matching), et la version C++ utilisera variant ce qui est idiomatique des pratiques contemporaines dans ce langage.

using System;
using System.IO;
public class Program
{

#include <iostream>
#include <type_traits>
#include <iterator>
#include <iomanip>
#include <variant>
#include <string>
#include <string_view>
#include <sstream>
#include <cassert>
using namespace std;

   enum TypeMessage : ushort { Info, Warning }
   static TypeMessage LireTypeMessage(StreamReader reader)
   {
      string s = reader.ReadLine();
      return (TypeMessage)ushort.Parse(s);
   }

enum class MsgType : uint16_t { Info, Warning };
ostream &operator<<(ostream &os,
                    const MsgType &type) {
   return os << static_cast<underlying_type_t<MsgType>>(type);
}
istream &operator>>(istream &is, MsgType &type) {
   if (!is) return is;
   if (underlying_type_t<MsgType> val; is >> val)
      type = static_cast<MsgType>(val);
   return is;
}

   enum Severity : ushort { Low, Medium, High }
   static Severity LireSeverity(StreamReader reader)
   {
      return (Severity)ushort.Parse(reader.ReadLine());
   }

enum class Severity : uint16_t { Low, Medium, High };
ostream &operator<<(ostream &os,
                    const Severity &severity) {
   return os << static_cast<underlying_type_t<Severity>>(severity);
}
istream &operator>>(istream &is, Severity &severity) {
   if (!is) return is;
   if (underlying_type_t<Severity> val; is >> val)
      severity = static_cast<Severity>(val);
   return is;
}

   static bool EstCitation(string s) =>
      s.Length >= 2 && s[0] == '\"' && s[s.Length - 1] == '\"';
   static string EnleverGuillemets(string s) =>
      EstCitation(s) ? s.Substring(1, s.Length - 2) : s;
   static string LireChaîne(StreamReader reader) =>
      EnleverGuillemets(reader.ReadLine());

// rien à indiquer ici; std::quoted
// fait le travail

Le code C# est aussi plus simple (mais beaucoup plus coûteux) pour ce qui est des entrées/ sorties. Vous avez peut-être remarqué, plus haut, que le code C++ définit des opérations d'entrée et de sortie pour les énumérations, alors que le code C# ne se préoccupe que des entrées; c'est que le code client en C# fera des transtypages explicites en ushort ou en string pour fins d'affichage, alors que les types C++ sont complets et gèrent eux-mêmes ces opérations.

La prépondérance (coûteuse) des conversions en string et des dépendances explicites envers les substrats des énumérations est idiomatique de langages comme C# et Java, mais ne sont pas adéquates en C++ où les coûts inutiles sont mal vus, et mal venus.

Pour cette raison, vous remarquerez (ci-dessous) que dans le code C#, j'ai intégré le type de message à la string construite, ce qui évite une coûteuse opération, alors qu'en C++ le type de message est externe au message sérialisé et fait partie du code général de sérialisation.

Détail : en C++, il est simple de lire les données jeton par jeton (il serait aussi simple de le faire ligne par ligne, mais quel serait l'intérêt?). En C#, c'est beaucoup plus facile de procéder ligne par ligne, surtout en présence de chaînes de caractères comportant des espaces. Ceci explique que les formats utilisés pour les entrées/ sorties soient un peu différents dans les deux exemples.

   class MsgInfo
   {
      public string Info { get; }
      public MsgInfo(string info)
      {
         Info = info;
      }
      // unconditional quotes
      public override String ToString() =>
         string.Join("\n",
                     $"{(ushort) TypeMessage.Info}",
                     $"\"{Info}\"");
   }
   static MsgInfo LireInfo(StreamReader reader) =>
      new MsgInfo(LireChaîne(reader));

struct MsgInfo {
   string info{};
   MsgInfo() = default;
   MsgInfo(string_view info) : info{ info } {
   }
};
ostream &operator<<(ostream &os, const MsgInfo &msg) {
   return os << quoted(msg.info);
}
istream &operator>>(istream &is, MsgInfo &msg) {
   if (!is) return is;
   if (string info; is >> quoted(info))
      msg = MsgInfo{ info };
   return is;
}

   class MsgWarning
   {
      public string Warning { get; }
      public Severity Severity { get; }
      public MsgWarning(string warning, Severity severity)
      {
         Warning = warning;
         Severity = severity;
      }
      public override String ToString() =>
         string.Join("\n",
                     $"{(ushort) TypeMessage.Warning}",
                     $"\"{Warning}\"",
                     $"{(ushort)Severity}");
   }
   static MsgWarning LireWarning(StreamReader reader)
   {
      string warning = LireChaîne(reader);
      Severity severity = LireSeverity(reader);
      return new MsgWarning(warning, severity);
   }

struct MsgWarning {
   string warning{};
   Severity severity{ Severity::Low };
   MsgWarning() = default;
   MsgWarning(string_view warning, Severity severity)
       : warning{ warning }, severity{ severity } {
   }
};
ostream &operator<<(ostream &os, const MsgWarning &msg) {
   return os << quoted(msg.warning) << ' ' << msg.severity;
}
istream &operator>>(istream &is, MsgWarning &msg) {
   if (!is) return is;
   if (string warning; is >> quoted(warning))
      if (Severity severity; is >> severity)
         msg = { warning, severity };
   return is;
}

   class MsgInconnu
   {
      public override string ToString() => "Inconnu";
   }

template <class ... Ts>
struct Overload : Ts... {
   Overload(Ts ... ts) : Ts{ ts }... {
   }
   using Ts::operator()...;
};
template <class ... Ts>
   Overload(Ts...)->Overload<Ts...>;

C'est à partir de ce point que nous pouvons commencer à examiner les impacts de se retreindre à un seul point de sortie sur la conception des programmes.

Dans les deux langages, nous voulons qu'une instance de Message contienne soit un MsgInfo, soit un MsgWarning (il pourrait y avoir d'autres types de messages, bien sûr).

   class Message
   {
      object Contenu { get; }
      public Message(MsgInfo info)
      {
         Contenu = info;
      }
      public Message(MsgWarning warning)
      {
         Contenu = warning;
      }
      public Message(MsgInconnu inconnu)
      {
         Contenu = inconnu;
      }
      public override string ToString() =>
         Contenu.ToString();
   }

using Message = variant<
   monostate, MsgInfo, MsgWarning
>;
ostream &operator<<
   (ostream &os, const Message &msg) {
   return visit(Overload{
      // should never happen
      [&os](monostate) -> ostream & { return os; },
      [&os](const MsgInfo & info) -> ostream& {
         return os << MsgType::Info
                   << ' ' << info;
      },
      [&os](const MsgWarning & warning) -> ostream& {
         return os << MsgType::Warning
                   << ' ' << warning;
      }
   }, msg);
}

   static Message LireMessage(StreamReader reader)
   {
      if (reader.EndOfStream) return null;
      Message msg = new Message(new MsgInconnu());
      switch (LireTypeMessage(reader))
      {
         case TypeMessage.Info:
            msg = new Message(LireInfo(reader));
            break;
         case TypeMessage.Warning:
            msg = new Message(LireWarning(reader));
            break;
      }
      return msg;
   }

auto consume(istream &is) {
   assert(!!is);
   Message msg;
   if (MsgType type; is >> type) {
      switch (type) {
      case MsgType::Info:
         if (MsgInfo info; is >> info)
            msg = info;
         break;
      case MsgType::Warning:
         if (MsgWarning warning; is >> warning)
            msg = warning;
         break;
      }
   }
   return msg;
}

   static Stream MakeStream(string src)
   {
      var stream = new MemoryStream();
      var writer = new StreamWriter(stream);
      writer.Write(src);
      writer.Flush();
      stream.Position = 0;
      return stream;
   }
   static string MakeMessages()
   {
      return string.Join
      (
         "\n",
         new MsgInfo("Ça sent l'orage").ToString(),
         new MsgWarning("Prudence", Severity.Medium).ToString(),
         new MsgInfo("... mais ça va bien aller").ToString()
      );
   }

auto make_messages() {
   return stringstream{}
      << MsgType::Info << ' '
      << MsgInfo{ "Ca sent l'orage" } << ' '
      << MsgType::Warning << ' '
      << MsgWarning{ "Prudence", Severity::Medium } << ' '
      << MsgType::Info << ' '
      << MsgInfo{ "...mais tout va bien aller"};
}

   public static void Main()
   {
      string msgs = MakeMessages();
      using (StreamReader reader = new StreamReader(MakeStream(msgs)))
      {
         for (Message msg = LireMessage(reader);
              msg != null;
              msg = LireMessage(reader))
            Console.WriteLine(msg);
      }
   }
}

int main() {
   auto stream = make_messages();
   for (Message msg = consume(stream);
        stream;
        msg = consume(stream))
      cout << msg << endl;
}

À l'affichage, nous obtenons ce qui suit (même contenu de part et d'autre, mais des formats un peu différents dû aux forces et faiblesses des deux langages) :

0
"Ça sent l'orage"
1
"Prudence"
1
0
"... mais ça va bien aller"

0 "Ca sent l'orage"
1 "Prudence" 1
0 "...mais tout va bien aller"

Relaxer les règles et améliorer le design

En quoi décider de ne pas se restreindre à un seul point de sortie (en sachant que nous contrevenions déjà à cette « règle » dans les fonctions de lecture, de toute manière) améliorerait-il notre design? Voici :

   class Message
   {
      object Contenu { get; }
      public Message(MsgInfo info)
      {
         Contenu = info;
      }
      public Message(MsgWarning warning)
      {
         Contenu = warning;
      }
      public override string ToString() =>
         Contenu.ToString();
   }

using Message = variant<
   MsgInfo, MsgWarning
>;
ostream &operator<<(ostream &os, const Message &msg) {
   return visit(Overload{
      [&os](const MsgInfo & info) -> ostream& {
         return os << MsgType::Info
                   << ' ' << info;
      },
      [&os](const MsgWarning & warning) -> ostream& {
         return os << MsgType::Warning
                   << ' ' << warning;
      }
   }, msg);
}

   static Message LireMessage(StreamReader reader)
   {
      if (reader.EndOfStream) return null;
      switch (LireTypeMessage(reader))
      {
         case TypeMessage.Info:
            return new Message(LireInfo(reader));
         case TypeMessage.Warning:
            return new Message(LireWarning(reader));
      }
      throw new Exception(/*...*/);
   }

optional<Message> consume(istream &is) {
   if (MsgType type; is >> type) {
      switch (type) {
      case MsgType::Info:
         if (MsgInfo info; is >> info)
            return info;
         break;
      case MsgType::Warning:
         if (MsgWarning warning; is >> warning)
            return warning;
         break;
      }
   }
   return {};
}

   public static void Main()
   {
      string msgs = MakeMessages();
      using (StreamReader reader = new StreamReader(MakeStream(msgs)))
      {
         for (Message msg = LireMessage(reader);
              msg != null;
              msg = LireMessage(reader))
            Console.WriteLine(msg);
      }
   }
}

int main() {
   auto stream = make_messages();
   for (auto msg = consume(stream);
        msg;
        msg = consume(stream))
      cout << msg.value() << endl;
}

L'affichage demeure le même. Notez que, pour la conception de notre système :

De plus, objectivement, il existe des cas où de multiples points de sortie mène à du code plus simple. Réexaminez les exemples ci-dessus si vous n'en êtes pas convaincu(e)s.

Variations sur le thème des extrants

Les extrants privilégiés d'une fonction passent par sa valeur de retour, mais le portrait général des extrants d'une fonction est plus complexe. Certaines fonctions n'ont pas d'extrant au sens du code (mais ont souvent des effets de bord); d'autres ont plusieurs extrants, exprimés à travers des valeurs de retour composites, par des paramètres sortants, ou par une combinaison des deux.

Fonctions sans extrants

Une question propre aux extrants est celle de savoir si une fonction devrait toujours avoir (au moins) un extrant, quand bien même ce ne serait que pour signifier au contexte appelant que le calcul réalisé s'est bien complété (ou pas). Après tout, en mathématiques, une fonction a toujours un extrant.

Le cas du programme principal

Certains pourraient être tentés de mentionner les programmes principaux dans plusieurs langages commerciaux. Par exemple, en Java, main() est void, et en C#, Main() est void. Dans ces langages, la complétion de l'exécution d'un programme principal est considérée comme un succès, du moins par défaut, et il est possible de signaler une complétion incorrecte en appelant exit() en Java et Exit() en C#.

class X {
   public static void main(String ... args) {
      // contrairement à C ou à C++, args[0] n'est pas
      // le nom du programme
      // supposons qu'on refuse les paramètres à l'appel
      if (args.length > 0)
         System.exit(-1); // ici : échec
   } // ici : succès
}

class X
{
   public static void Main(String [] args)
   {
      // contrairement à C ou à C++, args[0] n'est pas
      // le nom du programme
      // supposons qu'on refuse les paramètres à l'appel
      if (args.Length > 0)
         Environment.Exit(-1); // ici : échec
   } // ici : succès
}

En C++, main() n'est jamais void, et les compilateurs qui supportent void main() ne sont pas conformes au standard. En C++, toutefois, main() a la particularité de retourner implicitement zéro (succès) si aucun return n'y apparaît.

Il y a donc mensonge à la fois dans les langages qui font du programme principal une fonction sans extrant (car, en pratique, ces fonctions retournent un signal de succès d'exécution au système d'exploitation), et dans les langages qui permettent d'omettre la valeur de retour et signalent un succès jusqu'à preuve du contraire. Ce qui est clair, cela dit, est qu'un programme principal n'est pas un bon exemple de fonction sans extrant... C'est une créature étrange et spéciale.

Considérations plus générales

Il se trouve qu'en pratique, il y a des cas raisonnables de fonctions sans extrants. Par exemple :

void afficher_menu();
choix lire_choix();
bool est_quitter(const choix&);
void traiter_choix(const choix&);
// ...
int main() {
   afficher_menu();
   auto chx = lire_choix();
   while (!est_quitter(chx)) {
      traiter_choix(chx);
      afficher_menu();
      chx = lire_choix();
   }
}

void afficher_menu();
choix lire_choix();
bool est_quitter(const choix&);
void traiter_choix(const choix&);
// ...
int main() {
   afficher_menu();
   for(auto chx = lire_choix(); !est_quitter(chx); chx = lire_choix()) {
      traiter_choix(chx);
      afficher_menu();
   }
}

Dans cet extrait (simpliste) de programme, nous avons deux fonctions sans extrants (type de retour void, pas de paramètre sortant), soit afficher_menu() et traiter_choix(). Il serait bien sûr possible de faire en sorte que ces fonctions retournent quelque chose (par exemple, un code de succès, ou un descriptif génrique de l'état du traitement qui a été fait), et cela peut même être une bonne idée dans certains cas, mais il est aussi raisonnable de présumer que afficher_menu() ne fait qu'afficher un menu, et que traiter_choix() fasse une tâche qui ne nécessite pas que l'on porte attention à son succès (ou pas).

Fonctions sans extrants et odeurs suspectes

De manière générale, toutefois, une fonction sans extrant (et, à plus forte raison, une fonction sans extrant et sans intrant) est un code malodorant... un Bad Code Smell. En effet, une fonction ayant une telle signature dépend nécessairement (a) d'états globaux ou partagés, ou encore (b) d'effets de bord.

On m'a d'ailleurs posé plusieurs fois cette question : « Pourquoi une surabondance de fonctions void est-elle un problème [à tes yeux]? » (à plus forte partie, une surabondance de fonctions void sans paramètres!).

Puisque la question est récurrente, voici quelques-unes des raisons :

• Le problème principal avec une méthode void est qu'elle n'a pas d'extrant (du moins, pas d'extrant « naturel »). Ses postconditions possibles sont donc (a) afficher / écrire sur un flux ou (b) modifier un état partagé (une variable globale, ou quelque chose qui est utilisé comme tel). J'inclus les paramètres sortants ici (ref et out en C#) dans ces états partagés, ceux-ci étant en pratique bel et bien partagés entre l'appelant et l'appelé. Ce n'est pas un moindre mal : ce partage réduit les occasions d'optimisations, empêchant le raisonnement local, car il y a toujours possibilité que l'état soit accédé concurremment par un autre fil d'exécution. Il existe des cas légitimes de fonctions void, bien entendu (swap est notable), mais il faut que ces fonctions soient rares et justifiées, sinon c'est un signe que le découpage du code est ... perfectible.
• Exprimé autrement : quand on a une fonction void, elle n'est probablement pas réutilisable hors de son contexte original (il y a toujours des exceptions, évidemment), puisqu'elle est couplée avec les états de ce contexte. Si elle a une valeurs de retour (ou plusieurs, par exemple dans le cas des uplets de C# ou std::tuple en C++), il est typiquement plus facile que la réutiliser hors de son contexte original car son rôle et son interface (intrants, extrants) sont plus clairs.

En résumé, qu'une fonction soit de signature void F() implique que ses postconditions sont couplées au contexte, réduisant drastiquement la réutilisabilité du code. C'est souvent du code jetable... Si votre code comprend de telles fonctions, cela ne veut pas dire qu'il est mauvais, mais cela signifie toutefois qu'il peut être sage de le revisiter, et de se demander s'il est bien organisé, bien découpé. Retenez que si les postconditions de vos fonctions modifient des attributs d'un objet, votre code est peut-être fragile – c'est essentiellement comme si vous dépendiez de variables globales.

Distinguer extrant et point de sortie

Rappelons brièvement que, bien que certains extrants soient des points de sortie d'une fonction (un return, par exemple, ou la plupart des throw), plusieurs extrants n'en sont pas. Ceci est particulièrement vrai pour les langages qui acceptent des paramètres sortants (passés par référence en C++, ou encore ref en C# – car les out sont des sortants purs).

Les exemples les plus connus d'extrants qui ne sont pas des points de sortie sont les paramètres de fonctions clés comme std::swap() ou std::exchange() en C++, ou encore la valeur consommée par un TryParse() en C# :

// ...
int main() {
   if (int a, b; cin >> a >> b) {
      cout << "Avant swap() : " << a << ' ' << b << '\n';
      swap(a, b);
      cout << "Apres swap() : " << a << ' ' << b << endl;
   }
}

// ...
int main() {
   int pre = 0;
   if (int a; cin >> a) {
      cout << "Avant exchange() : " << a << ' ' << pre << '\n';
      int post = exchange(a, pre);
      cout << "Apres exchange() : " << a << ' ' << post << endl;
   }
}

// ...
static void Main()
{
   if (float.TryParse(Console.ReadLine(), out float x))
   {
      Console.WriteLine($"Succès lors de a lecture du flottant {x}");
   }
}

Il existe aussi des langages, par exemple les langages Pascal et Modula, où ce qui tient lieu de « return » s'exprime en affectant au nom de la fonction en cours d'exécution la valeur de retour courante, ce qui ne complète pas l'exécution de cette fonction. Par exemple :

program demo_facto;

function factorielle(n : integer) : integer;
   var i : integer;
   begin
      i := 1;
      factorielle := 1;
      while i <= n do
         begin
            factorielle := factorielle * i;
            i := i + 1;
         end;
   end;

begin
    writeln(factorielle(5));
end.

Ceci répond d'ailleurs à la question « est-il raisonnable pour une fonction d'avoir plusieurs extrants? » : certains traitements ont conceptuellement besoin de deux extrants, et la fonction de permutation des états de deux paramètres en est sans doute le cas le plus exemplaire.

Valeur de retour ou paramètres sortants

De manière générale, il est plus facile de raisonner sur la base de fonctions pures, au sens de fonctions qui acceptent des intrants par valeur, réalisent un calcul, et produisent un résultat en sortie à travers une valeur de retour. Ce mode de pensée est difficile à atteindre quand les paramètres sont des indirections vers des objets mutables et quand un programme est multiprogrammé; conséquemment, dans les langages qui ne supportent pas les accès directs aux objets (Java, C# et plusieurs autres; même C et C++ si vous passez les paramètres par référence ou par adresse), privilégiez les objets immuables, particulièrement si votre programme utilise plus d'un fil d'exécution.

Une fois cette mise en garde faite, règle générale, si vous avez le choix, préférez les fonctions qui profitent du mécanisme de valeur de retour pour exprimer leurs extrants. Quelques exemples, exprimés dans divers langages contemporains (vous pouvez extrapoler l'équivalent de chacun dans votre langage de prédilection) :

// ...
class Entier {
   int valeur;
   public int getValeur() {
      return valeur;
   }
   public void setValeur(int valeur) { // :(
      this.valeur = valeur;
   }
   public Entier(int valeur) {
      setValeur(valeur);
   }
}
public class Programme {
   static void calculerCarré(Entier e) { // :(
      e.setValeur(e.getValeur() * e.getValeur());
   }
   public static void main(String ... args) {
      Entier e = new Entier(3);
      calculerCarré(e); // :(
      System.out.println(e);
   }
}

// ...
class Entier {
   int valeur;
   public int getValeur() {
      return valeur;
   }
   private void setValeur(int valeur) { // mieux
      this.valeur = valeur;
   }
   public Entier(int valeur) {
      setValeur(valeur);
   }
}
public class Programme {
   static Entier calculerCarré(Entier e) { // mieux
      return new Entier(e.getValeur() * e.getValeur());
   }
   public static void main(String ... args) {
      Entier e = new Entier(3);
      Entier carré = calculerCarré(e); // mieux
      System.out.println(carré);
   }
}

// ...
template <class T>
   void piecewise_sum(const vector<T> &v0, const vector<T> &v1, vector<T> &res) {
      assert(v0.size() == v1.size());
      assert(res.empty());
      for(auto i0 = begin(v0), i1 = begin(v1); i0 != end(v0); ++i0, ++i1)
         res.emplace_back(*i0 + *i1);
   }
int main() {
   enum { N = 1'000'000 };
   vector<int> v0(N, 2), v1(N, 3);
   vector<int> resultat;
   piecewise_sum(v0, v1, resultat);
   // resultat est plein de 5 :)
}

// ...
template <class T>
   auto piecewise_sum(const vector<T> &v0, const vector<T> &v1) {
      assert(v0.size() == v1.size());
      vector<T> res;
      for(auto i0 = begin(v0), i1 = begin(v1); i0 != end(v0); ++i0, ++i1)
         res.emplace_back(*i0 + *i1);
      return res;
   }
int main() {
   enum { N = 1'000'000 };
   vector<int> v0(N, 2), v1(N, 3);
   auto resultat = piecewise_sum(v0, v1);
   // resultat est plein de 5 :)
}

// ...
class Program
{
   static void CréerTableau<T>(int n, out T [] tab, T val)
   {
      tab = new T[n];
      for(int i = 0; i != n; ++i)
         tab[i] = val;
   }
   static void Main()
   {
      const int N = 10_000;
      CréerTableau(N, out int[] tab, -1);
      // tab est créé et contient N éléments de valeur -1
   }
}

// ...
class Program
{
   static T[] CréerTableau<T>(int n, T val)
   {
      var tab = new T[n];
      for(int i = 0; i != n; ++i)
         tab[i] = val;
      return tab;
   }
   static void Main()
   {
      const int N = 10_000;
      var tab = CréerTableau(N, -1);
      // tab est créé et contient N éléments de valeur -1
   }
}

Il est arrivé par le passé, particulièrement en C++, que des programmeuses et des programmeurs expérimenté(e)s estiment préférable d'utiliser la version de gauche, même si elle est moins claire et moins élégante, pensant s'épargner une copie de variable (copie qu'elles ou ils estimaient parfois coûteuse; ici, on parle que quelques mégaoctets de mémoire à copier et d'une allocation dynamique de mémoire non-négligeable). Cependant, depuis C++ 11 et l'avènement du mouvement, et à plus forte partie depuis C++ 17 qui garantit que tous les compilateurs conformes implémentent l'optimisation RVO, cette vision est incorrecte. Le code de droite est à la fois plus élégant, plus clair et plus rapide.

Il existe quelques cas où des paramètres sortants sont à privilégier. On peut penser à la permutation de deux valeurs :

static void Permuter<T>(ref T a, ref T b)
{
   T temp = a;
   a = b;
   b = temp;
}

// note : privilégiez std::swap!
template <class T>
   void swap<T>(T &a, T &b) {
      T temp = std::move(a);
      a = std::move(b);
      b = std::move(temp);
   }

... notez l'absence d'exemple en Java, qui ne supporte que le passage de paramètre par valeur et ne permet donc pas l'implémentation de cet algorithme fondamental.

Un autre cas est celui où une fonction a plusieurs extrants. Par exemple, en C#, on trouve des méthodes TryParse pour divers types. Ces méthodes doivent rapporter à la fois le succès (ou pas) de la conversion d'une chaîne de caractères en un autre type, de même que le fruit de cette conversion si elle a réussi :

// ...
class Program
{
   static void Main()
   {
      if (int.TryParse(Console.ReadLine(), out int n))
         Console.WriteLine($"Entier lu : {n}");
      else
         Console.WriteLine("Erreur de lecture");
   }
}

L'équivalent C++ serait :

// ...
int main() {
   if (int n; cin >> n)
      cout << "Entier lu : " << n << endl;
   else
      cerr << "Erreur de lecture\n";
}

... où on peut remarquer, conceptuellement, deux « extrants », soit la valeur lue (l'entier n), mais aussi le flux sur lequel la lecture a été faite, qui se comporte comme un booléen vrai seulement si l'opération de lecture fut un succès.

Valeurs de retour multiples

Il est aussi possible, dans plusieurs langages contemporains, de retourner plusieurs valeurs d'une même fonction et de les récupérer élégamment au point d'appel. Par exemple :

package main
import (
   "fmt"
)
func divEnt(num int, denom int) (bool,int) {
   if denom == 0 {
      return false, 0
   }
   return true, num / denom
}
func main() {
   ok,quot := divEnt(2,3)
   if ok {
      fmt.Println(quot)
   } else {
      fmt.Println("div par zéro")
   }
}

def div_ent(num,denom):
   if denom == 0: 
      return False,0
   else:
      return True,num/denom

n = input()
d = input()
ok,quot = div_ent(n, d)
if ok:
    print(quot)
else:
    print("division par zéro")

using System;
class Program
{
   static (bool,int) DivEnt(int num, int dénom)
   {
     if (dénom == 0)
        return (false,0);
     return (true, num / dénom);
   }
   static void Main()
   {
      int n = int.Parse(Console.ReadLine());
      int d = int.Parse(Console.ReadLine());
      var (ok,quot) = DivEnt(n, d);
      if(ok)
         Console.WriteLine(quot);
      else
         Console.WriteLine("division par zéro");
   }
}

#include <tuple>
#include <iostream>
using namespace std;
tuple<bool, int> div_ent(int num, int denom) {
   if(!denom)
      return make_tuple(false, 0);
   return make_tuple(true, num / denom);
}
int main() {
   int n, d;
   if(cin >> n >> d) {
      bool ok;
      int quot;
      tie(ok, quot) = div_ent(n, d);
      if(ok)
         cout << quot << endl;
      else
         cerr << "division par zero\";
   }
}

#include <tuple>
#include <iostream>
using namespace std;
auto div_ent(int num, int denom) {
   if(!denom)
      return tuple{ false, 0 };
   return tuple{ true, num / denom };
}
int main() {
   if(int n, d; cin >> n >> d) {
      if([ok, quot] = div_ent(n, d); ok)
         cout << quot << endl;
      else
         cerr << "division par zero\";
   }
}

Perspective contemporaine

L'idée selon laquelle une fonction devrait se limiter à un seul point de sortie est une bonne idée, et on devrait tendre en ce sens, surtout dans l'enseignement de la programmation aux débutantes et aux débutants. Cependant, ce n'est pas un dogme, et ça ne devrait pas l'être.

Conséquemment :

• Visez à écrire de petites fonctions, qui accomplissent une et une seule tâche. Vous en arriverez souvent à un seul point de sortie, et le code sera à la fois élégant, compréhensible et plus facile à optimiser pour votre compilateur
• Visez à écrire des fonctions pures le plus possible : intrants acceptés par valeur (ou non-modifiables si acceptés sous forme d'une indirection), résultats des calculs retournés à travers la valeur de retour. Ceci facilitera le raisonnement sur les fonctions, et réduira l'effort de débogage
• Visez l'élégance. Si votre fonction comprend plusieurs points de sortie par paresse ou par négligence, vous le paierez en temps d'exécution, en effort d'entretien, ou encore en effort de compréhension lorsque vous ou vos collègues devrez le relire ultérieurement

Par défaut, visez un seul point de sortie, mais n'en faites pas une doctrine rigide. S'il est justifié d'envisager plusieurs points de sortie, vous pouvez examiner cette avenue.

Envisagez de multiples points de sortie, donc :

• Si cela constitue une optimisation mesurable, p. ex. : sortir d'une répétitive dès que le résultat a été trouvé
• Si cela facilite la compréhension du code par le lectorat, p. ex. : traiter les cas d'erreurs possibles en début de fonction, sortant tout de suite s'il devient clair que la fonction ne pourra pas satisfaire ses postconditions, et poursuivre le traitement normal une fois ces considérations chose du passé
• Si cela permet une conception logicielle plus naturelle, p. ex. : évitant d'introduire des états inappropriés au concept modélisé (souvent : un cas par défaut qui n'aurait normalement pas lieu d'être). Cela entraînera généralement une optimisation, en évacuant du code qui n'apporte rien d'utile à la fonction

Comparez ce cas d'espèce :

// retourne -1 si a < b, 0 si a == b, 1 si a > b
int three_way_compare(int a, int b) {
   int resultat;
   if(a < b) {
      resultat = -1;
   } else {
      if(a == b) {
         resultat = 0;
      } else {
         resultat = 1;
      }
   }
   return resultat;
}

// retourne -1 si a < b, 0 si a == b, 1 si a > b
int three_way_compare(int a, int b) {
   if(a < b) return -1;
   if(a > b) return 1;
   return 0;
}

... et souvenez-vous que, dans bien des cas, la meilleure solution est de repenser l'interface. Si nous changeons légèrement le mandat de la fonction ci-dessus (voir le commentaire annonçant la fonction), nous pouvons en arriver à :

// retourne une valeur négative si a < b, 0 si a == b, une valeur positive si a > b
int three_way_compare(int a, int b) {
   return a - b;
}

... qui est nettement mieux!

Lectures complémentaires

Quelques liens pour enrichir le propos.

• Textes d'Edsger W. Dijkstra :
  • Son argumentaire contre le goto, qui a mené au mouvement de la programmation structurée : http://www.cs.utexas.edu/users/EWD/ewd02xx/EWD215.PDF
  • Sans doute le texte fondateur de la programmation structurée : http://www.cs.utexas.edu/users/EWD/ewd02xx/EWD249.PDF
• Si les échanges sur le sujet du nombre de points de sortie d'une fonction vous intéressent, http://stackoverflow.com/questions/36707/should-a-function-have-only-one-return-statement comprend plusieurs points de vue, et plusieurs références historiques à ce sujet
• Aussi intéressant, ce discours vers lequel m'a pointé Ben Deane et qui rappelle les raisons historiques de la règle du point de sortie unique... mais aussi de la règle du point d'entrée unique, ce qui nous montre que la programmation a beaucoup évolué depuis ses débuts : https://softwareengineering.stackexchange.com/questions/118703/where-did-the-notion-of-one-return-only-come-from/118793#118793
• En 2015, Yegor Bugayenko se dit d'avis que la POO s'exprime mieux avec un seul point de retour par fonction (mais j'ai des réserves sur sa vision de la POO) : http://www.yegor256.com/2015/08/18/multiple-return-statements-in-oop.html
• Concevoir de bonnes fonctions, selon Robert C. Martin dans une conférence donnée en 2009 : https://meekrosoft.wordpress.com/2009/08/01/robert-martin-at-ndc/
• Texte d'Abby Fichtner, qui penche pour une approche pragmatique : https://hackerchick.com/religious-war-48293-single-vs-multiple/
• En 2018, Raphael Poss compare les coûts associés au retour de plusieurs valeurs d'une même fonction, en C++ et en Go : https://science.raphael.poss.name/measuring-multiple-return-values-in-go-and-cpp.html
• Texte de Jonathan Boccara :
  • En 2018, il propose une démarche pour raisonner dans une fonction sur la base de sortie hâtive : https://www.fluentcpp.com/2018/08/24/how-to-design-early-returns-in-c-based-on-procedural-programming/
  • Texte de 2018 sur les paramètres servant à la fois d'intrants et d'extrants : https://www.fluentcpp.com/2018/09/07/input-output-values/
• Les Core Guidelines de C++ sur la question du point de sortie unique : https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#Rnr-single-return
• En 2019, James Monger propose des exemples en JavaScript qui suggèrent que plusieurs points de sortie, en particulier de sortie hâtive, améliorent parfois grandement la lisibilité du code : https://jamesmonger.com/2019/08/06/return-early-return-often.html
• Dans ce texte de 2019, Lane Wagner montre qu'en Go, la sortie hâtive (qu'il nomme des clauses de garde) améliore la lisibilité du code : https://qvault.io/2019/08/16/guard-clauses-how-to-clean-up-conditionals/
• En 2019, Anthony Steele montre l'intérêt d'une ouverture aux multiples points de sortie en C# : https://www.anthonysteele.co.uk/TheSingleReturnLaw
• Dans le guide de style de LLVM, on trouve une recommandation en faveur de la sortie hâtive d'une fonction : https://llvm.org/docs/CodingStandards.html#use-early-exits-and-continue-to-simplify-code

Mon ami Aaron Ballman, dans un tweet privé, m'a indiqué ceci :

// This is OKAY
int foo(int i) {
  if (i % 2 == 0)
    return 0;
  return 1;
}
// This is NOT OKAY
int foo(int i) {
  if (i % 2 == 0)
    return 0;
  abort();
}

• En 2015, Doug Binks propose le mouvement comme alternative au passage de paramètres sortants dans le cas d'objets lourds à copier comme des conteneurs : https://arne-mertz.de/2015/06/passing-containers-as-out-parameters/
• En 2016, Jonathan Müller montre comment exprimer un paramètre sortant de manière descriptive en C++ : https://foonathan.net/2016/10/output-parameter/
• Argumentaire proposé par Leonel Menaia en 2020 à propos de la pratique de sortie hâtive d'une fonction : https://medium.com/@leonelmenaia/return-early-pattern-3d18a41bba8
• Textes de 2021 par Marius Levert, qui montre par refactorisation que sortir tôt d'une fonction peut clarifier le propos :
  • https://schneide.blog/2021/01/18/return-first/
  • https://schneide.blog/2021/03/01/return-first-example/
• En 2021, Jonathan Boccara propose plusieurs manières de retourner plusieurs valeurs d'une fonction en C++ tout en mettant (à juste titre) l'accent sur l'importance de privilégier la valeur de retour plutôt que les paramètres sortants : https://www.fluentcpp.com/2021/07/09/how-to-return-several-values-from-a-function-in-c/