C'est moins lisible sorti de son contexte. Par contre à l'utilisation et dans le temps c'est beaucoup plus lisible et moins casse gueule. Même si c'est moins joli graphiquement et plus rébarbatif à lire.
Si ma fonction retourne une liste alors je déclare que ma fonction retourne une liste... Sinon c'est un objet ou un tuple. Maintenant se pose la question quelles sont les objets retournés par ma fonction. De quels types sont-ils ?
Moi plus je sais ce que je manipule, plus c'est agréable à coder même si ca demande plus de lignes "inutiles" dans des exemples triviaux. Dans la vie de tout les jours, 80% du code que je manipule n'a pas été écrit par moi. Je préfère ne pas passer ma vie à essayer de deviner ce que les fonctions que j'appelle sont censées retourner.
Alors quand on parle de Perl, qui ne déclare ni ses arguments si ses types de retour... Ca peut péter (et ca le fera) quand on changera le moindre type d'un argument ou d'un valeur de retour, quand le nombre/ordre des paramètres changera, quand le nombre/ordre des valeurs de retour changera. Vous refactorez jamais ? Vous faites jamais d'erreur dans votre code ? Vous attendez que ça pète à l'exécution pour découvrir que le code est dans un état totalement incohérent ?
Comme toujours c'est marrant sur 100 lignes de code maintenu par une personne.
[^] # Re: javascript
Posté par ckyl . En réponse au journal Perl, Javouille, Lisaac|(Ruby|SmallTalk|etc..). Évalué à 4.
Si ma fonction retourne une liste alors je déclare que ma fonction retourne une liste... Sinon c'est un objet ou un tuple. Maintenant se pose la question quelles sont les objets retournés par ma fonction. De quels types sont-ils ?
Moi plus je sais ce que je manipule, plus c'est agréable à coder même si ca demande plus de lignes "inutiles" dans des exemples triviaux. Dans la vie de tout les jours, 80% du code que je manipule n'a pas été écrit par moi. Je préfère ne pas passer ma vie à essayer de deviner ce que les fonctions que j'appelle sont censées retourner.
Alors quand on parle de Perl, qui ne déclare ni ses arguments si ses types de retour... Ca peut péter (et ca le fera) quand on changera le moindre type d'un argument ou d'un valeur de retour, quand le nombre/ordre des paramètres changera, quand le nombre/ordre des valeurs de retour changera. Vous refactorez jamais ? Vous faites jamais d'erreur dans votre code ? Vous attendez que ça pète à l'exécution pour découvrir que le code est dans un état totalement incohérent ?
Comme toujours c'est marrant sur 100 lignes de code maintenu par une personne.