Nomi di variabili: underscore, no underscore o cammello? [chiuso]

Alcuni linguaggi di programmazione o framework hanno le loro convenzioni sulla denominazione delle variabili.

Credo che sia più importante del modo in cui si definiscono le variabili per essere coerenti e attenersi a determinati stili durante un progetto. Questo diventa estremamente importante all'interno di una squadra, in cui il codice deve essere facilmente compreso a prima vista da chiunque lo legga.

IMHO il resto è una questione di gusti.

Personalmente preferisco il caso dei cammelli. Il più importante è che puoi leggere il nome della variabile e il suo significato. E a causa di ciò penso che non importi se usi le sottovesti o il caso dei cammelli. Solo il tuo primo esempio ( thisisavariable ) è un pessimo modo di pensare che sia difficile da leggere!

Generalmente dipende dal tuo linguaggio di programmazione!

A volte preferisco il carattere di sottolineatura quando devi gestire gli acronimi nei nomi delle variabili.

Ad esempio, supponiamo che "Il mio team YAQRT" sia un nome di variabile significativo.

1.) MyYAQRTTeam -or-
2.) MyYaqrtTeam -or-
3.) my_yaqrt_team

Bjarne Stroustrup afferma che la denominazione di underscore è la più leggibile secondo alcune ricerche. Non sono sicuro di quale ricerca si riferisca, ma ovviamente le parole separate da spazi vuoti sono più leggibili rispetto ad altri stili.

Per quanto riguarda la digitazione, sfortunatamente lo stile di sottolineatura perde un po 'il caso: _ non è il simbolo più conveniente per la digitazione, richiede l'intervento di entrambe le mani.

Dipende dal linguaggio di programmazione. I caratteri di sottolineatura sono la convenzione di denominazione preferita in Python. Il caso Camel è la convenzione preferita in C #.

Direi che il primo tipo di nome non dovrebbe mai essere usato.

Qualsiasi altra cosa può essere utilizzata a seconda dell'ambiente. Qui non conta solo la tua scelta, ma anche la lingua e gli stili delle biblioteche. Le lingue possono avere guide di stile esplicite. Le biblioteche possono avere un nome ad hoc, ma è meglio che lo tenga in considerazione.

Ad esempio, se si scrive sotto Windows in una lingua con tipizzazione rigorosa, in cui le funzioni API sono NamedLikeThat e soDoTheirArguments, sembra logico seguire la tendenza e utilizzare il caso cammello con i prefissi di tipo. Allo stesso modo, se scrivi sotto Unix in una lingua con una digitazione debole, un tipico_call (may_look, like_that) e va anche bene.

Non c'è verità universale qui, tutto va non appena è leggibile e tutti sono d'accordo. Puoi estendere le regole nel modo che preferisci. Ad esempio, ho questa vecchia abitudine di nominare i parametri locali che iniziano con il trattino basso, in modo che ad esempio un costruttore C ++ assomigli a questo:

C :: C (const int _iCount) : m_iCount (_iCount) { }

e lo trovi molto comodo.

The specifics don't really matter as long as everybody agrees.

Ne sceglierei uno già esistente:

• per aiutare l'adozione di nuove persone nel team
• non è necessario inventare la ruota da soli
• potresti ottenere supporto per gli strumenti da controllare e refactoring

La maggior parte degli standard di codifica riguarda un linguaggio specifico e fanno una distinzione tra il tipo di variabili. (privato, pubblico, statico ecc.) in modo da poter dire che tipo di variabile è solo guardando il nome.

Per esempi c # consulta questo post del blog per codici diversi linee guida per c #.

Quello preferito è quello della lingua e delle librerie che stai utilizzando. È importante avere uno stile coerente e aderire all'ambiente utilizzato impedisce di mescolare stili diversi. Anche se non tutte le lingue hanno uno stile così dominante (mi viene in mente il C ++). In questi casi è una preferenza puramente personale. Basta concordare qualcosa e attenersi ad esso.

Questo dipende totalmente dal comune accordo dei membri del team. Dopotutto, il codice è pensato per sviluppatori, revisori, auditor e altri membri del team, e quindi deve essere pulito, facilmente modificabile e privo di ambiguità. Le variabili hanno poco spazio per una particolare classe o funzione e dovrebbero avere un nome significativo. Finché la variabile trasmette la sua intensione, il caso rimane nominale. E quindi qualsiasi standard approvato può essere utilizzato e seguito durante lo sviluppo.

Tutti sono preferiti. Dipende solo da chi chiedi.