Exemple: C'est vraiment ennuyeux de taper une liste de chaînes en python: Je fais souvent quelque chose comme ça pour me sauver avoir à taper des guillemets sur la place: P > map(tuple, "a9 43 zx".split())
13 Réponses :
Je trouverais cela acceptable, si un peu paresseux, tant que ce qui est fait n'est pas trop performant. Vous pouvez toujours revenir en arrière et l'optimiser si vous avez besoin de plus de vitesse.
Je ne vois pas comment quelque chose comme ça pourrait jamais être un goulot d'étranglement de la performance. Sauf si vous faites cela à des milliers et des milliers de lignes de texte.
Le code est généralement lu plusieurs fois, et il est écrit qu'une seule fois.
L'épargne temps d'écriture au détriment de la lisibilité n'est généralement pas un bon choix, à moins que vous fassiez un code de jeton.
La deuxième version est moins explicite et vous avez besoin de temps pour comprendre ce que fait le code. Et nous parlons simplement d'instanciation variable et non d'algorithmes!
Le problème avec les deux exemples est qu'ils ont l'air bizarre à d'autres programmeurs, les longues chaînes ne communiquent pas immédiatement la liste de choses comme les matrices. Par conséquent, ils forcent au moins une double prise, même pour ces petits exemples. Très, très mauvais style.
Oui, j'utilise régulièrement et approuve (dans les critiques de codes et les critiques de lisibilité) Les "quelques mots vont ici" .split () idée, mais le second que je veto comme sérieusement illisible.
J'aime le premier exemple, déteste la seconde.
En général, je pense que c'est une mauvaise idée. Le premier exemple n'est pas si mauvais (il est en quelque sorte un substitut du manque de QW de Python), mais la seconde est beaucoup plus difficile à comprendre. En particulier, je pense que ce type de chose est très inconvenant, et certainement pas approprié lors de la rédaction de code Python, en tout cas. La lisibilité du code est beaucoup plus importante que d'économiser un peu de temps à écrire le code. Si vous avez vraiment autant de données sur HARDCODE, écrivez un script pour le générer pour vous.
Combien de fois avez-vous vraiment besoin de taper accordé votre approche pourrait vous faire gagner du temps, mais pourquoi ajouter une complexité à votre code sans bonne raison que vous êtes un peu paresseux?
Si vous devez vraiment le taper aussi souvent ... Copy-coller! ["janvier", "février" ... etc] ?
Oups je me suis battu à quelques reprises!
Oui, ne faites pas de publicité "Copy-coller" à moins que vous n'êtes à battre, il est considéré comme mal (et pour les bonnes raisons) ;-)
Je savais que cela me ferait des ennuis: p
... Je fais souvent quelque chose comme ça pour me sauver avoir à taper des guillemets partout ...
Je pense que une telle chose ne devrait être faite qu'une fois par programme. Si vous faites la même chose "partout sur la place", alors peu importe laquelle utilisez-vous, vous créez un monstre.
Cette déclaration ne doit être écrite qu'une seule fois pour tout le code.
bon pt, mais par "partout sur la place" je voulais dire "tout au long de cette prochaine ligne"
C'est une chose raisonnable à faire pour des données que vous ne vous attendez pas à changer, telles que des mois ou des jours de plusieurs semaines. Il est également raisonnable de le faire tout en se moquant d'interactions avec des fichiers ou des bases de données, car il isole votre code de test. Cependant, ce n'est pas une bonne solution à long terme pour le code de production, et ne vous sauve pas beaucoup de temps. Tout ce qui est assez important pour permettre aux grandes économies de temps, il est suffisamment important pour exiger de stocker des données quelque part d'autres, comme un fichier séparé d'une base de données.
Dans le code de production, faites-le de la bonne manière. Dans le code de test, tant que cet idiome apparaît plus d'une ou deux fois, je pense que cela est acceptable. Si, dans le code de test, cette situation apparaît une ou deux fois, faites-la de la bonne manière.
Un bon éditeur de texte peut faire ces choses un non-problème. Par exemple, je peux taper la ligne suivante dans mon code: puis à l'aide de la séquence de clé J'utilise Vim pour mon exemple, mais je suis sûr que c'est tout aussi facile avec Emacs, Textmate, c. V :! Python
Lesquotes sont-ils nécessaires? Je trouve que la même chose est produite avec et sans backuotes.
@mhawke merci d'avoir souligné cela. J'utilisais des backuotes juste pour vous assurer que la sortie était une structure de données Python valide, mais elle semble que ce n'est pas nécessaire pour les listes.
+1, non pour les éditeurs spécifiques, mais pour utiliser l'interprète Python pour produire une représentation de structure de données calculée.
Je ne pense pas que ce type de chose devrait être dans la source.
Si j'étais vous, j'aurais Python d'évaluer les deuxième versions respectives, puis collez les résultats dans mon code source.
Dans un éditeur raisonnablement intelligent, vous pourriez:
par " " pour le 1er ex.),
- Vérifiez la case à cocher les lignes sélectionnées,
- Cliquez sur Remplacer tout,
- Bam .. votre fait.
lisible et facile à taper ... Respectez la puissance de l'éditeur!
Que voulez-vous dire lisible? On dirait que vous faites simplement référence à la fonction de recherche et remplacez la fonctionnalité trouvée dans chaque éditeur depuis le bloc-notes ...
Lisible fait référence au code résultant, c'est-à-dire une grande chaîne qui ne communique pas "la liste des éléments", comme directement la syntaxe de liste intégrée.
Je pense mettre des déclarations comme
"Janvier février mars avril mai juin juillet août ...". Split ()
au niveau du module global est bien. De cette façon, il n'est exécuté qu'une seule fois lors de l'importation. Je l'utilise même parfois dans des fonctions critiques non performantes en raison du bruit de la ligne réduit.
sur un Sidenote, je pense que les interprètes de Python pourraient être faits pour exécuter la "Split ()" au moment de la compilation qui éradiquerait la méthode des appels de méthode. La raison étant qu'une chaîne est un littérale intégré et python ne permet pas d'ajouter / remplacer des méthodes sur le type de chaîne de base, de sorte que le compilateur puisse savoir que "" .split () ne peut faire que référence à une méthode spécifique.
Vos méthodes rapides et intelligentes tandis que bien, prenez plus de temps à lire ce qui n'est pas bon. La lisibilité vient toujours toujours.
Combien du temps que vous avez économisé avez-vous utilisé posé cette question?
Je vote pour le deuxième exemple.
Je fais ce genre de chose de temps en temps, mais quand le faire, c'est décidé au cas par cas. Votre deuxième exemple est trop étendu pour moi.