• [^] # Re: Framework web

    Posté par . En réponse à la dépêche Première beta de POCHE 1.0 disponible. Évalué à 1.

    Les conventions disent d'indenter proprement

    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.

    En fait là je parlais en général. Et puis tu peux utiliser les accolades en Python! :p

    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.

    Lapin compris (j'ai fait très très peu de PHP).

    • 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).

    Ah, j'y avais pas pensé.

    • 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.

    Ok, m'enfin quand même. Si les gens sont pas foutu de comprendre qu'il ne faut pas modifier une variable... (même si je regrette l'absence de const en Python)

    • 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.

    Entièrement d'accord.

    C'est moche les majuscule, et c'est la seule raison pour laquelle j'ai réellement bannit les allcaps

    Ou sinon on privilégie l'efficacité à l'esthéthique, et des fois savoir que c'est une constante au premier coup d'œil ça peut être pratique.

    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.

    En effet.

    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.

    J'avoue que je n'ai pas (encore) rencontré d'exemple de duck typing.

    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.

    En effet, c'est dommage.

    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.

    Si les gens font de la merde aussi, ils peuvent en faire dans tous les langages.

    Pour le reste, on peut utiliser des outils comme Pylint, ou même le compiler vers un autre langage (C, Java, C#).

    Je ne suis pas défenseur à tout prix de Python mais il faut reconnaitre qu'il est pratique pour des petits ou moyens projets.

    Écrit en Bépo selon l’orthographe de 1990