Sono le convenzioni sulla denominazione delle convenzioni che valgono la pena?

L'unica cosa di cui ti dovresti preoccupare è che lavori in una squadra dove le persone non si preoccupano di ripulire un po 'le cose. È molto triste.

Fai quello che fai, continua a usare lo stile moderno e invita le persone (ma non le costringono) ad adottarlo. Ci vorrà del tempo, naturalmente. Dopo un po 'di tempo vedrai se andrà da qualche parte e cosa potresti fare in seguito.

P.S. Che ne dici di organizzare un incontro su questo tema e invitare tutti gli interessati. Quindi riceverai tutta la loro attenzione, indicherà il problema e presenterà il tuo approccio. Darà loro qualcosa a cui pensare. Forse dai tuoi tentativi locali non ti prendono molto sul serio.

Penso che potresti doverti chiedere se la notazione ungherese influisce o meno sul tuo output / qualità personale o se fa più male al tuo ego. Per ego, intendo che le cose generalmente funzionano bene, ma non vorresti mai che qualcuno che rispetti da fuori veda il codice vergognosamente sorpassato. Mentre penso che la preoccupazione abbia i suoi meriti, devi confrontarla con il colpo di qualità / produttività che dovrebbe essere preso da chiunque debba passare.

Questa è una sorta di domanda di debito tecnico, dal momento che sei chiaramente corretto sul fatto che questo stile ungherese non abbia senso in .Net (con l'eccezione delle interfacce con "I", ma questa è un'altra volta), tuttavia questo potrebbe essere il tipo di debito tecnico con cui la tua squadra può convivere finché non si attenua naturalmente .

Il miglior argomento contro la notazione ungherese, accanto ai moderni IDE, che hanno molti metodi per mostrare il tipo, la visibilità e altro materiale di una variabile con il colore, con simboli minuscoli e con tooltiptexts mentre hoovering, è, prenderlo sul serio .

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

Seriamente: durante il refactoring, potresti cambiare una variabile da int a long, da String a char. Non dovresti avere bisogno di cambiare il nome.

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

I caratteri aggiuntivi disturbano la semantica della variabile. Un intero 'sane' ottiene 'i_sane', che assomiglia più a 'pazzo'.

La notazione ungherese era utile nelle lingue, che mancano di un sistema di tipi. Non ne hai bisogno, se il compilatore impone tipi specifici. Se decori il tuo lamento sulla notazione ungherese con un empatico 'sì, per i programmatori più anziani, aveva senso in passato usarlo!', Quei programmatori più anziani potrebbero essere vanitosi, e preferiscono non essere identificati come vecchi.

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

Compra una copia di Linee guida per la struttura del framework e rilasciala sul banco del tuo manager (o chi controlla lo stile di codifica) . Assicurati di mettere un post nota che evidenzi chiaramente l'introduzione in cui evidenziano l'importanza della coerenza. Per guidare ulteriormente il punto, ottenere una copia di Pulisci codice e inserire un segnalibro nella sezione relativa alle convenzioni di codifica .

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

In questo senso farò del mio meglio per convincere un team a utilizzare le nomenclature delle variabili basate sul dominio piuttosto che le convenzioni di denominazione basate sui tipi, ma se tutto si risolve, mi ritroverò ad accettare uno standard di denominazione che tutti devono rispettare su una base di codice comune.

Non sono favorevole ad alcuni standard genericamente obbligatori imposti da un gruppo di standard, ma i team del software sviluppano il loro standard e, cosa ancora più importante, lo rispettano.

Con le variabili di ridenominazione del resharper è così veloce che posso annullare le convenzioni di denominazione errate così velocemente, che non devo lasciare le vecchie convenzioni sbagliate.

Se non si dispone di strumenti di refactoring, quindi, sono d'accordo con gli altri commentatori che hanno suggerito di seguire la convenzione esistente del codebase il più possibile, anche se era sbagliata. (fino a un certo punto ci sono convenzioni di denominazione variabili che si trasformeranno in generatori di bug se le si lascia fare)

La maggior parte delle tue preoccupazioni sono valide e renderebbe la vita più facile per un nuovo sviluppatore e probabilmente per la tua sanità mentale. L'unica convenzione che dovresti adottare è un nome descrittivo. Dovresti essere in grado di raggiungere un certo consenso su questo senza cambiare drasticamente gli stili a seconda di quanto siano cattivi. Per tutto il resto, aspetta di essere responsabile o sostituisci i membri attuali con nuovi sviluppatori che pensano e sentono come te.

Le mie deviazioni:

• _PublicPropertyBacker
• _private_property_backer
• _privateMember
• CONSTANT_MEMBER
• privateFunction
• param _
• Pulsante privato okBU; //eccetera. limitare 3 caratteri
• struct SOMESTRUCT // per le strutture pinvoke

Regioni di codici generici e layout di file:

• Membri
  • (privato | interno | protetto | pubblico) X [statico] X [const / readonly]
• Proprietà
  • (privato | interno | protetto | pubblico) X [statico] X [solo lettura]
• Costruttori
  • (privato | interno | protetto | pubblico) X [statico]
• Comandi // qualsiasi cosa con ritorno vuoto o ritorno dello stato
  • (pubblico | protetto | interno | privato) X [statico]
• Gestori di eventi / privati /
  • (Controllo | Remoto | Servizio | Altro) Eventi
• Funzioni // interrogano lo stato, non dovrebbero avere effetti collaterali
  • (pubblico | protetto | interno | privato) X [statico]