Vale la pena prestare attenzione alle linee guida della convenzione di denominazione?


13

Nomino le mie variabili usando le convenzioni .Net:

  • camelCase per variabili e campi (tendo a usare _camelCase per campi privati ​​in una classe)
  • PascalCase per metodi, proprietà e classi

L'unico posto in cui devio è su costanti ed Enum in cui in realtà preferisco lo stile Java SCREAMING_CAPS.

La base di codice della mia azienda è disseminata dello stile di notazione pseudo-ungherese di VB6 e VBScript, se non ungherese completo cioè

  • s o str per stringhe
  • i o int per Ints
  • d per decimale (o talvolta doppio)
  • o o obj per qualsiasi tipo di oggetto

Mi arrabbio ogni volta che vedo quello stile di codice usato nel codice di qualcun altro (anche nel codice greenfield, non solo nella legacy legft), e mi rifiuto di usare quello stile da solo. Ho accennato alla standardizzazione delle convenzioni di denominazione .Net in passato ed è stato semplicemente ignorato: le persone che scrivono in notazione ungherese continuano a farlo, quelli di noi che non mi piacciono continuano a usare il proprio stile; Sono un po 'paura che se noi facciamo standardizzare (che continuo a spingere per, ma nessun altro sembra preoccuparsi), sarà sulla notazione ungherese e non il metodo consigliato e poi sarò costretto a scrivere il codice del genere .

Sto facendo una montagna da una talpa per quanto riguarda questo? Non dovrei preoccuparmi se il codice è disseminato di identificatori ridondanti e non nomi descrittivi, e continuare a usare la mia strada e spingere per farlo diventare lo standard?


2
Buona domanda. Le convenzioni di denominazione sono lì per aiutare, non per ostacolare. Quando ostacolano (perché il loro scopo originale non è più rilevante), quindi abbandonarli.
Gary Rowe,

Risposte:


7

L'unica cosa di cui dovresti preoccuparti è che stai lavorando in un gruppo in cui le persone non si preoccupano di ripulire un po 'le cose. Questo è molto triste.

Fai quello che fai, continua a usare lo stile moderno e invita le persone (ma non forzarle) ad adottarlo. Ci vorrà del tempo ovviamente. Dopo un po 'vedrai se sta andando ovunque e cosa potresti fare dopo.

PS Che ne dici di organizzare una riunione su questo problema e invitare tutte le persone coinvolte. Quindi otterrai la loro piena attenzione, denoterai il problema e presenterai il tuo approccio. Darà loro qualcosa a cui pensare. Forse dai tuoi tentativi locali non ti prendono molto sul serio.


+1 Al giorno d'oggi Refactor Rename è così efficiente che difficilmente noterai l'impatto della modifica.
Gary Rowe,

2
Purtroppo le persone del mio team non lo usano nemmeno. Hanno paura di rinominare le cose anche quando il nome è fuorviante. Ad esempio, esiste un metodo chiamato SendNewCustomerEmailche viene utilizzato per inviare tutti i tipi di e-mail, non solo le e-mail di nuovi clienti. Ha un commento di un attuale sviluppatore che dice "Nota che questo nome è fuorviante" ma nessuno ha mai nemmeno preso in considerazione l'idea di rinominarlo in qualcosa di più generico e utile, e se lo faccio mi verrà chiesto dal gestore di spiegare perché sto cambiando il codice che non ha bisogno di essere modificato invece di aggiungere valore.
Wayne Molina,

3

Penso che potresti aver bisogno di chiederti se la notazione ungherese sta influenzando o meno la tua produzione / qualità personale, o se sta solo danneggiando il tuo ego. Per ego, intendo dire che le cose in genere funzionano bene, ma non vorresti mai che qualcuno che rispetto dall'esterno vedesse il codice vergognosamente obsoleto. Mentre penso che la preoccupazione abbia il suo merito, devi metterla a confronto con il colpo di qualità / produttività che verrebbe preso da chiunque debba cambiare.

Questa è una specie di domanda di debito tecnico, poiché hai chiaramente ragione sul fatto che questo stile ungherese non ha senso in .Net (ad eccezione delle interfacce con "I", ma è un'altra volta), tuttavia, questo potrebbe essere il tipo di debito tecnico con cui la tua squadra può sopravvivere fino a quando non si attenua naturalmente .


4
Non mi interessa nemmeno il prefisso "I", e lo uso solo perché evita di avere l'enigma Java, per esempio, di un nome interfacciato CustomerRepositorye che la classe sia CustomerRepositoryImplo simile.
Wayne Molina,

3
+1 - Sembra che ci dovrebbe essere un modo migliore. Di tanto in tanto uso "Hungarian Light", ma i prefissi sono sempre legati al mondo degli affari, non al tipo. Ad esempio, tutto in Accounting ha un lato AP e un lato AR e spesso hanno lo stesso nome, come Invoice. Avere un ARInvoice e un APInvoice mi sembra perfettamente ragionevole. L'ungherese non è TUTTO male TUTTO il tempo.
Morgan Herlocker,


Non prenderei davvero in considerazione questa "notazione ungherese" perché, come hai detto, è un significato commerciale con un'abbreviazione ben definita che le persone conoscono, sulla stessa linea di avere codice che utilizza XML con prefisso Xmlanziché ExtensibleMarkupLanguage. In un modulo di contabilità mi aspetterei di vedere gli oggetti fattura simili arInvoicee apInvoiceche trasmettono il contesto aziendale, ma vedere objArInvoiceo oApInvoiceè solo sciocco IMO. Immagino che potrebbe essere peggio, potrebbe essere clsApInvoiceper il vero nome della classe
Wayne Molina,

1
@ironcode: Questo è in realtà ciò che si chiama App Notazione ungherese, rispetto alla Notazione ungherese di Sistemi, ed è molto meglio. La maggior parte delle persone utilizza i sistemi purtroppo. en.wikipedia.org/wiki/…
Miki Watts,

2

L'argomento migliore contro la notazione ungherese, accanto ai moderni IDE, che hanno molti metodi per mostrare il tipo, la visibilità e più roba di una variabile con il colore, con piccoli simboli e descrizioni dei comandi durante l'aspirapolvere, è di prenderlo sul serio.

  • Incoraggiare più distintcion (b) ool (f) loat (c) har (l) ong (s) hort (è in conflitto con String? No: (S) tring), (v) oid.
  • Incoraggiare la codifica della visibilità. Vengo da Javaland e spero che vada bene anche per .net: (pri) vate, (pub) blic, (pro) tected (def) ault dovrebbero essere usati.
  • .net ha final / const? Fallo diventare un prefisso! Sento "volatile"?
  • Perché int e long hanno bisogno di un prefisso, ma oggetti diversi no? Non è logico. Crea un abbrev.tab. dove ogni nuovo oggetto ottiene un abbreviato distinto.
  • Anche le variabili che potrebbero essere nulle e simili, che non dovrebbero mai essere nulle, possono essere prefissate. Le persone intelligenti mettono l'intero DbC nel prefisso di una variabile.

Scherzi a parte: sul refactoring, è possibile modificare una variabile da int a long, da String a char. Non dovresti aver bisogno di cambiare anche il nome.

In IDE, ottieni i nomi spesso ordinati in una casella a lato. ordinati per nome, dove è facile da trovare. Se la maggior parte delle variabili inizia con oo, è inquietante per gli occhi arrivare alla parte significativa del nome.

I caratteri aggiuntivi disturbano la semantica della variabile. Un intero "sano" ottiene "i_sane", che assomiglia di più a "folle".

La notazione ungherese è stata utile nelle lingue, che mancano di un sistema di tipi. Non è necessario, se il compilatore applica tipi specifici. Se decori il tuo lamento sulla notazione ungherese con un "sì, empatico" per i programmatori anziani, in passato aveva senso usarlo! ", Quei programmatori anziani potrebbero essere vani, e preferirebbero non essere identificati come vecchi.

Ma devi stare attento, affinché la tecnica funzioni. Forse puoi abbassare la voce quando parli di "programmatori anziani", per farli sentire, quanto stai attento a loro, quanto hanno bisogno delle cure. In modo che una terza persona nella stanza riconoscerà che stai cercando di nascondere qualcosa, il che ovviamente aumenterà la sua curiosità.


Purtroppo ho visto anche eSomeEnumusato in alcuni punti; per fortuna non spesso.
Wayne Molina,

2

Acquista una copia delle Linee guida per la progettazione del framework e rilasciala sulla scrivania del tuo manager (o chiunque controlli lo stile di codifica). Assicurati di mettere un post-it che evidenzi in modo evidente l'introduzione dove evidenziano l'importanza della coerenza. Per guidare ulteriormente a casa, il punto ottiene una copia di Clean Code e inserisce un segnalibro nella sezione relativa alle convenzioni di codifica.


1

Per alcuni aspetti questo è un problema soggettivo, ed è uno di quei dibattiti sulla programmazione minutae (ortografia?) Che intrattengo per un po ', quindi evito. Mentre penso che la notazione ungherese sia un peccato che dovrebbe essere bandito, penso che la coerenza sia più importante.

In tal senso, farò del mio meglio per convincere un team a utilizzare la denominazione delle variabili incentrate sul dominio piuttosto che le convenzioni di denominazione basate sul tipo, ma se tutto diventa duro, torno indietro per accettare uno standard di denominazione a cui tutti devono attenersi una base di codice comune.

Non sono a favore di alcuni standard genericamente obbligati imposti da un gruppo di standard, ma i team di software sviluppano il proprio standard e, cosa ancora più importante, si attengono ad esso.


1

Con il resharper rinominare le variabili è così veloce che posso annullare le convenzioni di denominazione considerate così in fretta, che non devo lasciare in piedi le vecchie convenzioni sbagliate.

Se non si dispone di strumenti di refactoring, sono d'accordo con gli altri commentatori che hanno suggerito di seguire quanto più possibile la convenzione esistente della base di codice, anche se era sbagliata. (fino a un certo punto, ci sono convenzioni di denominazione variabili che si trasformano in generatori di bug se li lasci)


0

Molte delle tue preoccupazioni sono valide e renderebbero la vita più facile per un nuovo sviluppatore e probabilmente per la tua sanità mentale. L'unica convenzione che tutti dovresti adottare sono i nomi descrittivi. Dovresti essere in grado di trovare un consenso su questo senza cambiare drasticamente gli stili a seconda di quanto siano cattivi. Per tutto il resto, o aspetta di essere al comando o sostituisci i membri attuali con nuovi sviluppatori che pensano e sentono come fai.


0

Le mie deviazioni:

  • _PublicPropertyBacker
  • _private_property_backer
  • _privateMember
  • CONSTANT_MEMBER
  • privateFunction
  • param_
  • Pulsante privato okBU; //eccetera. limite di 3 caratteri
  • struct SOMESTRUCT // per le strutture pinvoke

Regioni di codice generiche e layout dei file:

  • Membri
    • (privato | interno | protetto | pubblico) X [statico] X [const / sola lettura]
  • Proprietà
    • (privato | interno | protetto | pubblico) X [statico] X [sola lettura]
  • Costruttori
    • (privato | interno | protetto | pubblico) X [statico]
  • Comandi // qualsiasi cosa con ritorno vuoto o ritorno stato
    • (pubblico | protetto | interno | privato) X [statico]
  • Gestori di eventi / privati ​​/
    • (Controllo | Remoto | Assistenza | Altro) Eventi
  • Le funzioni // interrogano lo stato, non dovrebbero avere effetti collaterali
    • (pubblico | protetto | interno | privato) X [statico]
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.