Usi articoli nei nomi delle variabili?

Question

Modifica: Sembra che ci siano almeno due validi motivi per cui Smalltalkers fa ciò (leggibilità durante i problemi di concatenamento e di scope) ma forse la domanda può rimanere aperta più a lungo per affrontare l'uso generale.

Originale: Per ragioni che ho dimenticato da tempo, non uso mai articoli nei nomi delle variabili. Per esempio:

aperson, thecar, anObject

Credo che mi sento come articoli sporchi i nomi con informazioni prive di significato. Quando vedevo il codice di un collaboratore usando questa convenzione, la mia pressione sanguigna si accelerava leggermente.

Recentemente ho iniziato a imparare Smalltalk, principalmente perché voglio imparare la lingua che Martin Fowler, Kent Beck e tanti altri grandi sono cresciuti e amati.

ho notato, tuttavia, che Smalltalkers sembrano utilizzare per ampiamente indefiniti articoli (una, un) nei loro nomi delle variabili. Un buon esempio potrebbe essere nel seguente metodo Setter:

name: aName address: anAddress. 
    self name: aName. 
    self address: anAddress 

Ciò mi ha indotto a riconsiderare la mia posizione. Se una comunità è molto rispettata e influente come Smalltalkers ha ampiamente adottato articoli nella denominazione delle variabili, forse c'è una buona ragione per farlo.

Lo usi? Perché o perché no?

Answer 1

Questa convenzione di denominazione è uno degli schemi del libro di Kent Beck Modelli Smalltalk Best Practice. IMHO questo libro è un must-have anche per i non-smalltalker, in quanto aiuta davvero a dare un nome alle cose e scrivere codice di auto-documentazione. Inoltre è probabilmente uno dei pochi pattern langages ad esibire Alexander's quality without a name.

Un altro buon libro sui modelli di codice è Smalltalk con Style, che è available as a free PDF.

In genere, la convenzione è che le variabili di istanza e gli accessor utilizzano il sostantivo nudo e i parametri utilizzano l'articolo indefinito più un ruolo o un tipo o una combinazione. Le variabili temporanee possono usare nomi nudi perché raramente duplicano la variabile di istanza; in alternativa, è abbastanza frequente nominarli con maggiore precisione rispetto a un articolo indefinito, per indicare il loro ruolo nel flusso di controllo: eachFoo, nextFoo, randomChild ...

Answer 2

Ho sempre sentito gli articoli sporcare i nomi con informazioni prive di significato.

Esattamente. E questo è tutto il motivo per cui gli articoli sono saltati: ingombrano il codice inutilmente e non forniscono ulteriori informazioni.

Non conosco Smalltalk e non posso parlare dei motivi delle "loro" convenzioni, ma in qualsiasi altro luogo, come sopra. Lì potrebbe essere essere una semplice ragione tecnica dietro la convenzione Smalltalk (ad esempio ALL_CAPS in Ruby, che è una costante non solo per convenzione ma a causa della semantica del linguaggio).

Answer 3

mai usato, forse perché nella mia lingua principale non ci sono articoli: P

In ogni caso penso che fino a quando il nome di variabile è significativa non è importante se ci sono articoli o no, tocca a codificatore di propria preferenza

Answer 4

È in uso in Smalltalk come un linguaggio senza nome perché suggerisce lo tipo di un argomento nella chiamata al metodo. Lo stesso articolo segnala che hai a che fare con un'istanza di qualche oggetto della classe specificata.

Ma ricordate che in Smalltalk i metodi guardano in modo diverso, usiamo i cosiddetti messaggi di parole chiave e in questo caso gli articoli effettivamente aiutare la leggibilità:

anAddressBook add: aPerson fromTownNamed: aString 

Answer 5

Nope.Sento che è uno spreco di spazio per i personaggi ed erode la leggibilità del tuo codice. Potrei usare variazioni del nome, ad esempio Person vs People a seconda del contesto. Ad esempio

ArrayList People = new ArrayList(); 
Person newPerson = new Person(); 
People.add(newPerson); 

Answer 6

No, non lo faccio. Non mi sembra che aggiunga nulla alla leggibilità o alla manutenibilità della mia base di codice e non distingue la variabile per me in alcun modo.

L'altro lato negativo è se si incoraggiano gli articoli nei nomi delle variabili, è solo una questione di tempo prima che qualcuno lo faccia nel codice base.

var person = new Person(); 
var aPerson = GetSomeOtherPerson(); 

Answer 7

penso che ho appena trovato un risposta. Come detto Konrad Rudolph, usano questa convenzione a causa di un motivo tecnico:

... questo significa che [metodo variabile] non può duplicare il nome di una variabile di istanza, una variabile temporanea definita nell'interfaccia, o un'altra variabile temporanea. - IBM Smalltalk Tutorial

Fondamentalmente un metodo variabile locale non possono essere denominati come una variabile oggetto/classe. Venendo da Java, ho assunto le variabili di un metodo sarebbe scope a livello locale, e vi piacerebbe accedere alle variabili di istanza utilizzando qualcosa di simile:

self address 

Ho ancora bisogno di saperne di più sul metodo/scoping locali in Smalltalk, ma sembra che non abbiano altra scelta; essi devono utilizzare un nome di variabile diverso da quello di istanza, quindi un indirizzo è probabilmente l'approccio più semplice. Utilizzando solo indirizzo risultati in:

Name is already defined ->address 

se si dispone di un'istanza variabile indirizzo definito già ...

Answer 8

Dove lavoro, lo standard è quello di precedere tutti i campi di istanza con "il-" , variabili locali con "my-" e parametri del metodo con "a-". Credo che ciò sia avvenuto perché molti sviluppatori utilizzavano editor di testo come vi al posto degli IDE che possono visualizzare colori diversi per ambito.

In Java, dovrei dire che preferisco la scrittura di setter in cui si denomini questo.

Confronta

public void setName(String name) { 
    this.name = name; 
} 

contro

public void setName(String aName) { 
    theName = aName; 
} 

La cosa più importante è avere uno standard e per tutti di aderire ad esso.

Answer 9

I wobble avanti e indietro sull'utilizzo di questo. Penso che dipenda dal rapporto tra C++ e Objective C nei miei progetti in qualsiasi momento. Per quanto riguarda la base e il ragionamento, Smalltalk rese popolare la nozione di oggetti come "cose". Penso che sia stato Yourdon e Coad che ha fortemente spinto a descrivere le classi in prima persona. In Python sarebbe qualcosa come il seguente frammento. Spero davvero di ricordare abbastanza SmallTalk per mettere insieme un esempio "corretto".

class Rectangle: 
    """I am a rectangle. In other words, I am a polygon 
    of four sides and 90 degree vertices.""" 
    def __init__(self, aPoint, anotherPoint): 
     """Call me to create a new rectangle with the opposite 
     vertices defined by aPoint and anotherPoint.""" 
     self.myFirstCorner = aPoint 
     self.myOtherCorner = anotherPoint 

Nel complesso, si tratta di un approccio colloquiale alla leggibilità del programma. Usare articoli con nomi variabili era solo una parte dell'intero idioma. C'era anche un idioma che circonda la denominazione di parametri e selettori di messaggi IIRC. Qualcosa di simile:

aRect <- [Rectangle createFromPoint: startPoint 
        toPoint: otherPoint] 

E 'stato solo un altro capriccio di passaggio che si apre ancora ogni tanto. Ultimamente ho notato che nomi di membri come myHostName stanno spuntando in codice C++ in alternativa a m_hostName. Sto diventando sempre più innamorato di questo utilizzo che ritengo tornasse un po 'agli idiomi di SmallTalk.