Discussion :

[el_slapper]

Pour le coup c'est un mécanisme bien connu de biais cognitif où on ne va pas s'apercevoir deux lettres qui auront été permutées, un mot manquant dans une phrase, ou un mot dupliqué, un à la fin d'une ligne et l'autre au début de la suivante.
À ce niveau là, c'est juste de la méchanceté gratuite.

C'est ça que tu ne comprends pas : le monde réel est méchant. C'est certes de la méchanceté, mais tout sauf gratuite. Elle est représentative du genre de trucs qu'on peut croiser dans le monde réel. Ce genre de règles à la con ou il faut tout lire, et deviner ce qu'il manque, est notre quotidien, nous les non-universitaires.

N'est-ce pas plutôt une bonne chose qu'il pose la question ?
Plutôt que de faire bêtement exactement ce qu'on lui demande de faire au risque d'avoir à la fin quelque chose de bancal ?

Le souci, c'est qu'il partait du principe que l'énoncé était faux. Et que lui, sa solution(un dédoublonnage par le début) était la vérité vraie. C'est un péché mortel. Au revoir.

D'ailleurs, j'aurais très bien pu faire mon trie sans doublon, puis inverser les deux avant-derniers chiffres.
J'aurais eu le même résultat que demandé, cela n'aura pas été ce que tu voulais, mais qui correspondra bien à ce que tu demandais.

Et c'est là que ton manque d'expérience du monde du travail d'enduit d'erreur : tu crois pouvoir jouer au plus malin. Or non, si tu veux survivre, non seulement il ne faut pas louper l'inversion des deux avant-derniers chiffres, mais en plus piger pourquoi ils sont inversés. Toute autre réponse te verra qualifiée d'un "au revoir monsieur/madame, vous n'avez pas su lire dans nos pensées". C'est le monde réel. Absurde, idiot, violent, méchant, mais réel. Et on cherche des gens capables de survivre là-dedans. Pas des intellectuels élégants qui vont savoir résoudre tous les problèmes standards avec élégance. Non, des gens solides, aguerris au combat de rue, qui sauront trouver la juste logique derrière une suite apparemment illogique.

Comment fais-tu pour savoir que ton interprétation de l'énoncé est bien celui du client, autrement qu'en demandant au client de préciser ce qu'il souhaite ?
Après, s'il me demande un pingouin alors qu'il voulait un manchot, on peut difficilement le deviner.

Il faut faire preuve de jugement. Et c'est difficile(et souvent injuste). Ca nécessite de l'habitude et surtout du flair. Pas le genre de choses qui s'apprend en formation.

D'un point de vue purement logique, en fait, tu ne peux pas. Et c'est bien là que je veux en venir : la logique ne suffit pas. C'est bien ça qu'on te reproche tous depuis le début : tu pars du principe qu'il suffit d'avoir raison d'un point de vue logique pour avoir raison tout court. Ben non. La logique est un outil très utile, mais on vu dans un monde ou elle ne suffit pas. Ce petit exercice tout bête, justement, va chercher à tester ta logique, mais aussi ta capacité à détecter tes propres erreurs, et aussi à intuiter ce qu'a voulu dire la personne n'en face.

Et des clients qui veulent un manchot et demandent un zèbre, c'est notre quotidien. Oui, parce-qu'un pingouin, ça serait trop facile.

[Grogro]

Le but, c'est surtout de voir à quelle vitesse le candidat va comprendre dans quel sens va la transformation. Le candidat doit comprendre intuitivement qu'il faut partir de la fin, et ne garder de la liste que les éléments qu'on a pas encore rencontrée. Après, à coder, ça va vite, comme le souligne fort justement Neckara. Mais toutes ces questions, je les ai vues sur le Stack Workplace, ou des gens se disaient que c'étai vraiment trop dur, et que si ils éliminaient tous les candidats qui échouaient, ils ne trouvaient plus personne.

Je ne comprends pas ta logique. Le but de la fonction que tu demandes semblent être d'ordonner une liste donnée en entrée, et de supprimer les doublons. Pourquoi, pour résoudre l'exercice, devrait-on tenir compte de l'exemple en entrée que tu donnes ? Moi, je lis la liste en entrée de façon incrémentale, j'ajoute à la liste de sortie en testant si le nombre n'est pas déjà présent, et ensuite seulement je trie la liste obtenue et je l'affiche. Ou alors je n'ai pas compris l'exercice, ou mal lu l'énoncé.

Après, pour les gens qui font l'affaire, c'est superfacile(et il y a intérêt, les problèmes professionnels sont autrement plus ardus. J'ai déjà du parler de mon cousin qui a fait un programme de calcul de l'influence de Jupiter sur les trajectoires des satellites, c'est une autre paire de manche).

C'est beaucoup moins ardu que tu ne le pense quand on a la formation adéquate (une licence de physique dans une bonne université suffit). le problème à N corps est un grand classique de la mécanique classique. Il n'est pas résoluble analytiquement, mais de nombreuses méthodes existent. A commencer par du bon vieux Runge-Kutta. C'est du calcul scientifique de base qui ne demande pas les mêmes qualités que pour être un bon développeur. Ce problème, c'était mon projet de calcul scientifique de L3. En fortran 95.

[Zirak]

Je ne comprends pas ta logique. Le but de la fonction que tu demandes semblent être d'ordonner une liste donnée en entrée, et de supprimer les doublons. Pourquoi, pour résoudre l'exercice, devrait-on tenir compte de l'exemple en entrée que tu donnes ? Moi, je lis la liste en entrée de façon incrémentale, j'ajoute à la liste de sortie en testant si le nombre n'est pas déjà présent, et ensuite seulement je trie la liste obtenue et je l'affiche. Ou alors je n'ai pas compris l'exercice, ou mal lu l'énoncé.

Même pb que Neckara en voulant aller trop vite, les nombres en sortie ne sont justement pas ordonnés, le 3 et le 4 sont inversés.

[Neckara]

Je pense que je viens de comprendre, tous les bons :

• ils se trompent en faisant un tri ;
• se font recaler parce qu'ils font remarquer le truc bizarre.

Au final, les seuls qui réussissent l'épreuve, c'est les boulets qui on merdé leur algorithme de tri et qui tombent par chance sur le bon résultat.
Faut pas s'étonner du niveau après.

[Invité]

Pour mes besoins perso, si j'avais voulu obtenir [1,2,4,3,5] à partir de [1,2,3,2,3,4,3,5], j'aurais plutôt fait

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
maliste = [1,2,3,2,3,4,3,5]
maliste = [1,2,4,3,5]

Mais je suppose que je suis recalée aussi

[el_slapper]

Je pense que je viens de comprendre, tous les bons :

• ils se trompent en faisant un tri ;
• se font recaler parce qu'ils font remarquer le truc bizarre.

Non. Ceux-là ne sont pas bons. en tous vas, pas bons dans le sens "utiles dans le monde réel". Quand la spec me parait curieuse, je demande des explications complémentaires. Je ne dis pas "ta spec est pourrie". La plupart du temps, d'ailleurs, il y a une explication à la bizarrerie. Il peut arriver qu'il y ait de vraies erreurs, ou de la communication pourrie. Un mec qui me fait des algos de fou, mais fait son complexe de supériorité dès qu'il voit une règle de gestion un peu surprenante, moi, je n'en veut pas.

Au final, les seuls qui réussissent l'épreuve, c'est les boulets qui on merdé leur algorithme de tri et qui tombent par chance sur le bon résultat.
Faut pas s'étonner du niveau après.

Non, ce sont ceux qui se sont loupés, ont testé leur algo, et se sont dits "tiens, j'ai du mal lire l'énoncé, je vais le relire plus attentivement". Et qui ont compris ou étaient leur erreur. Je ne vois pas comment un algorithme de tri peut arriver à ce résultat. Un algorithme de dédoublonnage, oui, mais seulement en partant de la fin - ce qui n'est pas ce qu'on apprend à l'école. Ca fait partie de l'intérêt du truc, aussi.

Je ne comprends pas ta logique. Le but de la fonction que tu demandes semblent être d'ordonner une liste donnée en entrée, et de supprimer les doublons. Pourquoi, pour résoudre l'exercice, devrait-on tenir compte de l'exemple en entrée que tu donnes ? Moi, je lis la liste en entrée de façon incrémentale, j'ajoute à la liste de sortie en testant si le nombre n'est pas déjà présent, et ensuite seulement je trie la liste obtenue et je l'affiche. Ou alors je n'ai pas compris l'exercice, ou mal lu l'énoncé.

Tu as dit toi-même que tu étais meilleur manager que développeur. Ben, voilà, désolé. L'exercice est difficile parce-que tout ce qu'on a, c'est un exemple d'entrée, et un exemple de sortie, et qu'aucun des algorithmes standard ne colle. Il ne faut pas trier(en fait, il faut garder l'ordre), et si il faut bien dédoublonner, il faut le faire en partant de la fin pour garder l'ordre en partant de la fin. L'exercice est d'autant plus difficile qu'il parait facile. Et que donc on le lit trop vite.

On est dans un cas réaliste ou le métier ne sait pas expliquer l'algorithme qu'il veut, et ne sait donner que des exemples. Et comme ils sont pressés et croient que c'est facile, ils ne donnent qu'un seul exemple. C'est la vraie vie. Un algo à la con, une spécification descriptive et non prescriptive, des zones d'ombres que quelqu'un de trop intelligent va explorer systématiquement(comme Neckara et ses algos alternatifs plus compliqués, avec inversions post dédoublonnage), ou au contraire ignorer(comme Conan Lord, ma solution préférée jusque là, même si ça manque un peu de recherche).

[Neckara]

Quand la spec me parait curieuse, je demande des explications complémentaires. Je ne dis pas "ta spec est pourrie". La plupart du temps, d'ailleurs, il y a une explication à la bizarrerie. Il peut arriver qu'il y ait de vraies erreurs, ou de la communication pourrie. Un mec qui me fait des algos de fou, mais fait son complexe de supériorité dès qu'il voit une règle de gestion un peu surprenante, moi, je n'en veut pas.

Ok, là je comprends mieux ce que tu entendais par là.
Il n'a pas juste demandé si l'énoncé avait une erreur.

Non, ce sont ceux qui se sont loupés, ont testé leur algo, et se sont dits "tiens, j'ai du mal lire l'énoncé, je vais le relire plus attentivement".

Ben s'ils lisent l'énoncé une fois, croient comprendre qu'on leur demande un algo de tri sans doublons, testent leur algo puis obtiennent une liste triée, je ne vois pas comment ils pourraient se dire "j'ai du mal lire l'énoncé".

Je ne vois pas comment un algorithme de tri peut arriver à ce résultat.

Ben si tu codes avec les pieds une fonction de tri boguée, tu peux obtenir n'importe quel résultat à la fin.

[Pyramidev]

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
function second_greater(list) {

    let greater = null;
    let second_greater = null;


    for(let i = 0; i < list.length; ++i)
        if( greater == null || list[i] > greater) {
            second_greater = greater;
            greater = list[i];
        }

    return second_greater;
}

Cet algorithme est faux.

Voici une correction si on considère que :
Si tous les éléments de la liste ont la même valeur, alors il faut retourner null.
Sinon, alors il faut retourner la deuxième plus grande valeur de la liste (par exemple 4 dans la liste [3,4,5,5,5]).

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
function second_greater(list) {

    let greater = null;
    let second_greater = null;


    for(let i = 0; i < list.length; ++i) {
        if(greater == null || list[i] > greater) {
            second_greater = greater;
            greater = list[i];
        } else if(list[i] < greater && (second_greater == null || list[i] > second_greater)) {
            second_greater = list[i];
        }
    }

    return second_greater;
}

[Neckara]

Bon, on ne se prend pas la tête, on fait un sort/unique_sort puis on récupère le premier élément en partant de la fin différent du dernier/l'avant-dernier élément.

Mais en effet, c'est vraiment traître.
Cela ne m'étonne pas que 80% échouent, s'il se font surprendre de la sorte.
Accuser l'incompétence est dans ce cas malhonnête, on teste surtout la connaissance du candidat sur le déroulement de ce type d'épreuves/exercices.

Personnellement, je pense que là j'aurais échoué l'épreuve, pourtant cela ne m'empêche pas d'être capable de réussir des algorithmes autrement plus complexes où tu passes plusieurs jours entiers à te taper la tête contre un mur.
De faire le boulot de 3 mois en 2 semaines (dont une semaine pour découvrir et installer l'environnement), et de faire preuve d'innovation.
Vous vous fermez la porte à des talents, c'est un peu dommage, surtout pour se plaindre derrière du niveau.

C'est comme certains tests de QI, si tu ne connais pas les ficelles/conventions derrière, tu ne peux pas les réussir. Maintenant j'ai compris un peu mieux le truc, je serais capable de réussir une autre épreuve du genre, pourtant je n'aurais eu aucun gain de compétence, j'aurais juste compris les règles du jeux.


Sinon je l'avais laissé exprès, et personne n'a remarqué que dans ma fonction unique_sort, je ne gère pas le cas où la liste est vide, ce qui est autrement plus grave.

[Pyramidev]

Personnellement, je pense que là j'aurais échoué l'épreuve

Dans le cas de l'exercice où le recruteur demande de retourner la deuxième plus grande valeur de la liste, tout dépend comment il gère l'épreuve.
Si tu écris rapidement la solution que tu avais donnée et que le recruteur te dit : « Cet algorithme est faux. Au revoir. », tu aurais échoué.
Mais un bon recruteur devrait dire « Il y a une erreur. Essaie de la trouver. » puis voir si tu la trouves rapidement.
Là, je ne suis pas en train de recruter, donc j'ai écrit directement une solution qui se rapprochait le plus possible de ton code de départ.

[Pyramidev]

Un autre sujet qui me passe par la tête : il y a quelques problèmes dans la signature de la fonction get_second_greater, dont le suivant : la fonction peut retourner null, mais l'utilisateur de la fonction ne peut le savoir que s'il lit le code source (ou la doc de la fonction, si on l'écrit), ce qui favorise les oublis.
Il faudrait renommer la fonction, peut-être en get_second_greatest_value_or_null. Je ne sais pas quelle serait la solution la plus idiomatique en JavaScript.

Remarque : si on choisit une autre interprétation de l'énoncé dans laquelle, à partir de la liste [3, 4, 5, 5, 5], il faudrait retourner 5 et non 4, alors on n'a pas ce genre de problème. Il suffit de poser en précondition que la liste d'entiers a au moins deux éléments et on pourra toujours retourner une valeur. Ainsi, la fonction pourrait s'appeler get_second_greatest_element.

À part ça, si on copie le code de get_second_greater dans http://www.compileonline.com/execute_nodejs_online.php, il y a un avertissement qui conseille de remplacer greater == null par greater === null. Idem pour second_greater == null.

PS : Je ne suis pas développeur JavaScript.

[ddoumeche]

Mais en effet, c'est vraiment traître.
Cela ne m'étonne pas que 80% échouent, s'il se font surprendre de la sorte.
Accuser l'incompétence est dans ce cas malhonnête, on teste surtout la connaissance du candidat sur le déroulement de ce type d'épreuves/exercices.

Ce n'est pas traître mais le reflet de la multiplicité des règles propres à chaque métier. Savoir bien lire une spécification et lever les ambiguïtés, sous entendus et non dits est aussi important voir plus important que de savoir coder.
Le nombre de plantages de projets à cause d'incompréhensions est incalculable

Personnellement, je pense que là j'aurais échoué l'épreuve, pourtant cela ne m'empêche pas d'être capable de réussir des algorithmes autrement plus complexes où tu passes plusieurs jours entiers à te taper la tête contre un mur.
De faire le boulot de 3 mois en 2 semaines (dont une semaine pour découvrir et installer l'environnement), et de faire preuve d'innovation.
Vous vous fermez la porte à des talents, c'est un peu dommage, surtout pour se plaindre derrière du niveau.

En informatique, les gens qui travaillent et s'investissent n'échouent pas, et si 75% des projets échouent, c'est aussi de la responsabilité des opérationnels et managers.
Mais il y a peu de candidats de bon niveau car les bons deviennent ingénieurs automobile, et non pas informaticien. On gagne beaucoup mieux sa vie et on est beaucoup considéré.

C'est comme certains tests de QI, si tu ne connais pas les ficelles/conventions derrière, tu ne peux pas les réussir. Maintenant j'ai compris un peu mieux le truc, je serais capable de réussir une autre épreuve du genre, pourtant je n'aurais eu aucun gain de compétence, j'aurais juste compris les règles du jeux.

Et inversement s'entrainer sur des jeux idiots dans les magazines pour enfant fait gagner 1°0 points de QI. Autant que d'aller à l'université.

Sinon je l'avais laissé exprès, et personne n'a remarqué que dans ma fonction unique_sort, je ne gère pas le cas où la liste est vide, ce qui est autrement plus grave.

Il suffit de lire l’algorithme (et donc de le dérouler mentalement) pour voir qu'il fonctionne dans le cas d'une liste d'éléments identiques.
Notons que la programmation par contrat est rarement pratiquée.

[Neckara]

Un autre sujet qui me passe par la tête : il y a quelques problèmes dans la signature de la fonction get_second_greater, dont le suivant : la fonction peut retourner null, mais l'utilisateur de la fonction ne peut le savoir que s'il lit le code source (ou la doc de la fonction, si on l'écrit), ce qui favorise les oublis.

Je pense qu'il est évident que si l'élément recherché n'existe pas, null sera retourné. null est là pour ça, j'ai envie de dire.

En revanche, je ne pense pas qu'il soit une bonne idée de créer des noms de fonctions trop à rallonge, au risque de nuire à la lisibilité du code.

À part ça, si on copie le code de get_second_greater dans http://www.compileonline.com/execute_nodejs_online.php, il y a un avertissement qui conseille de remplacer greater == null par greater === null. Idem pour second_greater == null.

JavaScript est une horreur à plusieurs niveau.

Là, c'est juste que undefined == null retourne true et undefined === null retourne false. Or dans une liste d'entiers, on ne devrait pas se retrouver avec un élément valant undefined.

Notons que la programmation par contrat est rarement pratiquée.

Disons qu'on a une fonction F qui retourne des listes, puis qu'on souhaite traiter cette liste. Si F retourne une liste vide, il ne faut pas que notre fonction plante.
En revanche, si F retourne une autre valeur qu'une liste, là oui, ce n'est pas de la responsabilité de notre fonction de vérifier que ce qui lui est passé en argument est correct, d'autant plus en JavaScript où cela pourrait devenir très lourd.

[Pyramidev]

Je pense qu'il est évident que si l'élément recherché n'existe pas, null sera retourné. null est là pour ça, j'ai envie de dire.

Pas forcément. La fonction pourrait aussi lancer une exception.

En revanche, je ne pense pas qu'il soit une bonne idée de créer des noms de fonctions trop à rallonge, au risque de nuire à la lisibilité du code.

Dans un langage avec un typage statique, c'est dans le type de retour que j'aurais signalé que le résultat est optionnel, par exemple std::optional<int> en C++, Maybe Int en Haskell, etc.
Dans un langage qui n'a que du typage dynamique, j'ai tendance à allonger certains noms de fonctions et variables pour réduire les risques d'erreurs d'étourderies.

Notons que la programmation par contrat est rarement pratiquée.

Disons qu'on a une fonction F qui retourne des listes, puis qu'on souhaite traiter cette liste. Si F retourne une liste vide, il ne faut pas que notre fonction plante.

Parles-tu seulement de unique_sort ou bien aussi de toute fonction qui a une liste en paramètre ?

Comme la fonction get_second_greatest_element n'a de sens que pour une liste ayant au moins deux éléments, alors il vaut mieux qu'elle plante si on lui passe une liste vide.

Le problème d'avoir des fonctions trop "gentilles" avec les arguments en entrée qui font semblant de marcher dans les cas que le développeur n'a pas prévus, c'est que, le jour où on se rend compte qu'il y a un bogue, ce sera plus difficile de remonter à l'origine du bogue.
Par contre, si la fonction signale une erreur avec un message d'erreur clair pour le développeur, alors l'origine du bogue sera immédiate : oups, on a oublié de réfléchir au cas où telle liste est vide ou n'a qu'un seul élément.

Pour nuancer ce que je viens de dire, dans certains programmes où les performances sont critiques, on aura tendance à désactiver les contrôles en mode Release (par exemple désactiver les assert en C). Dans ce cas, les violations de contrats n'entraîneront pas de message d'erreur clair.

[Neckara]

Pas forcément. La fonction pourrait aussi lancer une exception.

Les exceptions, c'est plus pour des cas "exceptionnels", "d'erreurs".
Une liste vide, ça reste une situation "normale".

Dans un langage qui n'a que du typage dynamique, j'ai tendance à allonger certains noms de fonctions et variables pour réduire les risques d'erreurs d'étourderies.

Pour les fonctions, si tu documentes, tu dois normalement avoir une auto-complétion avec quelques détails. Bon, je suis un mauvais exemple, j'utilise gedit.

D'un autre côté, je développe moi-même pour moi-même (recherche).

Parles-tu seulement de unique_sort ou bien aussi de toute fonction qui a une liste en paramètre ?

À priori toutes fonctions, à moins qu'il n'y ai des cas auxquels je ne pense pas.

Comme la fonction get_second_greatest_element n'a de sens que pour une liste ayant au moins deux éléments, alors il vaut mieux qu'elle plante si on lui passe une liste vide.

Mouais... dans ce cas là, je proposerais plutôt deux fonctions, ou un paramètre facultatif pour définir s'il faut retourner ou throw : get_second_greatest_element(list, {throw_if_not_exists = false, default_value = null, cmp = (a,b) => (a - b) }) {}.

Parce qu'il n'y a rien de plus enquiquinant d'être forcé à enchaîner des try/catch quand on n'en a pas besoins.

Le problème d'avoir des fonctions trop "gentilles" avec les arguments en entrée qui font semblant de marcher dans les cas que le développeur n'a pas prévus, [...]

La fonction marche bien correctement car elle retourne "null", c'est à dire qu'il n'y a pas de seconde plus grande valeur.

Après, en JavaScript, on ne va pas aussi tester le type de chaque élément du tableau. Dans ce cas, autant changer de langage.

Par contre, si la fonction signale une erreur avec un message d'erreur clair pour le développeur, alors l'origine du bogue sera immédiate : oups, on a oublié de réfléchir au cas où telle liste est vide ou n'a qu'un seul élément.

Sauf que derrière, ce n'est pas vraiment un cas d'exception, et ça te force à mettre des try-catch de partout. Ce qui est encore plus enquiquinant quand c'est une valeur attendue, où on se retrouve alors à écrire :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
let x;
try {
     x = foo();
} catch (e) {}

faa(x);

[Pyramidev]

Par contre, si la fonction signale une erreur avec un message d'erreur clair pour le développeur, alors l'origine du bogue sera immédiate : oups, on a oublié de réfléchir au cas où telle liste est vide ou n'a qu'un seul élément.

Sauf que derrière, ce n'est pas vraiment un cas d'exception, et ça te force à mettre des try-catch de partout. Ce qui est encore plus enquiquinant quand c'est une valeur attendue, où on se retrouve alors à écrire :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
let x;
try {
     x = foo();
} catch (e) {}

faa(x);

Il n'y a pas besoin de mettre des try-catch partout de cette manière. En outre, cela ne respecte pas la programmation par contrat.

En programmation par contrat, l'utilisateur n'a pas le droit de violer les préconditions. Par exemple, si je pose comme précondition que la liste en paramètre de get_second_greatest_element doit avoir au moins deux éléments, alors l'utilisateur de la fonction doit s'assurer que la liste en argument a au moins deux éléments. Si une certaine liste peut être vide ou n'avoir qu'un seul élément sans que cela ne provienne d'une erreur de programmation alors, pour pouvoir appeler get_second_greatest_element, il faut, par exemple, faire un if-else. Si la liste a au moins deux éléments, alors on appelle get_second_greatest_element. Sinon, on décide quoi faire en fonction du contexte.

Du coup, si la fonction get_second_greatest_element reçoit en argument une liste vide ou n'ayant qu'un élément, alors elle a le droit de faire ce qu'elle veut : crasher, retourner n'importe quoi, lancer une exception, loguer une erreur et arrêter le programme, acheter des tulipes sur internet, etc. Personnellement, quand les performances ne sont pas critiques, je lance une exception avec un type qui indique qu'il s'agit une erreur de programmation. Par exemple, en C++, il s'agit de std::logic_error.

Comme tu connais le C++, si t'as le temps, je peux te conseiller un article assez complet de Luc Hermitte sur la programmation par contrats en C++, en 3 parties.
Remarque : En C++20, on aura une standardisation de la programmation par contrat dans le langage.

[Neckara]

Par exemple, si je pose comme précondition que la liste en paramètre de get_second_greatest_element doit avoir au moins deux éléments, [...]

Pourquoi poser cette précondition ?
Autant accepter toutes listes d'entiers, non ?

Là, cela revient presque à déplacer la gestion de quelques cas particulier en dehors de la fonction. Ce qui revient presque à avoir un a priori sur le contenu de la fonction, or on n'est pas censé avoir de tels a priori. Et surtout de copier/coller le même code à presque chaque appel de la fonction.

En l’occurrence, il faudrait chercher la seconde plus grande valeur, pour savoir qu'elle n'existe pas. Pour ensuite pouvoir appeler la fonction pour chercher la seconde plus grande valeur.

[Pyramidev]

En l’occurrence, il faudrait chercher la seconde plus grande valeur, pour savoir qu'elle n'existe pas. Pour ensuite pouvoir appeler la fonction pour chercher la seconde plus grande valeur.

Dans le cas de get_second_greatest_value_or_null qui, quand on lui donne en entrée [3, 4, 5, 5, 5], retourne 4, il n'y a pas besoin de chercher la deuxième plus grande valeur pour vérifier si elle existe : il suffit de vérifier que la liste a au moins deux valeurs distinctes. Néanmoins, je ne lui donnerais probablement pas de précondition, car vérifier dans le code appelant que la liste ait au moins deux valeurs différentes risquerait d'être lent pour certaines listes.

Par contre, dans le cas de get_second_greatest_element qui, quand on lui donne en entrée [3, 4, 5, 5, 5], retourne 5, je lui donne une précondition : posséder au moins deux éléments.

Pourquoi poser cette précondition ?

Considérons les deux fonctions suivantes qui, quand on leur donne en entrée [3, 4, 5, 5, 5], retournent 5 :

• get_second_greatest_element, qui possède une précondition (la liste doit avoir au moins deux éléments) et
• get_second_greatest_element_or_null, qui, quand on l'appelle avec une liste trop petite (0 ou 1 élément), retourne null.

Laquelle est la plus adaptée ?

L'utilisateur peut se retrouver dans un des deux cas suivants :

• Cas n°1 : dans une certaine portion du code, l'utilisateur est sûr qu'une certaine liste a au moins deux éléments et appelle la fonction qui retourne le deuxième plus grand élément de la liste. Donc, si la liste n'a aucun élément ou qu'un seul élément, alors il y a un bogue dans le programme, car ce cas n'a pas été prévu. Il y a deux sous-cas :
  
  • Cas n°1a : les performances ne sont pas critiques. Alors, le contrôle dans get_second_greatest_element est actif et signale une erreur claire pour le développeur en cas de non respect de la précondition. Par contre, si on appelle get_second_greatest_element_or_null, alors soit on ne fait pas de vrai contrôle, ce qui diminue la robustesse du code, soit on teste explicitement la nullité de la valeur retournée par la fonction et on signale une erreur explicitement quand la valeur retournée est nulle, ce qui encombre le code appelant.
  • Cas n°2a : les performances sont critiques. Alors, le contrôle dans get_second_greatest_element est inactif. get_second_greatest_element ne contrôle pas le nombre d'éléments de la liste en entrée. Par contre,get_second_greatest_element_or_null fait ce contrôle, ce qui réduit les performances. Je ne sais pas si cette remarque est pertinente pour un langage comme JavaScript qui n'a pas été conçu pour être aussi performant que C. Par contre, elle s'applique aux langages comme C et C++.
  
  Donc, dans le cas n°1, je préfère clairement get_second_greatest_element à get_second_greatest_element_or_null.
• Cas n°2 : dans une certaine portion du code, l'utilisateur n'est pas sûr qu'une certaine liste ait au moins deux éléments. Si elle est assez grande, l'utilisateur voudrait récupérer le deuxième plus grand élément et faire quelque chose avec. Sinon, il voudrait faire autre chose.
  Avec get_second_greatest_element, il faut s'arranger pour se retrouver dans le cas n°1 : l'utilisateur doit écrire un if-else pour tester la taille de la liste. Dans le if (par exemple), il appellera get_second_greatest_element et fera quelque chose avec le deuxième plus grand élément. Dans le else, il fera autre chose.
  Avec get_second_greatest_element_or_null, l'utilisateur pourrait appeler directement cette fonction pour faire deux opérations d'un coup : tester la taille de la liste et récupérer le deuxième plus grand élément si la liste est assez grande. Ensuite, l'utilisateur devrait écrire un if-else pour tester la nullité de la valeur retournée. Dans le if (par exemple), il ferait quelque chose avec le deuxième plus grand élément. Dans le else, il ferait autre chose. Dans certains langages, il est possible de vérifier lors de l'analyse statique du code (ou à la compilation) que l'on n'essaie d'accéder à la valeur entière de la variable que quand cette variable n'est pas null, ce qui permet de repérer avant l'exécution les erreurs d'étourderie du style if(variable == null) au lieu de if(variable != null). Je pourrais détailler davantage ce point si ça intéresse quelqu'un.
  Personnellement, dans le cas n°2, parmi ces deux approches, j'ai tendance à préférer celle avec get_second_greatest_element que je trouve plus lisible.

Du coup, dans l'ensemble, je préfère get_second_greatest_element qui a une précondition plutôt que get_second_greatest_element_or_null qui n'en a pas.

[Neckara]

Dans le cas de get_second_greatest_value_or_null qui, quand on lui donne en entrée [3, 4, 5, 5, 5], retourne 4, je ne lui donne pas de précondition, car vérifier dans le code appelant que la liste ait au moins deux valeurs différentes risquerait d'être lent pour certaines listes.

Par contre, dans le cas de get_second_greatest_element qui, quand on lui donne en entrée [3, 4, 5, 5, 5], retourne 5, je lui donne une précondition : posséder au moins deux éléments.

Sauf que dans ce cas là ton API n'est pas "constante". Un coup on accepte des listes vides, un autre coup, il faut au moins 2 éléments, cela en fonction des contraintes algorithmiques liées à l'implémentation. Alors même que les deux fonctions restent très similaires quant à leur but.

C'est à dire que pour comprendre la logique de ton API, il faudrait comprendre l'implémentation des fonctions, ce qu'un utilisateur de l'API ne devrait pas avoir à faire et à s'en soucier.

Et même plus que cela, il faut comprendre quelles sont les pré-conditions, qui ne seront pas forcément "évidentes" en lisant la signature de la fonction. Demander à avoir un type particulier :

• itérable ;
• entier ;
• entier positif ;
• [0; 1] (e.g. probabilité)
• etc.

Est "simple" et peut se comprendre à la signature de la fonction, par contre "une liste d'au moins deux éléments" commence à devenir plus "avancé", et va commencer à nécessiter des noms de variables à rallonge "integer_list_with_at_least_2_elements". Derrière, cela reste une pré-condition relativement "simple", mais quid de pré-conditions plus compliquées, et où va-t-on placer la limite ? C'est une question ouverte, et l'utilisateur de l'API n'aura aucun moyen de savoir où le développeur de l'API l'aura placé.

Par exemple, pour faire un find/indexOf, tu vas généralement retourner null/-1/std::string::npos (en fonction du langage), et ne va pas tester au préalable que l'élément est bien dans la liste.

De plus, tu vas lancer une exception pour quelque chose qui n'est pas une erreur ou un cas exceptionnel. Donc pour moi tu as 4 problèmes :

• une API "non-constante" ;
• un a priori sur l'implémentation ;
• des pré-conditions pas "évidentes" ;
• l'utilisation d'exception qui ne fait pas sens sémantiquement.

[Pyramidev]

Sauf que dans ce cas là ton API n'est pas "constante". Un coup on accepte des listes vides, un autre coup, il faut au moins 2 éléments, cela en fonction des contraintes algorithmiques liées à l'implémentation. Alors même que les deux fonctions restent très similaires quant à leur but.

C'est à dire que pour comprendre la logique de ton API, il faudrait comprendre l'implémentation des fonctions, ce qu'un utilisateur de l'API ne devrait pas avoir à faire et à s'en soucier.

Globalement, j'essaie d'être cohérent. Quand je suffixe ma fonction par OrNull, OrThrow ou autre chose dans ce genre, c'est pour dire ce que je fais dans un cas limite qui aurait été une précondition si la fonction n'avait pas eu ce suffixe et si elle était cohérente avec les autres fonctions de l'API dont le nom n'a pas ce genre de suffixe. Par exemple, si ma fonction get_second_greatest_value_or_null (sans précondition) s'appelait get_second_greatest_value, alors elle aurait eu pour précondition que la deuxième plus grande valeur (par exemple 4 dans [3, 4, 5, 5, 5]) existe, ce qui aurait été cohérent avec get_second_greatest_element qui a pour précondition que le deuxième plus grand élément (par exemple 5 dans [3, 4, 5, 5, 5]) existe.

L'utilisateur n'a alors pas besoin de comprendre l'implémentation des fonctions.

Et même plus que cela, il faut comprendre quelles sont les pré-conditions, qui ne seront pas forcément "évidentes" en lisant la signature de la fonction. Demander à avoir un type particulier :

• itérable ;
• entier ;
• entier positif ;
• [0; 1] (e.g. probabilité)
• etc.

Est "simple" et peut se comprendre à la signature de la fonction, par contre "une liste d'au moins deux éléments" commence à devenir plus "avancé", et va commencer à nécessiter des noms de variables à rallonge "integer_list_with_at_least_2_elements".

Idéalement, une fonction avec un nom comme get_second_greatest_element avec un seul paramètre devrait pouvoir être appelée avec n'importe quel itérable d'au moins deux éléments et dont le type des éléments possède une relation d'ordre totale par défaut. Hélas, l'implémenter ainsi dépasse mes connaissances actuelles du JavaScript.

Derrière, cela reste une pré-condition relativement "simple", mais quid de pré-conditions plus compliquées, et où va-t-on placer la limite ? C'est une question ouverte, et l'utilisateur de l'API n'aura aucun moyen de savoir où le développeur de l'API l'aura placé.

Plus les conditions dans les algorithmes sont tordues et compliquées, plus il est important de faire de la programmation par contrat.

Je me rappelle de certains besoins clients tordus et compliqués pour lesquelles j'avais décomposé une fonction en plein de sous-fonctions pour éviter que la fonction ne fasse 2 kilomètres. Certaines sous-fonctions avaient plusieurs paramètres qui devaient respecter certaines préconditions. Il fallait lire ma documentation pour savoir quelles étaient ces préconditions, car il n'y avait pas la place dans le nom de ces fonctions pour les exprimer.

Mais heureusement que ces préconditions étaient là, car on ne m'avait pas laissé le temps d'écrire les tests unitaires et, dans le code, j'avais fait une erreur d'étourderie (un == entre deux entiers au lieu d'un != ou le contraire, je ne sais plus) qui engendrait un bogue dans un cas rare. Le jour où le bogue est survenu en production, cela s'est manifesté par une violation de précondition. Grâce au message d'erreur, j'ai pu trouver l'origine du bogue directement en lisant le code près de l'appel de la fonction dont la précondition n'était pas respectée, sans avoir besoin de reproduire le bogue en local.

Si, à la place, j'avais décidé que ces sous-fonctions aient un certain comportement par défaut autre que signaler une erreur quand les préconditions n'étaient pas respectées, alors l'origine du bogue aurait été beaucoup plus difficile à analyser le jour où quelqu'un se rendrait compte qu'il y a un bogue.

Par exemple, pour faire un find/indexOf, tu vas généralement retourner null/-1/std::string::npos (en fonction du langage), et ne va pas tester au préalable que l'élément est bien dans la liste.

En général, quand le nom de la fonction commence par find, elle retourne un résultat optionnel. Du coup, tu pourrais renommer ta fonction get_second_greater en find_second_greatest ou find_second_greatest_value, même si je préfère la nommer get_second_greatest_value_or_null.