Utilizzo di caratteri di sottolineatura in variabili Java e nomi di metodi

Question

Anche oggigiorno vedo spesso trattini di sottolineatura in metodi e variabili Java, un esempio sono variabili membro (come "m_count" o "_count"). Per quanto mi ricordi, usare i caratteri di sottolineatura in questi casi è chiamato stile cattivo da Sun.

L'unico posto che devono essere utilizzati è in costanti (come in "public final static int IS_OKAY = 1;"), perché le costanti devono essere tutte maiuscole e non in maiuscolo. Qui, il carattere di sottolineatura dovrebbe rendere il codice più leggibile.

Pensi che l'uso di caratteri di sottolineatura in Java sia di cattivo gusto? Se è così (o meno), perché?

Answer 1

Se non si dispone di un codice che lo utilizza ora, suggerirei di continuarlo. Se il tuo codice base lo usa, continua così.

La cosa più importante nello stile di codifica è consistenza. Se non hai nulla con cui essere coerente, allora i consigli del fornitore del linguaggio sono probabilmente un buon punto di partenza.

Answer 2

utilizzando 'm_' o '_' nella parte anteriore di una variabile rende più semplice individuare le variabili membro nei metodi in un oggetto.

Come beneficio collaterale di battitura 'M_' o '_' farà intellsense loro pop-up prima;)

Answer 3

Regole:

1. fare quello che il codice che si sta modificando non
2. Se # 1 non si applica, utilizzare CamelCase, senza trattini bassi

Answer 4

È una miscela di stili di codifica. Una scuola di pensiero è di prefigurare i membri privati ​​con un trattino basso per distinguerli.

setBar(int bar) 
{ 
    _bar = bar; 
} 

anziché

setBar(int bar) 
{ 
    this.bar = bar; 
} 

altri useranno sottolineatura per indicare una variabile locale temporanea che uscirà di portata al termine della chiamata al metodo. (Trovo che questo sia abbastanza inutile - un buon metodo non dovrebbe essere così lungo, e la dichiarazione è GIUSTA LÀ! Quindi so che va fuori dal campo di applicazione) Modifica: Dio non voglia un programmatore di questa scuola e un programmatore della scuola memberData collaborare ! Sarebbe un inferno.

A volte, il codice generato prefigura le variabili con _ o __. L'idea è che nessun essere umano farebbe mai questo, quindi è sicuro.

Answer 5

Penso che qualsiasi stile che infrange le linee guida dello stile di una lingua (senza una giusta causa) è brutto e quindi "cattivo".

Senza dubbio il codice che hai visto è stato scritto da qualcuno che lavorava in una lingua in cui i caratteri di sottolineatura erano accettabili.

Alcune persone semplicemente non può adattarsi ai nuovi stili di codifica ...

Answer 6

"stile Bad" è molto soggettivo. Se alcune convenzioni funzionano per te e il tuo team, penso che qualificheranno uno stile cattivo/buono.

Per rispondere alla tua domanda: Io uso un trattino basso principale per contrassegnare le variabili private. Lo trovo chiaro e posso scansionare velocemente il codice e scoprire cosa sta succedendo.

(ho quasi mai usare "questo", anche se, se non per evitare che un nome di scontro.)

Answer 7

La ragione per cui le persone lo fanno (nella mia esperienza) è quello di distinguere tra variabili e parametri di funzione. In Java si può avere una classe come questa:

public class TestClass { 
    int var1; 

    public void func1(int var1) { 
    System.out.println("Which one is it?: " + var1); 
    } 
}

Se hai fatto la _var1 variabile membro o m_var1, non si avrebbe l'ambiguità nella funzione.

Quindi è uno stile e non lo chiamerei male.

Answer 8

sunDoesNotRecommendUnderscoresBecauseJavaVariableAndFunctionNamesTendToBeLongEnoughAsItIs(); 

as_others_have_said_consistency_is_the_important_thing_here_so_chose_whatever_you_think_is_more_readable();

Answer 9

Personalmente, penso che una lingua non dovrebbe fare regole di codifica stile. È una questione di preferenze, utilizzo, convenienza, concetto di leggibilità.
Ora, un progetto deve impostare le regole di codifica, per coerenza tra gli elenchi. Potresti non essere d'accordo con queste regole, ma dovresti rispettarle se vuoi contribuire (o lavorare in una squadra).

Almeno, IDE come Eclispe sono agnostico, che permette di impostare regole come prefissi o suffissi variabili, vari stili di posizionamento brace e la gestione dello spazio, ecc Quindi è possibile utilizzarlo per riformattare il codice lungo tuoi linee guida.

Nota: sono tra coloro che mantengono le loro vecchie abitudini da C/C++, codificando Java con prefissi m_ per le variabili membro (e s_ per quelle statiche), prefissando i booleani con una iniziale b, utilizzando una lettera maiuscola iniziale per i nomi delle funzioni e allineamento di parentesi graffe ... L'orrore per i fondamentalisti di Java! ;-)
Funnily, sono le convenzioni utilizzate dove lavoro ... probabilmente perché il principale sviluppatore iniziale viene dal mondo MFC! :-D

Answer 10

Ecco un link per le raccomandazioni di Sun per Java. Non che tu debba usare questi o anche che il loro codice di libreria li segua tutti, ma è un buon inizio se stai andando da zero. Strumenti come Eclipse sono dotati di formattatori e strumenti di pulizia che possono aiutarti a conformarti a queste convenzioni (o ad altre che definisci).

Per me, '_' sono troppo difficili da digitare :)

Answer 11

E 'bello avere qualcosa di distinguere privato vs. variabili pubbliche, ma non mi piace '_' nella codifica generale. Se posso aiutarlo nel nuovo codice, evito il loro uso.

Answer 12

• Mi capita di come leader di sottolineatura per le variabili (privato) esempio, sembra più facile da leggere e distinguish.Of ovviamente questa cosa si può ottenere nei guai con i casi limite (ad esempio, le variabili di istanza pubbliche (non comune, lo so) - in entrambi i casi è il nome loro che stai probabilmente rompere la convenzione di denominazione:
• private int _my_int; public int myInt;? _my_int?)

-come quanto mi piace il _style di questo e che sia leggibile trovo che sia probabilmente più problemi di quanti ne vale la pena, poiché è raro ed è probabile che non corrisponda a nient'altro nella base di codice che stai utilizzando.

-generazione automatica di codice (ad es. i generatori di eclipse, i setter) non sono in grado di capirlo, quindi dovrai risolverlo a mano o fustigare con eclissi abbastanza da farlo riconoscere.

In fin dei conti, stai andando contro il resto dei prefissi del mondo (java) e probabilmente avrai qualche fastidio da quello. E come hanno menzionato i manifesti precedenti, la coerenza nel codebase supera tutti i problemi sopra citati.

Answer 13

Non penso che usare _ o m_ per indicare che le variabili membro sono in cattive condizioni in Java o in qualsiasi altra lingua. A mio avviso, migliora la leggibilità del tuo codice perché ti permette di guardare uno snippet e identificare rapidamente tutte le variabili membro dai locali.

È inoltre possibile ottenere questo costringendo gli utenti a anteporre le variabili di istanza a "questo", ma questo lo trovo leggermente draconiano. In molti modi viola DRY perché è una variabile di istanza, perché qualificarla due volte.

Il mio stile personale è utilizzare m_ anziché _. Il motivo è che ci sono anche variabili globali e statiche. Il vantaggio di m _/_ è che distingue uno scope di variabili. Quindi non puoi riutilizzare _ per globale o statico e invece scelgo rispettivamente g_ e s_.

Answer 14

è solo il tuo stile, niente un brutto codice di stile, e niente un buon codice di stile, solo differenza il nostro codice con gli altri.

Answer 15

C'è un motivo per cui l'utilizzo di caratteri di sottolineatura era considerato uno stile negativo nei vecchi tempi. Quando un compilatore di runtime era qualcosa di inaccessibile e i monitor venivano forniti con una risoluzione sorprendente di 320x240 pixel, spesso non era facile distinguere tra _name e __name.