Utilizzo dei trattini bassi nelle variabili Java e nei nomi dei metodi [chiuso]

Question

Anche oggi vedo spesso trattini bassi nelle variabili e nei metodi Java, un esempio sono le variabili membro (come " m_count " o " _count "). Per quanto ricordo, usare questi caratteri di sottolineatura in questi casi è chiamato cattivo stile da Sun.

L'unico posto in cui dovrebbero essere usati è nelle costanti (come in " public final static int IS_OKAY = 1; "), perché le costanti dovrebbero essere tutte maiuscole e non maiuscole. Qui, il trattino basso dovrebbe rendere il codice più leggibile.

Pensi che usare il trattino basso in Java sia un cattivo stile? Se è così (o no), perché?

Answer 1

Se non hai un codice che lo utilizza ora, ti suggerisco di continuare. Se la tua base di codice lo utilizza, continua.

La cosa più importante dello stile di codifica è coerenza . Se non hai nulla di coerente, i consigli del fornitore di lingue sono probabilmente un buon punto di partenza.

Answer 2

sunDoesNotRecommendUnderscoresBecauseJavaVariableAndFunctionNamesTendToBeLongEnoughAsItIs();

as_others_have_said_consistency_is_the_important_thing_here_so_chose_whatever_you_think_is_more_readable();

Answer 3

Regole:

1. Fai ciò che fa il codice che stai modificando
2. Se il n. 1 non si applica, utilizzare camelCase, nessun carattere di sottolineatura

Answer 4

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

Puoi anche raggiungere questo obiettivo forzando gli utenti a anteporre variabili di istanza con " questo " ma lo trovo leggermente draconiano. In molti modi viola DRY perché è una variabile di istanza, perché qualificarlo due volte.

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

Answer 5

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

Per rispondere alla tua domanda: utilizzo un carattere di sottolineatura iniziale per contrassegnare le variabili private. Lo trovo chiaro e posso scansionare velocemente il codice e scoprire cosa sta succedendo.

(Non uso quasi mai " questo " però, tranne che per evitare uno scontro tra nomi.)

Answer 6

l'uso di 'm_' o '_' nella parte anteriore di una variabile semplifica l'individuazione delle variabili membro nei metodi in un oggetto.

Come vantaggio secondario, digitare 'm_' o '_' farà apparire prima intellsense;)

Answer 7

• Mi piacciono i caratteri di sottolineatura principali per le variabili di istanza (private), sembra più facile da leggere e distinguere. Naturalmente questa cosa può metterti nei guai con casi limite (ad esempio variabili di istanza pubblica (non comune, lo so) - sia il modo in cui li chiami stai probabilmente infrangendo la tua convenzione di denominazione:
• private int _my_int;  public int myInt ;? _my_int? )

-quanto mi piace lo stile _ di questo e penso che sia leggibile, trovo che sia probabilmente più problemi di quanti ne valga la pena, in quanto è raro e probabilmente non corrisponde a nessun altro nella base di codice che stai usando.

generazione automatica di codice (ad es. generatori di gettoni, setter di eclipse) non sono in grado di comprenderlo, quindi dovrai risolverlo manualmente o muck con eclissi abbastanza per farlo riconoscere.

Alla fine, andrai contro il resto delle prede del mondo (java) e probabilmente avrai qualche fastidio da questo. E come hanno già detto i poster precedenti, la coerenza nella base di codice supera tutti i problemi sopra citati.

Answer 8

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

Answer 9

È bello avere qualcosa per distinguere le variabili private rispetto a quelle pubbliche, ma non mi piace '_' nella codifica generale. Se posso aiutarlo con un nuovo codice, ne evito l'uso.

Answer 10

Ecco un link alle raccomandazioni di Sun per Giava. 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 hanno formattati e strumenti di pulizia che possono aiutarti a conformarti a queste convenzioni (o ad altre che definisci).

Per me, '_' è troppo difficile da scrivere :)

Answer 11

È una miscela di stili di codifica. Una scuola di pensiero è quella di prefigurare i membri privati ??con un carattere di sottolineatura per distinguerli.

setBar( int bar)
{
   _bar = bar;
}

anziché

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

Altri useranno i trattini bassi per indicare una variabile locale temporanea che andrà al di fuori dell'ambito alla fine della chiamata del metodo. (Lo trovo abbastanza inutile - un buon metodo non dovrebbe essere così lungo, e la dichiarazione è GIUSTA QUI! Quindi so che va oltre lo scopo) Modifica: Dio vieti un programmatore di questa scuola e un programmatore del membro Scuola di dati collaborano ! Sarebbe un inferno.

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

Answer 12

Penso che qualsiasi stile che rompa le linee guida di uno stesso linguaggio (senza la dovuta ragione) sia brutto e quindi "cattivo".

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

Alcune persone non riescono ad adattarsi ai nuovi stili di codifica ...

Answer 13

Il motivo per cui le persone lo fanno (secondo la mia esperienza) è la differenziazione tra variabili membro e parametri di funzione. In Java puoi 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 creato la variabile membro _var1 o m_var1, non avresti l'ambiguità nella funzione.

Quindi è uno stile e non lo definirei cattivo.

Answer 14

Personalmente, penso che una lingua non dovrebbe fare regole sullo stile di programmazione. È una questione di preferenze, utilizzo, convenienza, concetto di leggibilità.
Ora, un progetto deve impostare 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 gruppo).

Almeno, gli IDE come Eclispe sono agnostici, consentendo di impostare regole come prefissi o suffissi variabili, vari stili di posizionamento del controvento e gestione dello spazio, ecc. Quindi puoi usarlo per riformattare il codice lungo tuo linee guida.

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

Answer 15

è solo il tuo stile, niente di un cattivo codice di stile, e niente di un buon codice di stile, fai la differenza tra il nostro codice e gli altri.