Bonnes pratiques en matière de fixation des valeurs des paramètres

[Morendil]

Meta: je souhaite expérimenter avec cette issue une nouvelle manière d'ouvrir des discussions auxquelles toute la communauté peut participer, sans pour autant augmenter indéfiniment notre WIP. Il s'agit donc d'ouvrir une issue avec l'étiquette [RFC] et d'indiquer une date limite au-delà de laquelle l'issue pourra être fermée si une résolution satisfaisante n'est pas intervenue auparavant. A cette date, ou lors de sa cloture si elle intervient plus tôt, une synthèse de la discussion pourra éventuellement être déposée sur le wiki.

Date de cloture de ce RFC: 1er novembre 2018

En cours de revue de #1149 certaines contradictions sont apparues sur la manière de gérer les paramètres. Ce sujet a déjà été abordé précédemment: #884 #886 #1082 notamment.

Ma compréhension des forces en présence est la suivante:

• on se sert des paramètres pour représenter les modifications paramétriques de la loi: revalorisations, etc.
• on se sert des formules datées pour représenter des modifications structurelles de la loi; pour autant, différentes versions d'une formule peuvent faire appel à un même paramètre
• rien ne garantit statiquement qu'un paramètre existe pour toutes les périodes où une formule qui l'exploite est définie, ce qui est parfois source d'erreurs
• lors de l'import des barèmes on représente par des valeurs null la non-existence d'un paramètre
• évaluer un paramètre pour une période où il est null occasionne une erreur à l'exécution
• en l'absence d'une valeur (pouvant être null) plus récente, Core fait l'hypothèse qu'un paramètre reste inchangé dans le temps
• on ne peut pas distinguer entre un paramètre manquant et une valeur qui se "prolonge" dans le temps (par exemple, on peut avoir une valeur pour 2010 et une autre pour 2012, cela peut vouloir dire soit que le paramètre est inchangé en 2011, soit qu'on en ignore la valeur sur cette période)

Ce sont des constats factuels (on pourra compléter pendant la discussion et j'invite à les corriger si besoin).

---

Ce qui suit relève plus de mon opinion:

Dans le cas de #1149 mon intuition penche fortement pour unifier la formule de l'AEFA. Cela respecte un principe plus général qui consiste à éviter au maximum de représenter comme structurelles des évolutions de la loi qui sont seulement paramétriques. Pourquoi ? Parce que la stratégie inverse engendre beaucoup de copier-coller de formules pour des modifications mineures, donc de la duplication de code, qui constitue l'une des formes les plus courantes de dette technique.

Une formule unifiée couvre une plage de dates, mais peut s'appuyer sur un paramètre qui évolue dans le temps pour moduler le comportement. Dans ce cas, il convient que le paramètre soit défini pour toutes les périodes couvertes par la formule.

Pour cette "prime exceptionnelle de fin d'année" qui est active seulement en 2008, je pense qu'il n'y a pas de conflit avec notre mécanique d'importation des barèmes IPP, car après vérification cette valeur n'apparait pas dans les XLS.

Cela dit, si cela était le cas, on pourrait quand même étudier des solutions. Par exemple on pourrait "protéger" certains paramètres contre l'écrasement lors de l'import de barèmes, en ajoutant un champ (par exemple protection: import-ipp, 2017-12-31) spécifiant jusqu'à quelle date on considère que les paramètres déjà dans OpenFisca sont satisfaisants.

[fpagnoux]

on ne peut pas distinguer entre un paramètre manquant et une valeur qui se "prolonge" dans le temps (par exemple, on peut avoir une valeur pour 2010 et une autre pour 2012, cela peut vouloir dire soit que le paramètre est inchangé en 2011, soit qu'on en ignore la valeur sur cette période)

Il existe un mécanisme qui permet d'indiquer explicitement qu'on s'attend à un changement de valeur pour une date donnée, mais qu'on ne connait pas la valeur :

  2020-01-01:
    expected

Ça na pas d'influence à l'exécution, mais ça permet d'ajouter des métadonnée sur notre connaissance de l'historique du paramètre.

[fpagnoux]

Cela dit, si cela était le cas, on pourrait quand même étudier des solutions. Par exemple on pourrait "protéger" certains paramètres contre l'écrasement lors de l'import de barèmes, en ajoutant un champ (par exemple protection: import-ipp, 2017-12-31) spécifiant jusqu'à quelle date on considère que les paramètres déjà dans OpenFisca sont satisfaisants.

L'import des barèmes IPP est en train d'être repensée, et on va plus vers une fusion totale que vers des scripts d'imports. Par ailleurs, les scripts d'imports actuels ne tournent plus depuis longtemps, donc pas trop de risque d'écrasement aujourd'hui.

[Morendil]

Egalement, il serait utile de maintenir un calendrier d'actualisation, comme on l'a déjà évoqué je crois (je ne retrouve plus la référence du commentaire), idéalement le plus près possible des paramètres concernés (en métadonnées). L'idée n'est pas forcément de forcer l'expiration de paramètres, mais plutôt dans mon esprit de servir à constituer une checklist de façon automatique qu'on pourrait générer à dates fixes, trimestriellement ou mensuellement par exemple.

(Je pense à ça car je constate qu'on a des paramètres pour l'ARS qui semblent un peu moisis, en plus de ne pas être définis pour les DOM.)

Resterait évidemment à répondre aussi à la question "qui s'y colle" puisqu'on constate qu'ouvrir une issue ne suffit pas à ce que le taf soit fait.

[Morendil]

expected

On pourrait aussi être explicite quand un paramètre n'a pas changé, en combinant avec un calendrier:

updates:
  annually
2019-01-01:
  12345.6
2020-01-01:
  idem

[benjello]

Pour répondre au dernier point du premier post. On n'a pas de mécanisme pour dire je ne connais pas la valeur entre deux valeurs. Donc on peut mettre explicitement null pour avoir une erreur ou on garde l'ancienne valeur et on ajoute un commentaire. On pourrais rajouter un tag unkown mais pour l'instant on n'en a pas vraiment eu l'usage.

Pour info à l'IPP on met à jour les barèmes une à deux fois par an. On n'est généralement pas aussi réactifs que mes aides, la msa ou syso mais on essaie de tout balayer.

Pas contre que l'on consolide un calendrier sur le wiki. J'avais noté quelques points ici.

[Morendil]

Un autre exemple de deux formules datées, qui ne sont distinguées en fait que par l'application d'un paramètre législatif, qu'on pourrait (et devrait) unifier:

    def formula_2016_07_01(famille, period):
        montant_avant_degressivite = famille('aide_logement_montant_brut_avant_degressivite', period)
        loyer_reel = famille('aide_logement_loyer_reel', period)
        loyer_degressivite = famille('aide_logement_loyer_seuil_degressivite', period)
        loyer_suppression = famille('aide_logement_loyer_seuil_suppression', period)
        handicap_i = famille.members('handicap', period)
        handicap = famille.any(handicap_i)

        coeff = select(
            [loyer_reel <= loyer_degressivite, loyer_reel <= loyer_suppression, loyer_reel > loyer_suppression],
            [1, 1 - ((loyer_reel - loyer_degressivite) / (loyer_suppression - loyer_degressivite)), 0]
            )

        statut_occupation_logement = famille.demandeur.menage('statut_occupation_logement', period)
        accedant = (statut_occupation_logement == TypesStatutOccupationLogement.primo_accedant)
        locataire_foyer = (statut_occupation_logement == TypesStatutOccupationLogement.locataire_foyer)
        exception = accedant + locataire_foyer + handicap
        coeff = where(exception, 1, coeff)

        montant = round_(montant_avant_degressivite * coeff, 2)

        return montant

et

    def formula_2017_10_01(famille, period, parameters):
        montant_avant_degressivite = famille('aide_logement_montant_brut_avant_degressivite', period)
        loyer_reel = famille('aide_logement_loyer_reel', period)
        loyer_degressivite = famille('aide_logement_loyer_seuil_degressivite', period)
        loyer_suppression = famille('aide_logement_loyer_seuil_suppression', period)
        handicap_i = famille.members('handicap', period)
        handicap = famille.any(handicap_i)

        coeff = select(
            [loyer_reel <= loyer_degressivite, loyer_reel <= loyer_suppression, loyer_reel > loyer_suppression],
            [1, 1 - ((loyer_reel - loyer_degressivite) / (loyer_suppression - loyer_degressivite)), 0]
            )

        statut_occupation_logement = famille.demandeur.menage('statut_occupation_logement', period)
        accedant = (statut_occupation_logement == 1)
        locataire_foyer = (statut_occupation_logement == 7)
        exception = accedant + locataire_foyer + handicap
        coeff = where(exception, 1, coeff)

        montant_avant_degressivite_et_coeff = round_(montant_avant_degressivite * coeff, 2)

        abattement_forfaitaire = parameters(period).prestations.aides_logement.autres.abattement_forfaitaire
        aide_logement_apres_abattement_forfaitaire = (montant_avant_degressivite_et_coeff > 0) * max_(0, montant_avant_degressivite_et_coeff - abattement_forfaitaire)

        return aide_logement_apres_abattement_forfaitaire

Si l'abattement forfaitaire est de zéro, il est clair que la 2è formule se réduit à la première.

[benjello]

@Morendil : quelques points de contexte pour que tu aies une vision plus complète.

Je rappelle succinctement qu'un des objectifs d'openfisca et de pouvoir manipuler une abstraction de la législation. Par exemple, on doit pouvoir ne garder le système qu'à une date donnée et le vieillir selon un processus précis (inflater des paramètres monétaires, neutraliser certaines variables sur certaines périodes etc, voir par exemple cette fonction que l'on aimerait faire remonter dans core dans les prochaines semaines).

Pour cela, il faut pouvoir manipuler les paramètres et les variables à certaines dates.

• Les paramètres ont une valeur par date donc c'est assez simple (et encore, il peut y avoir des améliorations possibles entre date d'effet et date à laquelle a été prise la décision de changer la valeur). Mais il faut éviter de mettre des paramètres à zéro quand ils n'existent pas, d'utilsier des paramètres comme des flags pour activer désactiver des dispositifs (@claireleroy a une PR corrective qui va bientôt arriver qui a rencontré ce problème)

• Pour les variables, on s'appuie sur le dictionnaires des formules par dates. Il faut donc en préserver l'intégrité. On ne devrait donc pas utiliser des conditions sur period dans le code des formules.

Enfin il y a toujours eu un tiraillement entre rendre la lecture d'une formule à une date donnée facilement lisible par un expert non codeur et factoriser du code. En effet, la meilleur façon de factoriser du code tout en respectant les consignes mentionnées plus haut est l'utilisation de helpers, des fonctions pratiques que l'on peut utiliser soit dans plusieurs formules et potentiellement avec des paramètres différents. Personnellement, je pense qu'il est un peu vain de vouloir rendre tout le code lisible à tout le monde, et que cela se paie soit en perte de flexibilité soit prolifération de copier-coller et autres problèmes de ce genre. Donc je ne me prive pas d'utiliser des helpers bien sentis. Sachant que je n'ai pas encore vu arriver des contributions de non codeurs purs et que l'exemple de la msa montre que d'autres peuvent s'approprier assez vite le code grâce aux super travail de @Anna-Livia @sandcha @fpagnoux après la première ébauche de @cbenz.

Je suis toute ouïe sur des propositions pour améliorer l'état actuel à la lumière de ces contraintes et de notre expérience passée.

[fpagnoux]

Je rappelle succinctement qu'un des objectifs d'openfisca et de pouvoir manipuler une abstraction de la législation.

👍. C'est à mon avis un point clé à prendre en compte dans la recherche de bonnes pratiques sur ce sujet. Deux formules doivent-elle vraiment être factorisées dans le code si elles ne le sont pas dans la loi ? Doit-on faire émerger des structures qui ne sont pas explicitées dans les textes ?

Dans un autre contexte, sur les bourses du supérieur je crois, on avait eu un dilemme du même ressort: les barèmes en fonction de nombre d'enfants (jusqu'à 7 ou 8) étaient donnés sur légifrance via un gros tableau. Il était évident qu'il y avait une structure derrière ces valeurs. On avait passé un peu de temps à essayer de la trouver, en essayant de chercher les règles d'arrondis appliqués et les "variables cachées" du système. Mais on avait ensuite abandonné en réalisant que ce n'était pas le but d'OpenFisca que de faire émerger cette structure.

[Morendil]

Mais il faut éviter de mettre des paramètres à zéro quand ils n'existent pas

Je questionne précisément ce "il faut", et je te propose la reformulation suivante: "pour diverses raisons on a fait le choix jusqu'ici de ne pas mettre des paramètres à zéro quand ils n'existent pas".

Ce qui m'intéresse c'est de comprendre ces raisons, de façon à proposer des solutions. Prenons très précisément l'exemple ci-dessus. Je propose d'unifier ces deux formules. Le gain est clair: environ 20 lignes de code. Ce gain m'intéresse et si on peut le préserver en apportant d'autres idées, ça vaut le coup de chercher.

La façon de le faire consiste à considérer le paramètre "abattement forfaitaire" comme un paramètre de modulation du comportement de la loi. En 2016 il est à 0, ensuite il passe à 5€. Quel est précisément pour cet exemple l'objection que cela soulève ? Qu'est-ce qui pourrait se passer qu'on regretterait ?

[Morendil]

Deux formules doivent-elle vraiment être factorisées dans le code si elles ne le sont pas dans la loi ? Doit-on faire émerger des structures qui ne sont pas explicitées dans les textes ?

Oui: c'est déjà ce qu'on fait quand on distingue variables et paramètres - le législateur ne fait pas cette distinction, il rédige des deltas légistiques qui disent "au 3e alinéa de l'article 11, la mention '15 euros' est remplacée par '10 euros'". C'est déjà ce qu'on fait quand on introduit une variable aide_logement_montant_brut_avant_degressivite qui n'existe pas dans la loi.

Tout ça me semble légitime: c'est une compétence clé en développement logiciel, celle de rechercher l'expressivité dans la représentation de la connaissance.

Encore une fois prenons l'exemple ci-dessus. On voudrait être capable de représenter l'état de la loi en 2015, 2016 et 2017. Une façon triviale de le faire consiste à enregistrer une nouvelle formule à chaque delta - au lieu de s'enquiquiner à introduire des variables intermédiaires et des paramètres, on fait un copier-coller, on ajoute une formule datée et on applique ce que disent les textes pour obtenir une nouvelle version. C'est une mauvaise stratégie parce qu'elle maximise la production de lignes de code, et chaque ligne de code supplémentaire est un fardeau de maintenance.

Une meilleure façon consiste à effectivement matérialiser des structures latentes. On le fait déjà, mais on ne le fait pas assez !

Par exemple, si on disposait de mécanismes réutilisables pour représenter la notion de "conditions d'applicabilité" et de "modulation linéaire", on pourrait exprimer la formule unifiée à peu près comme ça:

définis: dégressif
  linéaire:
    base: loyer_reel
    seuil: loyer_degressivite
    plafond: loyer_suppression
définis: coeff
  choix:
    - valeur: 1
      si une de ces conditions:
        - locataire
        - accédant
        - handicap
    - valeur: dégressif
      autrement
résultat: brut_avant_degressivite * coeff - abattement_forfaitaire

Cette formulation ne s'oppose pas non plus à la possibilité de reconstituer l'état de la loi en 2015, 2016 et 2017. Elle nous donne simplement une façon plus succincte de dire: "La loi actuelle combine un mécanisme d'abattement introduit en 2017 en complément d'un mécanisme de dégressivité qui lui a été introduit en 2016". (On pourrait même envisager d'associer des périodes aux mécanismes, un grain plus fin que de les associer aux formules.)

Pour moi la façon qu'on a de coder actuellement des formules OpenFisca c'est un peu comme si on écrivait un programme complexe en assembleur "parce que comme ça on maîtrise tout". C'est vrai, et ça peut être un avantage, et on peut même le préserver pour les occasions où on en a besoin (performance, formules très tordues, etc.). Pour la plus grande partie du code, on peut aussi obtenir des bénéfices énormes en passant à des formulations de plus haut niveau et débarrassées du maximum de complexité accidentelle.

[benjello]

Mais il faut éviter de mettre des paramètres à zéro quand ils n'existent pas

Je questionne précisément ce "il faut", et je te propose la reformulation suivante: "pour diverses raisons on a fait le choix jusqu'ici de ne pas mettre des paramètres à zéro quand ils n'existent pas".

Ce qui m'intéresse c'est de comprendre ces raisons, de façon à proposer des solutions.

C'est parce qu'il y a une différence entre n'avoir aucune existence et valoir zéro. Notamment celle de produire une erreur si on est appelé à une date où l'on n'est pas censé exister: explicit is better than implicit . Mais surtout parce qu'on peut être manipulé de façon systématique par du code et que décider d'une transformation tous les paramètres qui ont une pertinence à un instant donné est plus facile si on définit s'il le son (pertinent) ou pas. Par exemple imaginons que l'on désire ajouter 10 euros à tous les paramètres monétaires d'un sous arbres, utiliser 0 pour null peut créer un problème.

[benjello]

@Morendil : pour ce qui concerne ton souci d'éviter des redondances inutiles (et n'hésite surtout pas à les factoriser) mais je suis assez sceptique sur le développement d'un niveau d'abstraction supplémentaire qui nécessiterait d'apprendre une couche supplémentaire, rendrait plus compliqué le débogage etc.

Python a été retenu parce qu'il permet de faire beaucoup de choses (en tout cas bien plus que les logiciels spécialisé de statistiques utilisés couramment pour faire de la microsimulation) tout en étant particulièrement lisible. Et globalement j'ai vu peu de frustration de la part des utilisateurs sur la capacité à coder des formules une fois comprise le fait que l'on utilise des vecteurs.

Par contre il y a pas mal de domaines où il y a de la redondance que l'on pourrait sûrement régler avec un peu de génie logiciel bien senti:

• les cotisations qui appellent un barème: elles pourraient former une classe héritant de Variable et être plus explicites
• les décompositions pourraient être le support de création de simili variables facilement et rapidement créées (voir ma contribution à https://github.com/openfisca/openfisca-france/issues/1165)

Je suis adepte des petits pas créant une valeur conséquente: je pense que l'on a enfin un modèle qui fonctionne très correctement pour deux types d'usages importants (microsimulation sur données d'enquêtes et calcul de cas-type via API-web type mes-aides). Je pense qu'en terme d'usage il faut récupérer (là il y a eu beaucoup de frustration et pas que de mon fait ou de mes collègues et supérieurs, demandez à @adrienpacifico notamment) cette faculté que l'on avait d'explorer le système socio-fiscal avec les décompositions et les cas types sans surprise pour illustrer les analyses les plus diverses que l'on voudrait en faire (on a déjà bien améliorer les réformes et l'écriture des formules). Bien entendu je suis preneur de tout ce qui réduit la maintenance d'où le chantier des barèmes IPP et ceux que je viens de mentionner plus haut.

[Morendil]

utiliser 0 pour null peut créer un problème

@benjello Vu. On peut pallier à ça en étendant la palette de "non-valeurs", de la même façon qu'on a expected on pourrait utiliser une valeur inactive. (La différence entre null et inactive est une différence d'intention: on dit qu'on sera capable de fournir une valeur par défaut qui neutralise le dispositif législatif concerné par ce paramètre. Avec "null" on ne fait pas de garantie, on s'attend à une erreur.)

Par exemple la formule complète (paramètres et variables) de l'aide au logement pourrait alors être:

dégréssivité_aide_logement:
  2015-01-01:
    inactive
  2016-01-01:
    true
loyer_degressivite:
  2016-01-01:
    1000
loyer_suppression:
  2016-01-01:
    2000
abattement_forfaitaire:
  2015-01-01:
    inactive
  2017-01-01:
    5

définis: dégressif
  si: dégréssivité_aide_logement
  linéaire:
    base: loyer_reel
    seuil: loyer_degressivite
    plafond: loyer_suppression
définis: coeff
  choix:
    - valeur: 1
      si une de ces conditions:
        - locataire
        - accédant
        - handicap
    - valeur: dégressif
      autrement
résultat: brut_avant_degressivite * coeff - abattement_forfaitaire

Si tu n'est pas fan du paramètre flag dégréssivité_aide_logement (je veux bien voir le problème qu'on a rencontré avec ça), on peut aussi faire ça:

loyer_degressivite:
  2015-01-01:
    inactive
  2016-01-01:
    1000
loyer_suppression:
  2015-01-01:
    inactive
  2016-01-01:
    2000
abattement_forfaitaire:
  2015-01-01:
    inactive
  2017-01-01:
    5

L'idée c'est que si une modulation linéaire a des paramètres inactive on neutralise la modulation (on la prend comme un multiplicateur de 1). C'est un peu plus délicat à gérer parce qu'il y a le cas où l'un des paramètres est inactif mais pas l'autre.

[Morendil]

Et globalement j'ai vu peu de frustration de la part des utilisateurs

Il me semble, et je le redirai autant de fois que nécessaire, que la frustration qui a entraîné la perte du "client" embauche.beta.gouv.fr est un signal qu'on ignore à nos risques et périls, quand bien même il s'y serait mêlé d'autres choses sans rapport avec l'écriture des formules. La frustration de la part de Mes Aides me semble réelle aussi.

Au-delà de ça, il faut distinguer entre trois énoncés:

• on a des utilisateurs capables de surmonter la friction
• on a suffisamment peu de frictions pour attirer de nouveaux utilisateurs
• on a tellement peu de frictions que cela crée un cercle vertueux d'amélioration

Je peux partager le premier énoncé, et m'inscrire en faux sur les deux derniers qui ne décrivent pas la situation actuelle, et mon ambition est bien d'atteindre le troisième.

[benjello]

@Morendil : on n'a pas beaucoup utilisé expected donc je ne suis pas très chaud pour rajouter des inactive en vertu du principe KISS. Je préférerais avoir un moyen simple et explicite de vérifier si un paramètre existe à une date donnée ou pas.

Je comprends que tu regrette la perte du client embauche.beta.gouv.fr. Je la regrette aussi car j'y avais investi pas mal de temps et d'efforts. Mais je regrette aussi beaucoup de fonctionnalités et d'usages (qui ne valent pas moins à mes yeux que de nouveaux utilisateurs) que j'ai accepté de perdre, momentanément qu'ils disaient, et que je rame pour remettre en place aujourd'hui. Je ne t'en tiens nullement comptable mais je médite désormais plus souvent l'adage de Charles Pasqua qui veut que les promesses n'engagent que ceux qui les reçoivent.

Cela dit je reste ouvert à toutes améliorations mais je pense qu'il faut faire de l'incrémental (et il y a du travail notamment pour) et du nettoyage ou rallier le consensus des utilisateurs actuels avant de faire des modifications substantielles en vue d'attirer des nouveaux. En tout cas c'est mon point de vue et je le partage ;-)

[fpagnoux]

Beaucoup de discussions riches et profondes sur cette discussion, merci pour toutes ces contributions 👍 .

Pour essayer de converger, je propose qu'on se concentre sur le sujet principal de l'issue, qui est (j'ai l'impression ?) la duplication de code engendrée dans les formules par la non-existence de certains paramètres pour certaines périodes.

Il y a quelque chose dans le comportement actuel qui est assez étrange:

1. On peut calculer une variable pour n'importe quelle période, même avant qu'elle ne soit introduite/après qu'elle ait disparue. Dans ce cas, sa valeur par défaut est retournée. Aucune erreur n'est levée.
2. Pour un paramètre, comme pointé par Laurent, un appel en dehors de la période de définition provoque une erreur.

Ces deux comportements semblent peu cohérents.

Je n'ai pas été témoin des discussions qui ont mené au choix de 1, mais quelque chose me dit que ce sont exactement les arguments de @Morendil: éviter de la pénible duplication de code, éviter des erreurs là où on peut faire des hypothèses raisonnables, etc.

Je pense qu'il y a de la valeur à distinguer dans les fichiers de paramètres null et 0, qui ont une sémantique différente. J'aurais par contre envie de challenger le principe selon lequel "évaluer un paramètre pour une période où il est null occasionne une erreur à l'exécution".

Je comprends l'intention de vouloir lever une erreur pour identifier rapidement des erreurs dans les formules, mais honnêtement, je ne suis pas sûr de l'utilité concrète: de mon expérience à coder pas mal de formules, je ne suis pas sûr que ça m'ait jamais aidé à anticiper un bug. Au contraire, ça a causé pas mal d'erreurs indésirables en production: c'était surtout le cas avant la refonte des "fuzzy" (#old 👴 ), mais on a toujours le risque aujourd'hui de faire planter les calculs parce qu'on fait un appel pour une période antérieure à la définition d'un paramètre. Dit autrement, on ne peut pas garantir que le calcul d'une variable ne va pas, pour une certaine période, causer une erreur serveur (c'est le 3e point de @Morendil).

A-t-on des exemples de cas très concret où, si le moteur OpenFisca retournait 0 quand on appelle un paramètre qui n'existe pas, on pourrait être induit en erreur?

Si non, ou si ces exemples pèsent moins lourd que la possibilité de factoriser le code et d'éviter des erreurs, je serai d'avis d'adopter un comportement plus souple, où l'appel d'un paramètre hors de sa période de définition renvoie 0 (ou une valeur par défaut définie explicitement, s'il y a des cas d'usages).

[benjello]

Je pense que pour les paramètres cela peut-être très dangereux de ne pas renvoyer une erreur quand le paramètres n'existe pas. On est assez souvent amené à réorganiser l'arbre des paramètres et donc à casser le code. Comme on ne rédige pas de tests pour chaque changement de paramètres (notamment côté impôt) je pense que l'on ouvre la voie à beaucoup de création de bugs. On perd tous les avantages d'explicit is better than implicit pour des avantages que je trouve mineurs et qui peuvent trouver des solutions plus explicites comme tester l'existence d'un paramètre.

[fpagnoux]

On est assez souvent amené à réorganiser l'arbre des paramètres et donc à casser le code.

Sur ce point bien d'accord, mais il y a deux situations distinctes:

• J'appelle un paramètre qui n'existe pas dans la législation (à aucune période). Dans ce cas, c'est sûr qu'il doit y avoir une erreur, de la même manière qu'il y a une erreur quand j'appelle une variable qui n'existe pas.
• J'appelle un paramètre qui existe, mais en dehors de sa période de définition. C'est seulement dans ce cas que l'on pourrait retourner une valeur par défaut sans lever d'erreur, comme pour les variables.

[benjello]

Point taken @fpagnoux ;-) L'autre usage qui me fait peur c'est que les gens utilisent alors zéro au lieu de null. Pour ce qui est de ta comparaison avec les variables, il me semble qu'elle n'est pas forcément très pertinente. On a eu une inflation de variable et d'augmentation de la complexité liées à la volonté de reproduire la législation à un niveau fin.

Je suis assez d'accord avec ton analyse coûts-bénéfices finale. Pour moi, on perd de la clarté pour peu de gains de factorisation de code si on dispose d'un moyen de tester si un paramètre existe. Mais je suis preneur d'autres avis !

[Morendil]

@benjello J'entends bien ton point "inflation de variable et d'augmentation de la complexité liées à la volonté de reproduire la législation à un niveau fin" et je crois que c'est une autre discussion :)

L'autre inquiétude qui n'a pas trouvé de réponse est "cela peut-être très dangereux de ne pas renvoyer une erreur quand le paramètres n'existe pas. On est assez souvent amené à réorganiser l'arbre des paramètres et donc à casser le code" et elle est plus directement liée à cette discussion, je l'entends aussi.

Pour l'instant ça me va de ne rien changer au fonctionnement actuel de Core, charge à ceux (comme moi) qui souhaitent simplifier des formules de s'assurer que les valeurs de paramètres ont un sens et sont testées. Je ferme, la date convenue étant dépassée :)

[fpagnoux]

L'autre inquiétude qui n'a pas trouvé de réponse est "cela peut-être très dangereux de ne pas renvoyer une erreur quand le paramètres n'existe pas. On est assez souvent amené à réorganiser l'arbre des paramètres et donc à casser le code" et elle est plus directement liée à cette discussion, je l'entends aussi.

@Morendil Il me semble que cette inquiétude a bien trouvé une réponse (voir les deux messages qui précèdent le tien 😉)