[Haskell-fr] Demande de revue de code

[Arnaud Bailly]

Bonjour Gautier,
Je ne vois pas trop la partie TDD, je trouve personnellement les tests peu
expressifs. IMHO illustrer le TDD en Haskell implique de partir de
Quickcheck. Tes tests sur l'égalité et les propriétés des Temperatures
pourraient tirer parti de cet outil par exemple. Par ailleurs si tu veux
utiliser HSpec alors je te suggérerai de "suivre le grain" de l'API.

describe "Both Fahrenheit" $ do
                it "same" $ do

c'est pas trés "beau", il serait plus logique d'avoir quelque chose du
genre:

describe "Both Fahrenheit" $ do
                it "should be equal given same value" $ do
                it "should be different given different values" $ do

Mais encore une fois, l'exemple choisi se prêterait pas mal à l'utilisation
de quickcheck.

Dans le code principal, je ne vois pas trop le problème que tu as avec ta
classe: j'arrive à compiler ce code sans problème en rajoutant les flags
qui vont bien (ghc me le dit...).

Je ne suis pas sûr non plus que l'utilisation intensive d'une notation
"point-free" aide à la compréhension.... Surtout avec un pipeline de 10
fonctions. Je te suggérerai de détailler chaque partie de la fonction.

Une approche que j'aime bien utiliser et qui fonctionne bien en Haskell
c'est de partir de la fonction principale qui ne fait rien, puis de la
décomposer.


Cordialement,

--
Arnaud Bailly
FoldLabs Associate: http://foldlabs.com


2014-04-03 16:10 GMT+02:00 Gautier DI FOLCO <gautier.difolco at gmail.com>:

> Le 3 avril 2014 11:00, Gautier DI FOLCO <gautier.difolco at gmail.com> a
> écrit :
>
> Le 3 avril 2014 10:44, Sylvain Henry <hsyl20 at gmail.com> a écrit :
>>
>> Pour l'immutabilité, je montrerais les Lenses.
>>>
>>
>> Bonne idée
>>
>>
>>> Eviter d'utiliser des listes partout, notamment dans DayStmt, WeekStmt
>>> et MonthStmt, vu que le nombre de champs est fixe.
>>>
>>
>> Pas forcément, tu ne peux avoir que les relevés de 40 jours par exemple,
>> ce qui fais que tu as un mois et une semaine incomplète.
>>
>>
>>> Utiliser des lenses ici serait pas mal, surtout pour réécrire la
>>> fonction finale. Si je comprends bien elle fait une sélection et une
>>> réduction, donc parfait avec des lenses.
>>>
>>
>>
>>
>>> Je ne suis pas convaincu par le Monoid, une simple fonction de réduction
>>> suffirait :
>>> toStats :: [Temperature] -> Statistics
>>> Là c'est compliqué inutilement je trouve.
>>>
>>
>>  Du coup tu perds la notion de groupes de relevés (jour, semaines, mois)
>> et tu te retrouve à gérer le "conflit" °C/°F en même temps que le calcul
>> des stats.
>>
>
> si je donne l'impression de vous rembarrer pour le plaisir, il n'en est
> rien, je tente juste d'exposer mes choix et de comprendre ce qui ne va pas
> (et j'ai l'impression de mal m'exprimer).
> Le but c'est de montrer le TDD, il y a un aspect incrémental à mettre en
> valeur et arriver à quelque chose de complexe en partant de choses simple à
> mettre en valeur.
> Le coding dojo en lui même n'est pas spécifiquement fonctionnel (je pense
> qu'on sera 3/20 à coder dans un langage fonctionnel, au sens large), mon
> but est de dire : la POO ne résout pas tout proprement, regardez en FP.
> Je pense mes intentions sont plus claires.
>
> _______________________________________________
> Haskell-fr mailing list
> Haskell-fr at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-fr
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-fr/attachments/20140403/14d76679/attachment.html>