Due convenzioni di denominazione in C #: cosa ne pensi? [chiuso]

https://stackoverflow.com/questions/823294

05-07-2019
|

Domanda

Ho due convenzioni di codifica C # specifiche che ho praticato con sentimenti contrastanti. Sarei curioso di sentire cosa pensa la gente. Sono:

# 1. Assegna un nome alle istanze dopo la lezione di cui è un'istanza, camelCased

# 2: " Corrispondenza dei nomi delle proprietà "

Ecco la logica:

# 1. Assegna un nome alle istanze dopo la lezione di cui è un'istanza, camelCased

Uso questa come impostazione predefinita per la convenzione di denominazione. Certo, ci sono eccezioni. Ma usato in modo coerente drammaticamente migliora la chiarezza del codice e la manutenibilità. Il codice è simile al seguente:

var dataConnection = new DataConnection();
//not: var dataConn, dbConn, sqlConn, myDbPickOfTheDay etc.

FileInfo fileInfo = new FileInfo();

Timer timer = new Timer(); 

//etc.

Sono nel punto in cui codice come questo mi provoca dolore fisico:

DataConnection dbConn = new DataConnection();

Non posso sottolineare abbastanza come questa convenzione abbia tolto il dolore e la rabbia del gioco a nome variabile.

Questa convenzione è in netto contrasto con il tentativo di nominare le cose in modi che provano a indicare cosa sta facendo l'istanza, il che equivale a provare a incorporare in modo creativo il business case nel codice. Il codice ha un modo per essere refactored al punto in cui quei nomi originali sono fuorvianti nel migliore dei casi.

Per me questa convenzione è oro. Impedisce anche la pratica orribile di nomi di variabili leggermente ottimizzati per la stessa cosa.

Un esempio di questa convenzione in pratica è:

class Person { ...
   public string FirstName { get; set; }

//and then
var person = new Person();
person.FirstName = firstName; //where firstName comes from somewhere else.

Molto facile da leggere. Molto noioso. Noioso è buono quando si tratta di mantenere il codice.

Tuttavia , questa convenzione mi porta a # 2:

# 2 " Corrispondenza dei nomi delle proprietà " (per mancanza di un titolo migliore)

Ecco un esempio:

public class ShoppingCart { ..
  private Item item;
  public Item Item {  //<---- ?
  get { return this.item; } ...

Il compilatore è perfettamente soddisfatto di questo. E, in effetti, espone un'interfaccia molto bella:

//notice how tempting it is to just say "ShoppingCart cart ... "
ShoppingCart shoppingCart = new ShoppingCart();  
shoppingCart.Item = item;

Ora, l'alternativa è quella di essere creativi - In realtà è necessario creare due buoni nomi di variabili per Item: il nome della proprietà pubblica e il nome della variabile del membro privato.

Quante volte l'hai visto e vuoi ritirarti immediatamente?

 public class ShoppingCart { ..
      private Item cartItem;
      public Item ShoppingCartItem { 
      get { return this.cartItem; } ..
  ///....
  ShoppingCart userShoppingCart = new ShoppingCart();
  userShoppingCart.ShoppingCartItem = userSelection;

Sono abbastanza convinto della convenzione n. 1 che penso di poter vivere con la n. 2.

Cosa ne pensi?

Soluzione

nel caso in cui non fossi a conoscenza e se ti interessa, C # ha già uno standard di denominazione

http://msdn.microsoft.com/en -us / library / xzf533w0 (VS.71) aspx

Inoltre, guardando di nuovo le tue convenzioni ... ecco alcuni altri suggerimenti.

fileInfo sembra piuttosto vicino a FileInfo ma non ha altro significato che il tipo che posso ottenere rapidamente passando il mouse sul tipo o in intellisense. Suggerirei di nominare le variabili con significato e un po 'di contesto, se disponibili. remoteWebServerLog, localWebServerLog o persino localWebServerLogFileInfo se ti piace il tipo nel nome.

Se posso dare qualche consiglio dal tornare al codice, hai scritto più di 6 mesi dopo. Ti gratterai la testa cercando di capire e rintracciare cosa diavolo sono tutti i tuoi dbConn e fileInfo. Quale file? Cosa db? Molte app hanno diversi dbs, è questo dbConn per il OrdersDB o il ShoppingCartDB?
I nomi delle classi dovrebbero essere più descrittivi. Preferirei ShoppingCartItem a Item. Se ogni ListBox, DropDown ecc. Ha nominato i propri articoli di raccolta " Item " ti scontreresti con molti spazi dei nomi e saresti costretto a sporcare il tuo codice con MyNameSpace.ShoppingCart.Item.

Detto questo ... anche dopo anni di programmazione, continuo a sbagliare e non seguo le regole il 100% delle volte. Potrei anche aver usato FileInfo fi = ... ma è per questo che adoro il mio Resharper " Refactor- > Rename " comando e lo uso spesso.

Altri suggerimenti

La convenzione n. 1 può diventare confusa. Se dovessi avere due oggetti FileInfo nello stesso metodo, ad esempio una sorgente e una destinazione, dovresti deviare dalla convenzione per nominare i due.

I nomi delle variabili devono essere mnemonici, per indicare all'osservatore casuale l'intenzione del suo uso.

Forse saresti più felice con una combinazione delle due convenzioni ... come sourceFileInfo e targetFileInfo, per questo esempio.

Ovviamente, non puoi nominare ogni System.String nel tuo progetto string *, ma per cose che non usi molto, esp. cose di cui hai solo bisogno di una, e la cui funzione nel tuo codice è evidente dal suo nome, queste convenzioni di denominazione sono perfettamente accettabili.

Sono comunque quello che faccio.

Vorrei scegliere un nome più specifico per, ad esempio, l'oggetto Timer. A cosa serve un timer? Ma definirei sicuramente un DataConnection dataConnection.

* Anche se " string " non era una parola chiave ...

Faccio sempre 1 e lo trovo molto leggibile. Sono sul recinto con 2. Lo trovo confuso in determinate situazioni, principalmente perché è difficile distinguere il tipo dalla proprietà a causa degli identificatori identici.

Normalmente seguirò la convenzione n. 1, anche se per i nomi di classe lunghi tendo a usare solo le iniziali della classe. Se mi riferissi a più di un oggetto dello stesso tipo, pre-penderei il nome del tipo con un nome che indica quale è o a cosa serve.

Uso abbastanza spesso la convenzione n. 2 se ha senso. Non c'è niente di peggio che avere qualcosa come l'esempio che hai elencato nel carrello.ShopingCartItem, il fatto stesso che sia una proprietà di ShoppingCart rende totalmente ridondante quella parte del nome della proprietà. Tuttavia, molto probabilmente chiamerei la classe ShoppingCartItem e la proprietà Item. L'articolo ha un nome un po 'troppo generico, mentre ShoppingCartItem ti dice con quale tipo di oggetto stai lavorando.

Seguo sempre la convenzione 1. Tuttavia, aggiungo un qualificatore aggiuntivo se ci sono due oggetti affiancati.

Ma detto questo, rendere obbligatoria questa convenzione può essere problematico:

In un determinato contesto carrello può essere un nome abbastanza buono per un oggetto ShoppingCart (se, ad esempio, non ci sono altri 'cart' nella stessa funzione per essere confuso con).
A volte la convenzione può oscurare completamente lo scopo dell'oggetto dichiarato. Ad esempio Window scoreBoard = new Window () dice che abbiamo un oggetto che è effettivamente una finestra ma che viene utilizzato come scoreBoard. Molto espressivo. Ma dopo la convenzione 1 dovresti scrivere Window window = new Window () che nasconde totalmente l'intenzione dietro questa finestra.

Quindi direi di usare questa idea di denominazione ovunque tranne quando ostacola il significato o appare irragionevolmente impegnativo.

Riguardo alla convenzione 2, sono totalmente d'accordo. Mantenere i nomi delle proprietà sintetici e lasciare che il nome dell'oggetto completi il ??pieno significato della sua invocazione è una cosa elegante. Funziona perfettamente con oggetti ben nominati. Quindi ci sono poche ragioni per essere timidi di usarlo.

Non mi piace molto l'idea di avere più identificatori nell'ambito che differiscono solo nel loro uso di maiuscole / minuscole; se avessi i miei druther, il codice che utilizzava un identificatore sarebbe necessario per utilizzare la stessa combinazione di lettere maiuscole / minuscole della sua dichiarazione, ma al codice non sarebbe consentito dichiarare due identificatori nello stesso ambito che differiscono solo per caso, né accedono qualsiasi identificatore che, ad eccezione del caso, corrisponderebbe a un identificatore in un ambito interno. Sebbene nessun linguaggio che conosco (certamente non VB né C #) faccia rispettare tali regole, il codice scritto in conformità con tali regole potrebbe essere liberamente trasportabile tra linguaggi sensibili al maiuscolo e al minuscolo senza dover rinominare gli identificatori.

Di conseguenza, non mi piace lo schema n. 2. La conformità CLS richiede che tutti gli identificatori di quello stile siano limitati all'ambito privato o interno . Poiché sia ??vb.net che C # consentono ai nomi di iniziare con caratteri di sottolineatura, se una proprietà è denominata Trait , non vedo alcun motivo per favorire tratto rispetto a _trait . L'uso di quest'ultimo nome distinguerebbe chiaramente i casi in cui il programmatore ha voluto scrivere sulla variabile di supporto da quelli in cui il dito è scivolato sul tasto Maiusc.

Per quanto riguarda il modello n. 1, nei casi in cui l'intero scopo di un tipo o metodo si risolve attorno a un singolo oggetto incapsulato di un determinato tipo, preferisco aggiungere un prefisso ai campi con my o parametri con il . Anche nei casi in cui il compilatore consentirebbe di utilizzare gli stessi nomi per membri e parametri di istanza, l'utilizzo di prefissi distinti evita la possibilità di utilizzare accidentalmente uno dove è richiesto l'altro.

Autorizzato sotto: CC-BY-SA insieme a attribuzione

Non affiliato a StackOverflow