Quand on voit le prototype d'une fonction, on ne sait même pas de quel type sont les arguments !
Si la fonction n'est pas documentée, en effet. On peut penser que si la fonction n'est pas documentée, elle ne fait pas partie d'une API publique :-)
Autre exemple, quand on veut faire du refactoring, renommer une méthode, une classe, etc. J'ai donné l'exemple dans le journal de la méthode « show ». Vas-y pour trouver tous les appels de la méthode show dans un code volumineux... Avec une bonne greppabilité du code, et une compilation pour détecter les erreurs, aucun soucis.
Les tests unitaires remplissent la fonction de la phase de compilation, de ce point de vue (tout en allant beaucoup plus loin car les tests ne se limitent pas à vérifier que les types conviennent).
Quant à la "greppabilité" du code, c'est plus une question de style objet (namespaces imbriqués, avec des noms souvent réutilisés) vs. style procédural (tout à plat, avec des noms très distinctifs). On peut très bien n'utiliser que des fonctions globales en Python.
Ceci dit si tu penses que C est mieux pour lire du code existant, je te suggère de lire, au hasard, le code d'OpenSSL :-)
[^] # Re: C vs Python pour des applis Gnome
Posté par Antoine . En réponse au journal Quelques langages de programmation pour GNOME. Évalué à 4.
Si la fonction n'est pas documentée, en effet. On peut penser que si la fonction n'est pas documentée, elle ne fait pas partie d'une API publique :-)
Les tests unitaires remplissent la fonction de la phase de compilation, de ce point de vue (tout en allant beaucoup plus loin car les tests ne se limitent pas à vérifier que les types conviennent).
Quant à la "greppabilité" du code, c'est plus une question de style objet (namespaces imbriqués, avec des noms souvent réutilisés) vs. style procédural (tout à plat, avec des noms très distinctifs). On peut très bien n'utiliser que des fonctions globales en Python.
Ceci dit si tu penses que C est mieux pour lire du code existant, je te suggère de lire, au hasard, le code d'OpenSSL :-)