"As" Naming Convention [chiuso]

Anche se in generale sembra bello, e sicuramente migliore del terribile stile ungherese, dove si mettono prefissi ovunque, anche in casi ovvi e auto-descrittivi, tuttavia direi di scrivere i tuoi programmi in modo che non sia necessario avere il stesso pezzo di dati in diversi formati nello stesso contesto .

Ad esempio:

function buildXmlRequest(name, email)
{
    return toXml({'request':
        {'name': name, 'email': email}});
}

function registerUser(name, email)
{
    if (!sendRequest('http://allusers.com/xml',
        buildXmlRequest(name, email)))
            throw "User registration has failed";
}

C'è una leggera curva verso la programmazione funzionale qui: come puoi vedere non ci sono affatto variabili. Il vantaggio di questo è che piccole porzioni di codice apolidi sono in genere meno soggette a errori, specialmente nei linguaggi dinamici, dove un nome di variabile errata può passare inosservato per un lungo periodo.

Un altro vantaggio di questo approccio è che i dati non vengono tenuti in memoria quando non sono più necessari. Nel tuo esempio hai packet AND packetAsJson allo stesso tempo in memoria (e possono essere enormi!) Mentre molto probabilmente ne hai bisogno solo uno alla volta. In ambienti conteggiati di riferimento (PHP) o linguaggi con Garbage Collection (C ++) basata su scope che porta qualche stile funzionale nel tuo programma potrebbe farti risparmiare molte risorse.

Ma ancora una volta, sì, userei questo stile ogni volta che l'approccio funzionale non aiuta molto.

Personalmente, non mi piace questo stile. Sapete già che un float è un float (ecc.) Perché lo avete definito come tale, non è necessario averlo nel nome della variabile. Estende i nomi delle variabili, senza fornire alcuna informazione nuova o utile.

Penso che questa convenzione di denominazione possa essere utile, ma non vedo come una convenzione cui puntare, più come ultima risorsa se non si possono assegnare nomi alle variabili in modo più significativo. Mi sembra che 2 dei tuoi esempi siano solo una versione a più lunga durata della notazione ungherese.

Il nome della variabile dovrebbe riguardare ciò che la variabile rappresenta nella progettazione. Nel tuo primo esempio se l'input dell'utente viene analizzato e convertito in un int, cosa ne farai di seguito - forse è un ID, o un numero di telefono o un codice postale. Qualunque cosa sia, il nome della variabile dovrebbe riflettere ciò e non è necessario codificare il tipo nel nome.

Capisco che potresti finire per convertire un tipo ed entrambe le variabili potrebbero ugualmente giustificare l'uso dello stesso nome - il tuo secondo esempio potrebbe essere un buon esempio di questo. In questo caso tendo ad essere d'accordo con te e in realtà questo non codifica il tipo nel nome della variabile, quindi penso che non sia troppo male. Penso che packetAsJson sia un buon nome in questo contesto.

Cosa succede se hai deciso di cambiare i tipi? Ad esempio, un float non ha più una precisione sufficiente ed è necessario eseguirlo fino a un doppio. Ora devi rifattorizzare tutti i nomi delle variabili per usare Double invece. Sebbene il tuo IDE possa avere strumenti di refactoring di qualità, penso che sarà difficile mantenerlo dopo un po '.

In alcune lingue, questa convenzione di denominazione potrebbe essere eccessiva, come in Java:

List<String> inputsAsList = new LinkedList<String>(....)

Chiunque debba leggere questo sarà presto stanco. Tuttavia, nei linguaggi unityped può essere una buona idea ricordarsi del tipo in cui la variabile è usata, in modo che usi impropri come

inputsAsList = "foo"

sarà esposto, anche se solo ai lettori umani.

Quando ho questo tipo di istruzioni nel mio codice, di solito non faccio altro che aggiungere un semplice i o f o semplicemente usare il nome della classe.

Con l'uso comune degli IDE e, essendo C #, Intellisense, non ha senso aggiungere questi ai tuoi identificatori. Spreca tempo a digitarli e rende l'identificatore troppo lungo.

Ogni cosa dovrebbe essere nominata in base al suo contesto. Se è solo una semplice variabile locale, rendila ovvia ma non ingombrante. Vuoi fare un programma, non scrivere codice per ore.

string input = "123.4";
float fval = float.Parse(input); // I understand what fval is.
int ival = int.Parse(input);

IUnknown foo = MyObjectFactory.CreateFoo();
IVisualizer visualiser = (IVisualizer)foo;
ILocator locator = (ILocator)foo;

Dictionary<string, object> packets = new Dictionary<string, object>();
string json = packets.ToJSON(); // it's obviously the JSON output of packets since that the only context 'json' could be for.

Se hai più istanze, sii solo un po 'più specifico:

IUnknown srcFoo, destFoo;
IVisualiser srcVisualiser, destVisualiser;
ILocator srcLocator, dstLocator;

Per oggetti come matrici:

string inputString = "1,2,3";
string[] separatedInputs = inputString.Split(',');
List<int> inputs = new List(separatedInputs.Length);
foreach(var input in separatedInputs)
    inputs.Add(int.Parse(input));