Qual è la differenza tra "leggibilità del codice" e "convenzioni linguistiche" utilizzate all'interno di una comunità? [chiuso]

Question

Qual è la differenza tra "leggibilità del codice" e "convenzioni linguistiche" utilizzate all'interno di una comunità? [chiuso]

#1 da (3 voti)
#2 da (1 voti)
#3 da (1 voti)

4

Quando guardo alle domande poste su siti come StackOverflow su come rendere un particolare pezzo di codice "più pythonic" di solito ci sono suggerimenti offerti per usare complesse liste di comprensione o generatori o altre caratteristiche di Python che non sono disponibili in , per esempio, Java.

Sono un programmatore Python casuale, ea volte non riesco a seguire quello che sta succedendo senza scartare con cura la logica nella mia testa. A volte le intese delle liste sono nidificate in modi che sto pensando "probabilmente dovresti scriverlo usando i loop".

Ovviamente, gli utenti veterani di Python probabilmente non avranno un problema con questo, ma ho sempre più l'impressione che "il codice pythonic" sia preferito rispetto alla scrittura di codice che potrebbe essere letto per il "programmatore medio" che potrebbe non essere molto abile in Python.

In generale, quali sono le linee guida e le euristiche da seguire quando si sceglie tra la leggibilità del codice e le convenzioni utilizzate in una specifica comunità linguistica di programmazione?

python

posta That Umbrella Guy 19.12.2013 - 23:20

fonte

3 risposte

Leggi altre domande sui tag python

Java-Like 'getta' le informazioni nella firma del metodo C # È una pratica accettabile ottenere una proprietà, che coinvolga l'analisi binaria, che potrebbe generare un'eccezione?

score 3 · Answer 1

Sometimes the list comprehensions are nested in ways that I'm thinking "you probably should just write it out using loops".

Se dovessi rifattorizzare il codice in quel modo, molto probabilmente porterebbe alla sostituzione di un male con un altro. IMHO è meglio non sostituire le intese delle liste troppo profondamente annidate con i cicli (ancora troppo profondamente annidati). Invece, rimpiazza le intese degli elenchi troppo profondamente nidificati con non tanto profondamente le intese degli elenchi annidati. Questo ti dà la possibilità di aggiungere "spiegando le variabili" con nomi chiari per risultati intermedi, e puoi ancora pensare in "set", che produce molto meno "rumore" dei loop, ed è ancora "pythonic".

score 1 · Answer 2

Se stai "scartando con cura la logica" per dare un senso a una linea di codice, l'autore ha mancato la barca di essere Pythonic. Essendo Pythonic non si tratta di utilizzare le caratteristiche del linguaggio oscuro per mettere tutto il codice possibile in una linea - questo è ciò che Perl è per. Essere Pythonic significa mantenere il codice semplice, leggibile ed efficiente.

>>> import this

The Zen of Python, by Tim Peters

Beautiful is better than ugly.

Explicit is better than implicit.

Simple is better than complex.

Complex is better than complicated.

Flat is better than nested.

Sparse is better than dense.

Readability counts.

Special cases aren't special enough to break the rules.

Although practicality beats purity.

Errors should never pass silently.

Unless explicitly silenced.

In the face of ambiguity, refuse the temptation to guess.

There should be one-- and preferably only one --obvious way to do it.

Although that way may not be obvious at first unless you're Dutch.

Now is better than never.

Although never is often better than right now.

If the implementation is hard to explain, it's a bad idea.

If the implementation is easy to explain, it may be a good idea.

Namespaces are one honking great idea -- let's do more of those!

score 1 · Answer 3

Se non riesci a leggerlo, non puoi eseguirne il debug o mantenerlo.

'altro codice' Pythonic 'che non puoi mantenere è inutile, quindi per te usare le caratteristiche più complesse è una cattiva idea, non importa quanto sia elegante la risposta in termini di linguaggio.