Nomi di variabili per bit di informazioni di contatto [chiuso]

Question

Nomi di variabili per bit di informazioni di contatto [chiuso]

#1 da (3 voti)

2

Sono nel mezzo del codice di refactoring e vorrei avere qualche idea sulla denominazione delle variabili in modo che i miei nuovi nomi rappresentino chiaramente i dati che contengono.

Ho una classe chiamata ContactMethod che ha senso per me; ogni istanza è un modo diverso per contattare qualcuno. Il mio problema arriva quando si nominano le proprietà di ContactMethod . Ad esempio, un'istanza potrebbe essere un numero di fax 555-555-5555, mentre un altro potrebbe essere un indirizzo e-mail di [email protected]; Ho una proprietà chiamata contactMethodType per contenere i valori "fax" o "email", ma non so come chiamare la parte "555-555-5555" o "[email protected]". Qualcuno qui ha creato un buon nome generico per questo pezzo di informazioni di contatto?

(PS - la vecchia convenzione era chiamarla "Telefono" con campi "phoneType" contenente il valore "fax" / "email" e "phoneId" contenente il numero / l'indirizzo. em>

variables naming

posta RustyTheBoyRobot 28.06.2012 - 18:54
fonte

1 risposta

3

A mio parere, se non riesci a pensare a un nome significativo per un'astrazione, significa che probabilmente l'astrazione non ti aiuterà. Per curiosità, perché chiamarlo ContactMethod ti aiuta o ha più senso di una classe Telefono e email separata?

Le astrazioni dovrebbero fornire comportamenti comuni per entità simili. Non so nulla del particolare problema che stai cercando di risolvere, ma in fondo non riesco a vedere molto in comune tra un numero di telefono e un indirizzo e-mail. Ad esempio, la tua convalida seguirà probabilmente regole completamente diverse e il modo in cui utilizzi un indirizzo e-mail per contattare qualcuno (inviando loro un messaggio di posta elettronica) è diverso dal modo in cui li contatti con il loro numero di telefono.
(Inoltre, il fatto che tu stia memorizzando un ContactType separato suggerisce che il tuo codice potrebbe essere pieno di if(type == phone) else if(type == email) ecc.)

IMO è ok (e talvolta meglio / desiderabile) creare dati / entità separati per cose che sono logicamente differenti. A volte puoi provare troppo a trovare una soluzione unica per tutte le dimensioni che alla fine non ti semplifica la vita

risposta data 28.06.2012 - 19:21
fonte

Leggi altre domande sui tag variables naming

Cambiamenti nella licenza nel progetto biforcato quali sono i miei diritti? Come gestisci i test delle tue javascript?

score 3 · Accepted Answer

A mio parere, se non riesci a pensare a un nome significativo per un'astrazione, significa che probabilmente l'astrazione non ti aiuterà. Per curiosità, perché chiamarlo ContactMethod ti aiuta o ha più senso di una classe Telefono e email separata?

Le astrazioni dovrebbero fornire comportamenti comuni per entità simili. Non so nulla del particolare problema che stai cercando di risolvere, ma in fondo non riesco a vedere molto in comune tra un numero di telefono e un indirizzo e-mail. Ad esempio, la tua convalida seguirà probabilmente regole completamente diverse e il modo in cui utilizzi un indirizzo e-mail per contattare qualcuno (inviando loro un messaggio di posta elettronica) è diverso dal modo in cui li contatti con il loro numero di telefono.
(Inoltre, il fatto che tu stia memorizzando un ContactType separato suggerisce che il tuo codice potrebbe essere pieno di if(type == phone) else if(type == email) ecc.)

IMO è ok (e talvolta meglio / desiderabile) creare dati / entità separati per cose che sono logicamente differenti. A volte puoi provare troppo a trovare una soluzione unica per tutte le dimensioni che alla fine non ti semplifica la vita