I nomi brevi di metodi / funzioni abbreviati che non utilizzano le parolacce o una questione di stile? [duplicare]

Ho sentito una grande citazione su questa volta, qualcosa del tipo:

Code is written to be read by humans, not computers

Se i computer fossero tutto ciò di cui ci preoccupassimo, scriveremmo ancora assembler, o 1 e 0 per quella materia. Dobbiamo considerare le persone che useranno il nostro codice, come ad esempio una API, o il tizio che viene dopo di noi e mantiene il nostro codice. Quindi, a meno che il linguaggio che stiamo usando lo proibisca, il metodo di parole reali e i nomi di variabili devono essere considerati una buona pratica.

Mi piacerebbe molto per i ragazzi in alto per ottenere enormi quantità di upvotes. In questo modo, almeno, ho la certezza che la comunità globale apprezzerà, in generale, quando scrivo un nome di metodo di 35 caratteri che ne documenta il significato e l'intenzione, senza dover necessariamente cercare i documenti o altre annotazioni di codice. Spero che possiamo anche essere d'accordo sul fatto che i nomi dei metodi del caso di prova di 80 caratteri non sono male, quindi la prossima volta non devo cercare il caso di test per capire perché qualcosa è andato storto.

Sul rovescio della medaglia, preferisco quando i built-in della lingua sono concisi. Ragionamento? Il nucleo linguistico è qualcosa che è così ben noto sia a te che a me, che non è ambiguo. Posso essere d'accordo sul fatto che le persone che si stanno familiarizzando da sole potrebbero non capire repr() , dir() , getattr() off the bat, ma la maggior parte delle lingue moderne ha un ingombro globale molto piccolo che ci vorrebbe una semplice ora per passare completamente attraverso tutti i tipi e le funzioni di base forniti.

Credo ci fosse un altro incentivo a questo. Non vuoi impedire agli sviluppatori di scrivere riferimenti naturali evidenti a qualcosa con cui stanno lavorando. Immagina se len() sia stato scritto come length() , non potresti mai scrivere length = ... dal timore di sovrascrivere il riferimento globale nella tua chiusura. Sono sicuro che ci sono persone che si occupano di problemi in cui representation = ... è una chiamata sana.

In uno scenario più da incubo, immagina se result era una parola chiave riservata o globale. Perché ... piangerei per un vero e proprio impiccagione di chi ha avuto un'idea quella .

Sono molto d'accordo. Se guardo un nuovo codice base, i metodi descrittivi lunghi, i nomi delle classi, ecc. Sono molto apprezzati.

IMHO l'oppressione ottimale di un nome metodo / variabile dovrebbe essere direttamente proporzionale alla dimensione del suo ambito e inversamente proporzionale alla frequenza con cui viene utilizzata. Se una variabile / metodo viene usato N volte in un programma, il costo di memorizzare ciò che effettivamente fa un nome criptico ha overhead O (1) ma una grande costante. Il costo di digitare, leggere e sprecare spazio sullo schermo sul nome più lungo e più dettagliato ogni volta è O (N) ma con una costante più piccola. Se una variabile / metodo ha un ampio scope o è pubblico / globale, allora le probabilità che hai intenzione di comprenderlo e pagare l'overhead O (1) per modificare / capire qualsiasi parte del codice che stai mantenendo sono alto, sostenendo un nome più dettagliato. Se il suo scopo è di 10 righe, solo la persona che gestisce quelle 10 righe deve comprenderlo, sostenendo un nome terser.

Ciò significa che le funzioni di libreria standard utilizzate di frequente (come repr , str , list , ecc.) dovrebbero avere nomi concisi.

Seguo le Linee guida per la progettazione di Microsoft Framework (applicate tramite FxCop) su nomi di variabili e metodi che in pratica dicono che è una cattiva pratica usare nomi abbreviati o acronimi. Tuttavia, penso che sia necessaria una certa discrezionalità. Se l'acronimo è noto, allora dovrebbe andare bene. Anche per cose come loops, le abbreviazioni vanno bene, come ad esempio:

For Each fi As FileInfo in FileInfoArray
Next 

Quindi, per le lingue imperative moderne, penso che sarebbe considerato una cattiva pratica abbreviare i nomi.

Aggiornamento:

Mi spiace, ho interpretato male il tuo esempio. Lo stesso principio si applica ancora ai nomi dei metodi. Vorrei solo abbreviare se l'acronimo è ben noto (come GetCSVFile() , OpenDBConnection() , ecc.). In questi casi praticamente qualsiasi programmatore dovrebbe sapere cosa significano CSV o DB. Tuttavia, non utilizzerei OpenDBConn , OpnDBCn o GetCSVFl . Di nuovo la discrezione e la leggibilità umana sono le chiavi.

Sono d'accordo con te sui nomi. Una delle mie massime preferite è "Favorisci la convenienza della lettura al di sopra del tempo di scrittura", il che significa che stai leggendo un pezzo di codice molto più spesso di quello che stai scrivendo quel pezzo di codice, quindi rendilo il più leggibile possibile senza riguardo al " inconveniente "di digitare un nome lungo. Tendo a scrivere nomi di metodi lunghi. (Ad esempio per il commento sopra a supercalafragalisticexpialadoshus () vs supercala () preferirei molto probabilmente il primo.)

L'unica cosa che vorrei dire però è che repr è una funzione incorporata che quasi assume lo stato di una parola chiave. Esiste un piccolo insieme limitato di funzioni integrate. Puoi fare lo stesso argomento sulle parole chiave, ad esempio cosa significa "se" o "per"? Accettiamo parole / espressioni abbreviate come parole chiave, quindi dovremmo estendere tale accettazione ai built-in.

Nel passato non troppo lontano, le persone si sono sviluppate su sistemi con un numero limitato e impostato di caratteri disponibili sullo schermo. Nei sistemi legacy, questo è ancora il caso. È una caratteristica di molti, molti standard di codifica (inclusi i Python PEP ufficiali) che le linee non devono superare un certo numero di caratteri.

I nomi dettagliati e i nomi lunghi lo rendono difficile. Quando ti è permesso solo 79 caratteri su una linea, e da 8 a 12 potrebbero essere spazi bianchi in Python, quindi avere un nome di 4 piuttosto che tredici caratteri fa la differenza.

PEP pertinente - link

Il completamento automatico di solito non funziona bene nei linguaggi dinamici, quindi avere nomi brevi per le cose che ti servono spesso ha un senso. Detto questo, preferisco leggere i nomi lunghi, nella maggior parte dei casi.

I nomi dei metodi brevi erano importanti nel tempo di 128k o meno di memoria, dove letteralmente ogni byte contava. Oggi, non c'è assolutamente alcun motivo per utilizzare i nomi abbreviati criptici per i metodi quando nomi più lunghi e più descrittivi non hanno costi pratici.

I vecchi nomi dei comandi Unix tendono ad essere brevi e criptici perché sono stati spesso digitati su un Teletype o qualche altro terminale lento. Dover digitare spesso cinque o sei lettere in più potrebbe richiedere notevoli quantità di tempo.

Attualmente sto digitando questo sulla console di un computer con Gigabit Ethernet con connessioni ad alta velocità su Internet, quindi scrivo nomi di variabili significativi. A meno che tu non abbia effettuato l'aggiornamento a un modem a 1200 o superiore, fai altrettanto.

Francamente, repr() non è un segno di panico. Immagina di gestire nomi di funzioni come mds_rcv_scv_ckb_sync() , ora questo è un allenamento extrasensoriale. L'incubo arriva quando il codice non è documentato. Non ci sono informazioni su cosa funzioni. Anche se non mi piacciono le definizioni crittografate, devo ancora scrivere codice usando questi. Con gli strumenti di oggi, come il completamento del codice, i riferimenti incrociati, la leggibilità è un po 'più semplice, dato che i metodi sono documentati. Puoi solo Ctrl + Spazio e vedere l'elenco delle funzioni insieme alla documentazione corrispondente.
D'altra parte, funzioni come GetTheLatestWebSiteAccessTimeInMilliseconds() sono un altro caso estremo.
Mi piacciono le linee guida di Microsoft che utilizzano in .NET.

Precedenti o tradizione. Atoi per esempio è una funzione piuttosto classica che è un'abbreviazione che sospetto che molte persone semplicemente assorbano come parte di un vecchio linguaggio come C. Sarebbe un argomento che potrei vedere alcune persone fare anche se nelle lingue più recenti questo non dovrebbe essere un grosso problema. Malloc sarebbe un'altra di quelle funzioni esoteriche se qualcuno volesse un altro esempio. La maggior parte di questo è stata sostituita con nuovi linguaggi e strumenti, ma potrebbero esserci alcuni vecchi che si aggrappano a cose come notazione ungherese che può causare incubi visto quanto può fare cose brutte negli strumenti moderni. Non ho mai detto che questa fosse una buona argomentazione, solo che potrei immaginarmi alcune persone che la esprimono.

Non voglio che il commento faccia parte del nome grazie. Conciso è buono!

I dizionari sono concisi. Per usarne una completamente, devi leggere alcune delle loro abbreviazioni specialistiche per cose che vengono usate molte volte. Allo stesso modo, vedere una variabile chiamata "incrementatore" nell'origine sarebbe peggio di usare semplicemente "i".

Molte finestre e nomi di librerie Java sono troppo lunghi. Se vuoi sapere che cosa fa, leggi il codice che lo circonda - non aspettarti che venga detto - correttamente, basta con il suo nome.

Molti codici Microsoft e Java sono resi impenetrabili mentre ti trovi di fronte a una complessa rete di fonti peggiorata dagli identificatori troppo lunghi.

Almeno Microsoft aveva il buonsenso di usare un nome breve e accattivante per la funzione linq piuttosto che languageIntegratedQuery: -)