Quando un nome di metodo Java è troppo lungo? [chiuso]

Nelle ultime settimane ho visto alcuni ragazzi usare nomi molto lunghi per un metodo o una classe (50 caratteri), questo di solito è sotto la premessa che migliora la leggibilità, la mia opinione è che un nome lungo come questo sia un indicatore che siamo cercando di fare molto o troppo in una classe di metodi se abbiamo bisogno di un nome così lungo, tuttavia volevo sapere cosa ne pensate voi ragazzi.

Un esempio è:

getNumberOfSkinCareEligibleItemsWithinTransaction

Un nome in Java, o in qualsiasi altra lingua, è troppo lungo quando esiste un nome più breve che trasmette ugualmente il comportamento del metodo.

Alcune tecniche per ridurre la lunghezza dei nomi dei metodi:

1. Se l'intero programma, classe o modulo riguarda gli "articoli per la cura della pelle", è possibile abbandonare la cura della pelle. Ad esempio, se viene chiamata la tua classe SkinCareUtils, questo ti porta agetNumberOfEligibleItemsWithinTransaction

2. Puoi cambiare all'interno di in ,getNumberOfEligibleItemsInTransaction

3. Puoi cambiare Transazione in Tx, che ti porta a getNumberOfEligibleItemsInTx.

4. Oppure, se il metodo accetta un parametro di tipo, Transactionè possibile eliminare completamente InTx:getNumberOfEligibleItems

5. Si cambia numero di conteggio: getEligibleItemsCount

Questo è molto ragionevole. Ed è più corto del 60%.

Solo per cambiare, una risposta non soggettiva: 65536 caratteri.

A.java:1: la rappresentazione UTF8 per la stringa "xxxxxxxxxxxxxxxxxxxx ..." è troppo lunga per il pool costante

;-)

Sono d'accordo con tutti: i nomi dei metodi non dovrebbero essere troppo lunghi. Voglio aggiungere un'eccezione però:

I nomi dei metodi di test JUnit, tuttavia, possono essere lunghi e dovrebbero assomigliare a frasi.

Perché?

• Perché non vengono chiamati in altri codici.
• Perché sono usati come nomi di test.
• Perché possono quindi essere scritti come frasi che descrivono i requisiti. (Ad esempio, utilizzando AgileDox )

Esempio:

    @Test
    public void testDialogClosesDownWhenTheRedButtonIsPressedTwice() {
        ...
    }

Vedi " Behavior Driven Design " per maggiori informazioni su questa idea.

Il contesto "... WithinTransaction" dovrebbe essere ovvio. Questo è l'orientamento agli oggetti.

Il metodo fa parte di una classe. Se la classe non significa "Transazione" - e se non ti salva dal dover dire sempre "WithinTransaction", allora hai dei problemi.

Tendo ad usare la regola haiku per i nomi:

 Seven syllable class names 
 five for variables
 seven for method and other names

Queste sono le regole empiriche per i nomi massimi. Violo questo solo quando migliora la leggibilità. Qualcosa come recalculateMortgageInterest (currentRate, quoteSet ...) è meglio di recalculateMortgageInterestRate o recalculateMortgageInterestRateFromSet poiché il fatto che coinvolge tariffe e un insieme di virgolette dovrebbe essere abbastanza chiaro dai documenti incorporati come javadoc o l'equivalente .NET.

NOTA: non è un vero haiku, in quanto è 7-5-7 anziché 5-7-5. Ma preferisco ancora chiamarlo haiku.

Java ha una cultura di incoraggiamento dei nomi lunghi, forse perché gli IDE hanno un buon completamento automatico.

Questo sito afferma che il nome della classe più lunga in JRE è InternalFrameInternalFrameTitlePaneInternalFrameTitlePaneMaximizeButtonWindowNotFocusedStatelungo 92 caratteri.

Per quanto riguarda il nome del metodo più lungo ho trovato questo supportsDataDefinitionAndDataManipulationTransactions, che è di 52 caratteri.

Non usare mai una parola lunga quando lo farà un diminutivo.

Non credo che la tua tesi su "la lunghezza del nome del metodo sia proporzionale alla lunghezza del metodo" trattiene davvero l'acqua.

Prendi l'esempio che dai: "getNumberOfSkinCareEligibleItemsWithinTransaction". Mi sembra che faccia solo una cosa: conta il numero di elementi in una transazione che rientrano in una determinata categoria. Ovviamente non posso giudicare senza vedere il codice effettivo per il metodo, ma a me sembra un buon metodo.

D'altra parte, ho visto molti metodi con nomi molto brevi e concisi che fanno strada a molto lavoro, come "processSale" o il sempre popolare "doStuff".

Penso che sarebbe difficile dare una regola rigida sulla lunghezza del nome del metodo, ma l'obiettivo dovrebbe essere: abbastanza lungo da trasmettere ciò che fa la funzione, abbastanza corto da essere leggibile. In questo esempio, penso che probabilmente "getSkinCareCount" sarebbe stato sufficiente. La domanda è cosa devi distinguere. Se hai una funzione che conta gli articoli idonei per la cura della pelle nelle transazioni e un'altra che conta gli articoli idonei per la cura della pelle in qualcos'altro, allora "all'interno delle Transazioni" aggiunge valore. Ma se non significa nulla parlare di tali elementi al di fuori di una transazione, non ha senso ingombrare il nome con tali informazioni superflue.

Due, penso che sia incredibilmente irrealistico supporre che un nome di qualsiasi lunghezza gestibile ti dirà esattamente cosa fa la funzione in tutti tranne i casi più banali. Un obiettivo realistico è quello di fare un nome che dia un indizio al lettore e che possa essere ricordato in seguito. Ad esempio, se sto cercando di trovare il codice che calcola la quantità di antimateria che dobbiamo consumare per raggiungere la velocità di curvatura, se guardo i nomi delle funzioni e vedo "calibrateTransporter", "firePhasers" e "calcAntimatterBurn", è abbastanza chiaro che i primi due non lo sono, ma il terzo potrebbe essere. Se controllo e trovo che quello è davvero quello che sto cercando, sarà facile ricordare che quando tornerò domani per lavorare ancora su questo problema. Va abbastanza bene.

Tre nomi lunghi simili sono più confusi dei nomi brevi. Se ho due funzioni chiamate "calcSalesmanPay" e "calcGeekPay", posso fare una buona ipotesi che è che a colpo d'occhio. Ma se vengono chiamati "CalcolaMonthlyCheckAmountForSalesmanForExportToAccountingSystemAndReconciliation" e "CalcolaMonthlyCheckAmountForProgrammersForExportToAccountingSystemAndReconciliation", devo studiare i nomi per vedere quale è. Le informazioni extra nel nome sono probabilmente controproducenti in questi casi. Trasforma un pensiero di mezzo secondo in un pensiero di 30 secondi.

Progetta la tua interfaccia nel modo desiderato e fai corrispondere l'implementazione.

Ad esempio, forse lo scriverei come

getTransaction().getItems(SKIN_CARE).getEligible().size()

o con flussi Java 8:

getTransaction().getItems().stream()
    .filter(item -> item.getType() == SKIN_CARE)
    .filter(item -> item.isEligible())
    .count();

La mia regola è la seguente: se un nome è così lungo che deve apparire su una riga a sé stante, è troppo lungo. (In pratica, questo significa che raramente ho più di 20 caratteri.)

Questo si basa sulla ricerca che mostra che il numero di linee verticali visibili di codice è correlato positivamente con la velocità / efficacia della codifica. Se i nomi di classe / metodo iniziano a danneggiarlo in modo significativo, sono troppo lunghi.

Aggiungi un commento in cui viene dichiarato il metodo / classe e lascia che l'IDE ti porti là se vuoi una lunga descrizione di cosa serve.

La lunghezza del metodo stesso è probabilmente un indicatore migliore se sta facendo troppo, e anche questo ti dà solo un'idea approssimativa. Dovresti cercare la concisione, ma la descrittività è più importante. Se non riesci a trasmettere lo stesso significato in un nome più breve, probabilmente il nome stesso va bene.

Quando hai intenzione di scrivere un nome di metodo la prossima volta, pensa solo alla seguente frase

"The man who is going to maintain your code is a phyco who knows where you stay"

Il nome di questo metodo è decisamente troppo lungo. La mia mente tende a vagare quando sto leggendo nomi di metodi così grandi. È come leggere una frase senza spazi.

Personalmente, preferisco il minor numero di parole nei metodi possibili. Sei aiutato se il nome del pacchetto e della classe può trasmettere significato. Se la responsabilità della classe è molto concisa , non è necessario un nome di metodo gigante. Sono curioso di sapere perché "WithinTransaction" lì.

"getNumberOfSkinCareEligibleItemsWithinTransaction" potrebbe diventare:

com.mycompany.app.product.SkinCareQuery.getNumEligibleItems ();

Quindi, quando in uso, il metodo potrebbe apparire come "query.getNumEligibleItems ()"

Un nome di variabile è troppo lungo quando un nome più breve consentirà una migliore leggibilità del codice sull'intero programma o sulle parti importanti del programma.

Se un nome più lungo ti consente di comunicare più informazioni su un valore. Tuttavia, se un nome è troppo lungo, ingombrerà il codice e ridurrà la capacità di comprendere il resto del codice. Ciò si verifica in genere causando gli avvolgimenti di riga e spingendo altre righe di codice fuori dalla pagina.

Il trucco sta nel determinare quale offrirà una migliore leggibilità. Se la variabile viene utilizzata spesso o più volte in una breve quantità di spazio, potrebbe essere meglio assegnarle un nome breve e utilizzare un commento per chiarire. Il lettore può rimandare facilmente al commento. Se la variabile viene utilizzata spesso in tutto il programma, spesso come parametro o in altre operazioni complicate, potrebbe essere meglio tagliare il nome o utilizzare gli acronimi come promemoria per il lettore. Possono sempre fare riferimento a un commento mediante la dichiarazione della variabile se dimenticano il significato.

Questo non è un compromesso facile da fare, dal momento che devi considerare ciò che il lettore di codice sta probabilmente cercando di comprendere, e anche tenere conto di come il codice cambierà e crescerà nel tempo. Ecco perché nominare le cose è difficile.

La leggibilità è il motivo per cui è accettabile utilizzare i come contatore di loop anziché DescriptiveLoopCounterName. Poiché questo è l'uso più comune per una variabile, puoi spendere la minima quantità di spazio sullo schermo spiegando perché esiste. Il nome più lungo perderà tempo rendendo più difficile capire come si sta testando la condizione del ciclo o l'indicizzazione in un array.

All'altra estremità dello spettro, se una funzione o una variabile viene utilizzata raramente come in un'operazione complessa, come il passaggio a una chiamata di funzione multiparametrica, è possibile concederle un nome eccessivamente descrittivo.

Come con qualsiasi altra lingua: quando non descrive più la singola azione eseguita dalla funzione.

Direi di usare una combinazione di buone risposte ed essere ragionevole.

Descrivere in modo completo, chiaro e leggibile cosa fa il metodo.

Se il nome del metodo sembra troppo lungo, riformattare il metodo per fare di meno.

È troppo lungo quando il nome del metodo si sposta su un'altra linea e la chiamata al metodo è l'unica cosa sulla linea e inizia abbastanza vicino al margine. Devi prendere in considerazione la dimensione media dello schermo delle persone che lo useranno.

Ma! Se il nome sembra troppo lungo, probabilmente è troppo lungo. Il modo per aggirare il problema è scrivere il codice in modo tale da trovarsi in un contesto e il nome sia breve ma duplicato in altri contesti. È come quando puoi dire "lei" o "lui" in inglese invece del nome completo di qualcuno.

È troppo lungo quando spiega troppo verbalmente di cosa si tratta.

Ad esempio, questi nomi sono funzionalmente equivalenti.

in Java: java.sql.SQLIntegrityConstraintViolationException

in Python / Django: django.db.IntegrityError

Chiediti, in un pacchetto SQL / db, quanti altri tipi di errori di integrità puoi trovare? ;) Quindi db.IntegrityErrorè sufficiente.

Un nome identificativo è troppo lungo quando supera la lunghezza gestibile dal compilatore Java.

Ci sono due modi o punti di vista qui: uno è che non importa quanto sia lungo il nome del metodo, purché sia ​​il più descrittivo possibile per descrivere ciò che il metodo sta facendo (regola di base delle migliori pratiche Java). D'altra parte, sono d'accordo con il post flybywire. Dovremmo usare la nostra intelligenza per cercare di ridurre il più possibile il nome del metodo, ma senza ridurne la descrittività. La descrittività è più importante :)

Un nome è troppo lungo se:

• Richiede più di 1 secondo per leggere
• Occupa più RAM di quanto alloci per la tua JVM
• È qualcosa di assurdamente chiamato
• Se un nome più breve ha perfettamente senso
• Se si avvolge nel tuo IDE

Onestamente il nome deve solo comunicare il suo scopo agli sviluppatori che lo utilizzeranno come metodo API pubblico o dovranno mantenere il codice quando esci. Ricorda solo KISS (mantienilo stupido)