"A", "an" e "the" nei nomi dei metodi e delle funzioni: cosa ne pensi? [chiuso]

Question

"A", "an" e "the" nei nomi dei metodi e delle funzioni: cosa ne pensi? [chiuso]

#1 da (21 voti)
#2 da (10 voti)
#3 da (9 voti)
#4 da (7 voti)
#5 da (2 voti)
#6 da (0 voti)

16

Sono sicuro che molti di noi hanno visto nomi di metodi come questo in un punto o in un altro:

UploadTheFileToTheServerPlease
CreateATemporaryFile
WriteTheRecordToTheDatabase
ResetTheSystemClock

Cioè, nomi di metodi che sono anche frasi inglesi grammaticalmente corrette, e includono parole extra puramente per farle leggere come prose. Personalmente, non sono un grande fan di questi metodi "letterali" e preferisco essere succint, pur essendo il più chiaro possibile. Per me, parole come "a", "an" e "the" sembrano semplicemente scomode nei nomi dei metodi e rendono inutilmente lunghi i nomi dei metodi senza aggiungere nulla di utile. Preferirei i seguenti nomi di metodo per gli esempi precedenti:

UploadFileToServer
CreateTemporaryFile
WriteOutRecord
ResetSystemClock

Nella mia esperienza, questo è molto più comune dell'altro approccio di scrivere i nomi più lunghi, ma ho visto entrambi gli stili ed ero curioso di vedere quali erano i pensieri degli altri su questi due approcci.

Quindi, sei nel campo "i nomi dei metodi che leggono come prosa" oi "nomi dei metodi che dicono ciò che intendo, ma leggi ad alta voce come una brutta traduzione da lingua straniera a inglese" campo?

coding-style naming

posta Mike Spross 16.09.2010 - 06:56

fonte

6 risposte

Leggi altre domande sui tag coding-style naming

I DB multi-tenant hanno più database o tabelle condivise? La corrispondenza del modello rispetto a tipi di design idiomatici o scadenti?

score 21 · Answer 1

Sono d'accordo che i metodi di prosa fanno schifo con un'eccezione:

Casi test unità

Generalmente non vengono mai chiamati nel tuo codice e vengono visualizzati nei rapporti di test. In quanto tale, è utile avere letture con un po 'più di prosa:

AddingACustomerOrderFailWhenCustomersIdIsInvalid: non riuscito
OutOfBoundsPriceReturnsAnError: passato
CanDeleteAnEventFromASeason: superato

Anche questo dovrebbe essere fatto con parsimonia, ma posso vederlo come almeno un caso in cui le aggiunte grammaticali possono rendere un po 'più facile esprimere ciò che è passato e ciò che è fallito. Questo è, naturalmente, a meno che il tuo linguaggio / framework non fornisca un buon meccanismo per le descrizioni dei test nella lettura del test oltre ai nomi dei metodi, nel qual caso ignora anche questo.

score 10 · Answer 2

10

Per parafrasare Lawrence da Office Space ...

No, no, man, I do believe that if someone I worked with around here named a function 'UploadTheFileToTheServerPlease', he'd get his a-- kicked, man.

risposta data 16.09.2010 - 07:12

fonte

score 9 · Answer 3

Tali nomi "lunghi" non sembrano prose . Quando sono soli, forse, ma accompagnati dal resto del codice, fanno solo più casino. Dai un'occhiata:

bool ResultOfTheUpload
      = UploadTheFileToTheServerPlease(TheNameOfTheFile, TheServersAddress);

Yuuuuk! ..

Questo non è un testo inglese valido e in nessun linguaggio di programmazione sarà simile a uno. Quindi non ha senso spendere byte sugli articoli.

score 7 · Answer 4

Dal punto di vista dei programmatori "UploadFileToServer" ha più senso e più facile lettura e comprensione di "UploadTheFileToTheServerPlease".

Più della grammatica, della leggibilità e della comprensibilità della lingua inglese è più importante nella programmazione!

score 2 · Answer 5

Dato il numero di errori di battitura della mia vita, mi ritroverei con

* UploadTehFileToTehServerPleaz
* WriteTehRecordToTehDatabase
* ResetTehSystemClock
* ICanHazTehCheezburger

Seriamente, guarderei anche come era il mio nome di classe. Se la mia classe fosse chiamata "File", probabilmente andrei solo con

*UploadToServer
*DownloadFromServer

Quindi sarebbe

   File file = new file;
   file.UploadtoServer(ServerAddress);

Solo un esempio banale, ma si spera che sia sufficientemente illustrativo.

score 0 · Answer 6

Personalmente non mi interessa. Li ho visti e non mi danno fastidio. Non ci pensavo nemmeno fino a quando un altro programmatore non si è messo a parlare di loro. Ho trovato scioccante che a qualcuno interessasse tanto qualcosa che conta così poco. Voglio dire che era davvero arrabbiato per questo. Ma questo era all'inizio della mia carriera, circa 11 anni fa, e da allora ho scoperto che gli sviluppatori che si arrabbiano per cose minori sono in realtà abbastanza comuni. È per questo che i manager degli sviluppatori vengono pagati così bene. Devono confrontarsi con gli sviluppatori su base giornaliera.

E preferirei vederlo di "UL_FlToSrv".