Ce n'est pas une convention. Un programme Python est naturellement indenté, car l'indentation est utilisée pour distinguer les blocs de code, là où le C (et inspirés) utilise des accolades.
de mettre les noms de constantes en capitales
Ce qui est un aberration. Il ne peut pas y avoir de constante en Python, donc aucune variable ne peut voir son nom être capitalisée... à moins d'utiliser un décorateur, j'avoue.
Ceci dit, j'ai arrêté de capitaliser les constantes :
en PHP, il ne peut y avoir de collision variable/constante, donc l'absence de $ ou de () suffit à distinguer une constante des autres symboles.
en C/C++, les macros devraient être en captales. Si en C les constantes sont par incidence des macros (#define), ce n'est pas la culture en C++ (où on utilisera const sur des données statiques membres ou des variables globales). Je sais, un vilain peut toujours faire un const_cast, mais il faut le taper, et ça se voit (et je ne crois pas qu'un const_cast sur une globale constante soit un comportement définit).
en Python, parce que finalement, il y a toujours un couillon pour venir affecter une nouvelle valeur à ta constante. Je préfère encapsuler et fournir des copies de la valeur, histoire d'être certain que personne ne vienne y foutre le bordel.
en JavaScript, comment dire, c'est, hmmm
en SQL, j'ai même arrêter d'écrire les clauses en majuscules. Un jour, j'essaierai de comprendre pourquoi tout le monde écrit ses requêtes en majuscules.
C'est moche les majuscule, et c'est la seule raison pour laquelle j'ai réellement bannit les allcaps.
Je t'écoute.
Les pythonistes prétendent privilégier l'explicite sur l'implicite. D'où découle, entre autres absurditées, l'inutile self comme argument de chaque fonction membre.
Pourtant, il y a des choses implicites. Par exemple, les invariables sont copiés quand passés en argument, ou encore assigné à une variable. Le ducktyping : il n'y a pas plus implicite que le ducktyping, puisque tu suppose que l'objet qui t'es donné réagi comme tu t'y attends. L'absence totale de typehinting : ce qui est explicite, c'est de dire quel type/interface tu attends en argument, pas de le dire vaguement dans le doc ou laisser le plaisir de la lecture de la fonction.
et de ne pas utiliser des variables membres préfixées de _ en dehors de la classe (en plus c'est pratique de le savoir au sein de la classe en un coup d'œil).
Et pourquoi ne pas utiliser l'hungarian notation tant qu'on y est ? J'utilise _ pour préfixer, j'ai même essayer _classname_varname pour améliorer ça, mais ça reste encore de la convention, on peut saloper depuis l'extérieur de la fonction.
C'est pas dur. Mauvais dèv, changer de dèv.
Entendons-nous bien, je considère qu'un langage de programmation est un outil pour exprimer des idées, des concepts. S'il faut passer des heures pour une erreur de typo (oh, mais c'est length, pas lenght) parce que le langage est laxiste, je dis non. je veux que mon programme échoue le plus tôt possible, pour que je puisse corriger les problèmes, je ne veux pas que le programme tombe en marche et erre dans un état indéterminé.
On peut ensuite s'amuser à contrôler chaque argument de chaque fonction, qu'il expose la bonne interface, que l'attribut machin expose la bonne interface, etc. Mais franchement, pourquoi est-ce que c'est à moi de contrôler ça manuellement en 3 lignes de code alors que le langage peut être utilisé à cette fin ?
[^] # Re: Framework web
Posté par LupusMic (site web personnel, Mastodon) . En réponse à la dépêche Première beta de POCHE 1.0 disponible. Évalué à 5.
Ce n'est pas une convention. Un programme Python est naturellement indenté, car l'indentation est utilisée pour distinguer les blocs de code, là où le C (et inspirés) utilise des accolades.
Ce qui est un aberration. Il ne peut pas y avoir de constante en Python, donc aucune variable ne peut voir son nom être capitalisée... à moins d'utiliser un décorateur, j'avoue.
Ceci dit, j'ai arrêté de capitaliser les constantes :
en SQL, j'ai même arrêter d'écrire les clauses en majuscules. Un jour, j'essaierai de comprendre pourquoi tout le monde écrit ses requêtes en majuscules.
C'est moche les majuscule, et c'est la seule raison pour laquelle j'ai réellement bannit les allcaps.
Les pythonistes prétendent privilégier l'explicite sur l'implicite. D'où découle, entre autres absurditées, l'inutile self comme argument de chaque fonction membre.
Pourtant, il y a des choses implicites. Par exemple, les invariables sont copiés quand passés en argument, ou encore assigné à une variable. Le ducktyping : il n'y a pas plus implicite que le ducktyping, puisque tu suppose que l'objet qui t'es donné réagi comme tu t'y attends. L'absence totale de typehinting : ce qui est explicite, c'est de dire quel type/interface tu attends en argument, pas de le dire vaguement dans le doc ou laisser le plaisir de la lecture de la fonction.
Et pourquoi ne pas utiliser l'hungarian notation tant qu'on y est ? J'utilise _ pour préfixer, j'ai même essayer _classname_varname pour améliorer ça, mais ça reste encore de la convention, on peut saloper depuis l'extérieur de la fonction.
Entendons-nous bien, je considère qu'un langage de programmation est un outil pour exprimer des idées, des concepts. S'il faut passer des heures pour une erreur de typo (oh, mais c'est length, pas lenght) parce que le langage est laxiste, je dis non. je veux que mon programme échoue le plus tôt possible, pour que je puisse corriger les problèmes, je ne veux pas que le programme tombe en marche et erre dans un état indéterminé.
On peut ensuite s'amuser à contrôler chaque argument de chaque fonction, qu'il expose la bonne interface, que l'attribut machin expose la bonne interface, etc. Mais franchement, pourquoi est-ce que c'est à moi de contrôler ça manuellement en 3 lignes de code alors que le langage peut être utilisé à cette fin ?