Comments on: Comment garder des lignes courtes ?

By: Louis

Louis — Tue, 02 May 2017 13:57:12 +0000

@Brice : Aucun c’est pour un projet perso. Je fais des lignes comme ça plus par défi que par conviction.

By: Brice

Brice — Tue, 02 May 2017 08:26:45 +0000

@Louis : Et y’a combien de relecteurs qui se sont suicidés à cause de toi?

@entwanne : il faut limiter ce commentaire aux cas où c’est vraiment un commentaire. On ne l’écrit pas (uniquement) pour désactiver un linter, mais pour informer le lecteur de la volonté express d’écrire une ligne de code qui en général n’est pas souhaitable. Genre :

from shared_settings import * # noqa

Ce noqa signifie : Je sais qu’en général il est vilain de faire un import *, mais en l’occurrence, c’est exactement ce que je veux faire, c’est pas une erreur.

By: Heretron

Heretron — Mon, 01 May 2017 10:27:35 +0000

Je pense que la limite de 79 caractères est un des trucs que je préfère en python.

C’est comme lire du texte sur un livre de poche vs du A4 imprimé en paysage. Les magazines / journaux l’ont bien compris, le texte est sur de petites colonnes en général. En C++/Java/Whatever les gens ont la sale habitude de faire des lignes de 3km, ça demande une charge mentale énorme à la compréhension, on passe son temps à se focaliser sur des détails et ça demande des heures pour comprendre l’image générale.

@Louis: C’est justement parce que c’est pénible qu’il faut le faire ! :)

Tu t’es frappé la compréhension pour l’écriture du code, tu peux épargner ce travail à tes relecteurs.

L’idée c’est aussi d’avoir une seule action par ligne.

Je suis en train de décortiquer ton code depuis 5min pour arriver à me l’approprier.


str(self):
return '\n'.join(['\t'.join([str(val) for val in [clef.ljust(max([len(key) for key in self.dict])), valeur]]) for clef, valeur in self.dict.items()])

De base j’ai un ascenseur horizontal, rien ne t’empêche de coller des sauts de ligne dans cette expression, tu es au milieu de parenthèses / crochets.

En faisant des lignes courtes je remarque que ton affaire pourrait être plus simple :

– tu as une boucle for inutile pour coller un tab entre la clée paddée et la valeur

– tu converti la clé en str via ljust et via str()

– tu calcules plein de fois la longueur max d’une clé, en passant en variable c’est plus explicite et tu fais le calcul une seule fois.


def str(self):
maxkeylen = max([len(key) for key in self.dict])
return '\n'.join([
clef.ljust(maxkeylen) + '\t' + str(valeur)
for clef, valeur in self.dict.items()
])

Ton exemple se prête un peu trop bien au jeu pour illustrer, si tu as des cas plus tordus fais péter ! :)

PS: Sam, je crois bien que c’est 79 et pas 80 caractères

https://www.python.org/dev/peps/pep-0008/#maximum-line-length

By: Louis

Louis — Mon, 01 May 2017 07:50:53 +0000

@Cym13: Pour ne pas encombrer la mémoire et pour faire tenir mes fonctions sur moins de 5 lignes. (En fait c’est parce que c’est pénible de trouver un nom au variable, donc si c’est pour appeler mes variables intermédiaires a, b ou c ça vaut pas la peine ;-)

By: Cym13

Cym13 — Sun, 30 Apr 2017 21:58:17 +0000

@Louis: Euh… Pourquoi au juste ? Quel est l’intérêt de ne pas nommer ces valeurs intermédiaires que l’on doit de toute manière se farcir pour comprendre la fonction ? Donner un bon nom aux choses est une aide précieuse, notamment lorsqu’il s’agit de déterminer si un comportement est attendu ou non dans du code que l’on a pas écrit.

By: Louis

Louis — Sat, 29 Apr 2017 16:40:21 +0000

Perso j’essaye d’utiliser le minimum de variable possible.

Je ne créé une variable que si elle peut factoriser au moins trois fois une expression.

Du coup ça fait des lignes un peu longue. Par exemple une méthode qui affiche la liste des attributs d’un objet de manière allignée et indentée correctement.

def str(self):

….return ‘\n’.join([‘\t’.join([str(val) for val in [clef.ljust(max([len(key) for key in self.dict])), valeur]]) for clef, valeur in self.dict.items()])

By: Sam

Sam — Fri, 28 Apr 2017 21:55:24 +0000

Merci aux correcteurs.

By: Cym13

Cym13 — Fri, 28 Apr 2017 17:24:43 +0000

Maintenant que j’y pense c’est sans doute aussi plus performant d’écrire sur 80 colonnes. Je pense aux outils unix qui travaillent essentiellement sur des lignes:

grep donnera des résultats plus ciblés donc moins d’écritures différentes
git aura moins à stocker dans ses diffs
les outils de rendu type terminal n’ont pas de retour à la ligne à calculer
…

Ok, c’est peanuts, mais bizarrement il y a toujours quelqu’un pour prendre l’argument de l’optimisation inutile ;)

By: r00tBSD

r00tBSD — Fri, 28 Apr 2017 15:55:05 +0000

Très bon article, merci !

By: Alphonse la Défonce

Alphonse la Défonce — Fri, 28 Apr 2017 14:51:27 +0000

Sam je t’aime. Excellentes justifications à l’emploi de <80 caractères – perso j’ai souvent 3 à 5 colonnes juxtaposées sur un même écran, parfois même pour visualiser en même temps 2 portions d’un même fichier. L’argument des micro sauts oculaires paraît capillotracté, mais t’as bien fait de le citer en 1er parce que c’est putain de vrai.

Coquilles :

1) “Dois fois” au tout début => je pense que tu voulais écrire “des fois”, allez, écris-donc “parfois” et on n’en parle plus.

2) “Jamais vous ne vous retrouverez comme dans d’autres langages face au code de votre collègue, ce gros porc, aligne ses accolades avec le groin.” => il manque des mots genre “face au code [adjectif_bien_senti] de votre collègue, qui, ce gros porc, …”

3) anventageusement au lieu d’avantageusement mais ça a déjà été remarqué je crois