Cette question porte sur les conventions de codage, les meilleures pratiques et le style du code Common-Lisp de production et de mission critique. J'ai parcouru le guide de style Common-Lisp de Google ( http://tinyurl.com/qfvnqcx ), mais je n'ai rien trouvé qui réponde clairement à ma préoccupation spécifique, que j'exprime par exemple et par contraste avec C/C++, Java, etc. J'ai également jeté un coup d'œil rapide aux bases de code Common-Lisp sur Github, et je n'ai pas vu beaucoup de vérification des arguments et des valeurs intermédiaires, ce que je vois en C/C++, Java, etc.
Dans mon atelier, nous avons l'habitude de vérifier les arguments et les autres valeurs et de sortir prématurément lorsque les arguments ne respectent pas les contrats/conditions préalables, etc. Par exemple, considérez le micro-exemple suivant (artificiel, imparfait, typique, mais s'il vous plaît, ne perdez pas de temps à critiquer, qui présage l'exemple CL) :
ErrorCode o_symb_to_g_symb (char * symb, uint len)
{ if (len < 2) { return ERROR_LENGTH; }
if (symb[0] != 'O' || symb[1] != '!') { return ERROR_SYNTAX; }
char * result = (char *) malloc (len + 1);
if (NULL == result) { return ERROR_MALLOC; }
if (result != strncpy (result, symb, len + 1))
{ return ERROR_STRNCPY; }
result[0] = 'G';
return result; }Cela fait à peu près la même chose que le code de Doug Hoyte dans "Let Over Lambda", page 67, sauf qu'il prend soin de vérifier autant que possible en cours de route ( http://letoverlambda.com/ ).
(defun o!-symbol-to-g!-symbol (s)
(symb "G!"
(subseq (symbol-name s) 2))))La question est de savoir si le code de production du monde réel en Common Lisp fait plus de vérifications. Par exemple, il pourrait être raisonnable d'écrire du code explicite pour vérifier que s est effectivement une chaîne de caractères et qu'elle est effectivement assez longue, et qu'elle a effectivement un "O !" comme deux premiers caractères.
Est-ce que ce code contourne toute cette paranoïa juste parce que c'est pédagogique ? Le même code dans un déploiement de production critique serait-il plus susceptible d'avoir les vérifications de paranoïa (ma légère prospection de Github pour le code CL suggérerait "non") ? Si le code CL du monde réel ne tend pas vers la paranoïa, pourquoi pas ? La pratique des tests de type "corner-case" ou exhaustifs est-elle plus répandue qu'il n'y paraît ?
En bref, je suis assez perplexe quant à la différence de style. Dans le monde réel, le code C critique a tendance à être super-paranoïaque. Je ne vois pas la même chose en CL. Peut-être que je ne regarde pas les bonnes bases de code ? Peut-être n'ai-je pas lu les bons livres ? La réponse à cette question ne semble pas être facile à trouver sur Google.
