Sono immorale per l'utilizzo di un nome di variabile che differisce dal suo tipo solo per caso?

Ad esempio, prendi questo pezzo di codice:

var person = new Person();

o per voi Pythonistas:

person = Person()

Mi viene detto costantemente quanto sia grave, ma devo ancora vedere un esempio dell'immoralità di queste due righe di codice. Per me una persona è una persona e cercare di darle un altro nome è una perdita di tempo. Suppongo che nei giorni precedenti all'evidenziazione della sintassi, questo sarebbe stato un grosso problema. Ma oggigiorno è abbastanza facile distinguere il nome di un tipo dal nome di una variabile. Diamine, è anche facile vedere la differenza qui su SO.

O c'è qualcosa che mi manca? In tal caso, sarebbe utile fornire un esempio di codice che causa problemi.

Qual è il ragionamento di coloro che ti dicono che questo è un male? Lo faccio tutto il tempo. È il modo più semplice ed espressivo per nominare una singola variabile di un tipo. Se avessi bisogno di due Personoggetti, potresti aggiungere un prefisso personad aggettivi significativi come

fastPerson
slowPerson

altrimenti solo

person

per me va bene.

Uso molto questo modello nelle firme dei metodi. Se non sono in grado di fornire un nome descrittivo alternativo, IMHO, non c'è niente di sbagliato in questo.

Ciò che è sbagliato sarebbe se avessi due tipi di persona e persona, allora è molto molto sbagliato.

Lo uso sempre per i riferimenti temporanei agli oggetti. Lo eviterei come la piaga dei tipi di dati primitivi.

Person person = new Person(); // okay

int Int = 42; // pure evil

Se qualcuno dice che è malvagio, chiedigli se è meglio:

var abc = new Person();

Se la persona è una persona generale nel contesto, "persona" è davvero un buon nome. Ovviamente se la persona ha un ruolo specifico nel codice, è meglio nominarla usando il ruolo.

Suppongo che verrò svalutato per averlo detto, ma ...

Avendo appena passato un secolo assistendo a omicidi epici e avidità, noi programmatori siamo davvero benedetti se la cosa più immorale che possiamo fare è nominare una variabile.

Non penso che sia necessariamente "cattivo", ma ovviamente se puoi qualificarlo per dargli più contesto, come che tipo di persona è (hai a che fare solo con una delle presumibilmente molte persone possibili), allora qualcun altro lo sceglie può capire meglio.

Jason - Non sono sicuro di chi ti abbia detto che questo è un male. Un certo numero di autori usa questo come un modo standard per esprimere un'istanza (minuscolo) di una classe (maiuscolo).

Lo uso abbastanza spesso poiché trovo che la variabile in minuscolo effettivamente mi comunica non solo che si tratta di un'istanza, ma anche il nome della classe.

A meno che qualcuno non abbia una solida argomentazione in contrario, continuerò sicuramente a farlo.

Il motivo per cui è considerato cattivo è che se hai bisogno di avere 2 persone in futuro, puoi quindi finire con un codice simile.

Persona persona = nuova persona ();

Persona persona2 = nuova persona ();

Sarebbe quindi al limite del "cattivo". Tuttavia, in quel caso dovresti poi rifattorizzare la tua persona originale per distinguere tra i due.

Come per il tuo esempio, il nome della variabile "persona" è un nome perfettamente descrittivo per l'oggetto "Persona". Quindi non c'è niente di sbagliato in questo.

Dico il nome per quello che è: se la variabile rappresenta una persona con 2 cani, chiamala personWith2Dogs. Se la variabile ha un ambito breve (come una variabile di ciclo), la persona va bene.

Lo uso molto nel mio codice e non credo che ci sia qualcosa di sbagliato in esso. Detto questo, io (probabilmente) non lo userei in un metodo più lungo, diciamo di una schermata, e se ci sono più istanze della classe Person. Sicuramente non nominarli person1, person2, person3 ... invece usa qualcosa di più descrittivo, come person_to_del, person_to_ban, person_to_update, ecc.

Non immorale, ma una ricerca globale troverà entrambi Persone personse non si attiva la distinzione tra maiuscole e minuscole. Preferisco un prefisso per rendere più facile la ricerca / sostituzione globale, ma assolutamente NON ungherese o qualcosa di lungo / complicato. Quindi, io uso ...

Personper la classe / tipo aPersonper una variabile locale thePersonper un parametro di metodo myPersonper una variabile di istanza ourPersonper una variabile di classe

In rare occasioni, potrei usarlo pin un contesto locale in cui ho MOLTI riferimenti, ma di solito si applica solo agli indici di loop e simili.

Dipende.

Se hai uno stile di capitalizzazione rigoroso, quindi le variabili iniziano in minuscolo (e usa under_scores o camelCase per le interruzioni di parola) e le classi iniziano con le lettere maiuscole, allora è ovvio che la persona è una variabile e la persona è una classe, e quando qualcuno lo capisce , non sembrano trovarsi in spazi dei nomi sovrapposti. (Allo stesso modo, le persone non si confondono quasi mai tra il verbo o il sostantivo "polacco" e l'aggettivo "polacco".)

Se non hai un tale stile, hai due nomi che possono essere facilmente confusi e differiscono solo nel caso. Questo è male.

Quali sono gli argomenti esatti che queste persone usano?

Se non ti consentono di utilizzare persona come nome di variabile, potresti considerare di aggiungere il prefisso "a".

aPerson = Person()

Penso che quello che stai facendo vada bene. Penso che in generale sia importante avere standard di codifica concordati.

Ad esempio io uso lowerCamelCase per istanze, variabili e UpperCamelCase per classi ecc

Gli standard di codifica dovrebbero eliminare questo problema.

Quando guardo programmi open source di successo, spesso hanno standard di codifica

http://drupal.org/coding-standards

http://help.joomla.org/content/view/826/125/

http://wiki.rubyonrails.org/rails/pages/CodingStandards

http://lxr.linux.no/linux/Documentation/CodingStyle

Concordare gli standard di codifica dovrebbe essere l'ultima battaglia che devi affrontare.

In effetti guarda la voce di wikipedia (da http://en.wikipedia.org/wiki/CamelCase )

Stile di programmazione e codifica

L'uso delle maiuscole interne è talvolta consigliato per indicare i confini delle parole dalle linee guida dello stile di codifica per la scrittura del codice sorgente (ad esempio, il linguaggio di programmazione Mesa e il linguaggio di programmazione Java). Le raccomandazioni contenute in alcune di queste linee guida sono supportate da strumenti di analisi statica che controllano l'aderenza del codice sorgente.

Queste raccomandazioni spesso distinguono tra UpperCamelCase e lowerCamelCase, specificando tipicamente quale varietà dovrebbe essere utilizzata per tipi specifici di entità: variabili, campi record, metodi, procedure, tipi, ecc.

Uno stile di codifica Java ampiamente utilizzato impone di utilizzare UpperCamelCase per le classi e lowerCamelCase per istanze e metodi. [19] Riconoscendo questo utilizzo, alcuni IDE, come Eclipse, implementano scorciatoie basate su CamelCase. Ad esempio, nella funzionalità di assistenza ai contenuti di Eclipse, digitare solo le lettere maiuscole di una parola CamelCase suggerirà qualsiasi nome di classe o metodo corrispondente (ad esempio, digitare "NPE" e attivare l'assistente ai contenuti potrebbe suggerire "NullPointerException").

La notazione originale ungherese per la programmazione specifica che un'abbreviazione minuscola per il "tipo di utilizzo" (non il tipo di dati) deve anteporre a tutti i nomi delle variabili, con il resto del nome in UpperCamelCase; come tale è una forma di lowerCamelCase. CamelCase è la convenzione ufficiale per i nomi dei file in Java e per il personal computer Amiga.

Microsoft .NET consiglia lowerCamelCase per parametri e campi non pubblici e UpperCamelCase (noto anche come "Pascal Style") per altri tipi di identificatori. [20]

Python consiglia UpperCamelCase per i nomi delle classi. [21]

Il registro NIEM richiede che XML Data Elements utilizzi UpperCamelCase e gli attributi XML utilizzino lowerCamelCase.

Non esiste una convenzione unica per l'inclusione di abbreviazioni maiuscole (principalmente acronimi e iniziali) nei nomi CamelCase. Gli approcci includono lasciare l'intera abbreviazione in maiuscolo (come in "useHTTPConnection") e lasciare solo la prima lettera in maiuscolo (come in "useHttpConnection").

Il case Camel non è affatto universale nell'informatica. Gli utenti di diversi linguaggi di programmazione moderni, in particolare quelli delle famiglie Lisp e Forth, usano quasi sempre trattini. Tra i motivi a volte addotti vi sono il fatto che ciò non richiede lo spostamento sulla maggior parte delle tastiere, che le parole sono più leggibili quando sono separate e che il caso del cammello potrebbe semplicemente non essere conservato in modo affidabile nelle lingue che non fanno distinzione tra maiuscole e minuscole (come ad esempio Common Lisp, che, sebbene tecnicamente sia un linguaggio che distingue tra maiuscole e minuscole, canonicalizza (piega) gli identificatori in maiuscolo per impostazione predefinita).

È possibile sostenere un argomento più forte che i nomi di metodi di quel tipo non solo sono innocui ma possono essere un indicatore di codice di buona qualità.

• Un indicatore di una buona granularità del codice: se i metodi sono brevi, monouso e denominati in modo descrittivo, non sono necessarie molte informazioni nei nomi delle variabili. Se disponi di metodi lunghi che eseguono molte cose e devi tenere traccia di molto contesto e stato, i nomi delle variabili devono essere più descrittivi.

• Un indicatore di calcoli generici che vengono trasferiti in metodi generici: se si esegue una manipolazione intermedia di strutture dati in un metodo aziendale, ad esempio deve essere deduplicato un array di utenti, sarà necessario avere variabili nell'ambito con nomi come users[]e deduplicatedUsers[]. Se si sposta la deduplicazione su un metodo di utilità, è possibile chiamare il metodo Utils.dedup(array)e chiamare l'array deduplicato deduplicatedArrayo semplicemente result.

• I decompilatori Java spesso usano uno schema come quello per nominare le variabili locali (le variabili di istanza e di classe sono normalmente disponibili nel bytecode, ma le variabili locali no), e i risultati sono più leggibili di quanto ci si potrebbe aspettare, infatti spesso più leggibili del fonte originale.

• Vedi il principio di Larry Wall di "Local Ambiguity is OK" - http://www.wall.org/~larry/natural.html .

Direi che probabilmente hai in mente un uso specifico ogni volta che crei un oggetto. Il tipo da solo riflette molto raramente tale uso.

Quindi, se desideri creare un nuovo contatto nella tua applicazione della rubrica, potresti voler chiamare la variabile newContact.

E se stai testando il tuo codice per controllare il comportamento di Personoggetti senza nomi impostati, potresti volerli chiamare unnamedPersono qualcosa di simile.

Chiamarlo semplicemente personrinuncia a una grande possibilità di rendere il tuo codice auto-documentante.

Solo se stai programmando in VB6. In tal caso , quello che stai facendo è illegale, ma non immorale.

Lo faccio anche io, e non capisco nemmeno perché dovrebbe essere "immorale". Anche se posso capire che a volte può essere fonte di confusione, ma oggi abbiamo IDE con intellisense e evidenziazione della sintassi che assicureranno che (se commetti un errore e fai riferimento alla tua variabile anziché alla tua classe, e viceversa) vedere il tuo errore abbastanza velocemente. E abbiamo anche il compilatore. :)

Inoltre non vedo alcun problema con questa pratica. Finché c'è solo una variabile di quella classe, è facile da scrivere e di facile lettura. Imo, che si applica anche a un editor di testo di base. Personalmente non riesco a ricordare nessuno che lo definisca cattivo o addirittura immorale. Continua a farlo :)

Penso che la "regola" a cui potresti pensare sia intesa più per tipi primitivi e classi in cui il nome della classe fa un nome di variabile scadente.

Ad esempio, se avessi a che fare con il calcolo del costo di un particolare articolo in un negozio online, il seguente codice non sarebbe valido:

Decimal _decimal = item.BaseCost + item.Tax;

Invece, sarebbe consigliato un nome più descrittivo, come "_total" o "_cost".

L'unico problema con questo genere di cose che ho trovato è se vuoi lo stesso nome per un membro privato e anche una proprietà pubblica.

Se differiscono solo nel caso, funzionerà bene nei linguaggi con distinzione tra maiuscole e minuscole come C #, ma non in VB.NET.

Quindi, ad esempio, in VB, scriverei

Private _name As String

ma

Public Property Name() As String
    Get
        Return _name
    End Get
    Set(ByVal Value As String)
        _name = Value
    End Set
End Property

Farei lo stesso in C #, quindi la traduzione dall'uno all'altro è indolore. Inoltre lo rende un po 'meno soggetto a errori, dal momento che è molto facile leggere male, o addirittura sbagliare parole che differiscono solo per caso.

Non immorale, ma se il nome migliore per la tua variabile è il nome del tipo, qualcosa non va o stai solo facendo una prova di concetto o qualcosa del genere. Per me un nome di variabile deve riferirsi al significato nel contesto aziendale e non al linguaggio di programmazione. Sarà più difficile capire il codice.

Uso spesso Person person = new Person()me stesso. Comunemente utilizzato in Java / C #.

Anche se ieri ho finito per chiedermi perché

private enum DataType {NEW, OLD}

non funziona in C # ...

Soprattutto vedendo come è possibile utilizzare String, string, Double, double, ... a volontà in C #.

Person person = new Person()

va bene nel mio libro.

Quando diventa orribile è quando hai:

string Person;
string person;

Molto facile mescolare i 2.

Ciò che mi è stato espresso, oltre a non soddisfare i nostri standard di codifica, è evitare di aggiungere confusione quando qualcun altro sta leggendo il mio codice. Io, personalmente, non vedo alcun problema, purché il significato sia chiaro.

Per quanto riguarda i tipi CLR (int, string, ecc.) Puoi usare String o string (ecc.) Per dichiarare il tipo, quindi eviterei di usare qualcosa di simile

int Int = 0;
string String = "hi there";

Rendere le maiuscole l'unica differenza è pericoloso ... continua a farlo per un grande progetto e ti garantisco che incapperai in errori bizzarri che non riesci a individuare.

fastPerson / slowPerson come sopra vanno bene ... sono descrittivi e differenziati dal nome del tipo di variabile ... ma dai amico, chiamare un int "Int" sarebbe semplicemente pigro.

Direi che non è mai immorale - è solo il nome della tua variabile di base. Se non riesci a pensare a un nome migliore, nominarlo dopo il suo tipo è un buon valore predefinito ( solo per i tipi complessi - per i tipi incorporati è malvagio ) e molte volte non c'è davvero un nome migliore perché non lo fai. Non so nient'altro sulla variabile. Come con questo metodo

void SaveToDatabase(Person person) {...}

L'unica cosa che potresti ragionevolmente chiamare persona è person_to_saveo qualcosa del genere che sembra ridondante.

Tuttavia in molti casi puoi migliorare la leggibilità del tuo codice sostituendo la persona con un nome più descrittivo. Ad esempio, questo è meno descrittivo

void AddToAccount(Account account, Person person)  {...}

di questo

void AddToAccount(Account account, Person dependent)  {...}

Tuttavia, per favore, per favore - piuttosto per favore non mettere una "a" o "t" davanti al nome del tipo. Vale a dire una persona per "una persona" o una persona per "la persona". È eccessivamente complicato e non aggiunge molto valore. Inoltre inizi a inquinare il tuo ambito con un mucchio di variabili che iniziano con a o t che possono ridurre al minimo il valore di intelli-sense.

Non direi che è orribile. Di solito al nome della variabile faccio da prefisso "a" in questo genere di cose per mostrare che si tratta di una singola istanza del tipo, quindi lo farei

Person aPerson = new Person();

Rende il codice più naturale, credo.

Assolutamente niente di sbagliato in esso soggetto a caveat segnalati da altri (riassumendo qui per comodità): non farlo con tipi primitivi, refactoring dell'istanza originale se un'altra istanza viene aggiunta in seguito, non usare char-case per differenziare i nomi delle classi, ecc.

La mia regola pratica? Le dichiarazioni in codice dovrebbero essere lette come semplici frasi inglesi.

Persona persona = nuova persona ();

Dipendente dipendente = person.getRole (EMPLOYEE);

Genitore genitore = person.getRole (PARENT);

person.getFullName ();

dipendente.getSalary ();

parent.getChildren ();

parent.getFullName (); // assumendo che il motivo del decoratore sia in gioco

if (person.hasRole (EMPLOYEE)) {

  ...

}

E così via.

Se l'ambito della variabile è limitato (il metodo di incapsulamento è di 10-15 righe, per esempio) potrei anche usare "p" invece di "persona". I nomi di variabili più brevi rappresentano una distrazione minore quando cerchi di mantenere il contesto nella tua testa. Evita prefissi gratuiti come la notazione ungherese "a" o (rabbrividire) e le sue derivazioni. (Intendiamoci, non ho nulla contro tali prefissi se usati nel contesto appropriato - codice API C ++ / COM / ATL / Win32 ecc., Dove aiuta a mantenere le assegnazioni / typecasting dritto).

I miei due (!) Bit :-)