Articoli nei nomi di variabili

Nella maggior parte dei casi aggiungono poco o nessun valore, ma rendono il codice più lungo da leggere.

Di solito, raramente ho bisogno della distinzione tra "a" o "il" nel flusso di una funzione, quindi non ha senso usare gli articoli.

È un linguaggio di programmazione formale e io sto bene senza leggere esattamente come un linguaggio naturale. In effetti, probabilmente è meglio così, non tutto è necessariamente così eccezionale sui linguaggi naturali.

Ci sono alcuni casi in cui la leggibilità può trarre beneficio dall'uso degli articoli, ad esempio se si desidera implementare un correttore per una relazione "è una" con una firma del metodo come boolean isA(Object o, Class<?> cl) ^{(non sto sostenendo questa è una buona idea)} .

Stringhe con codifica hard

Dipende se si prevede di riutilizzarli o meno, e se tale riutilizzo è guidato dalla semantica (e non solo dal fatto che la Stringa ha lo stesso contenuto in luoghi diversi) e diffusa in più classi o sottosistemi.

In tal senso, di solito uso queste regole:

1. Se hai la stessa stringa più volte e ha lo stesso significato acros di più classi, quindi estrai in costanti in un'interfaccia.

2. Se hai la stessa stringa più volte all'interno di una singola classe e ha lo stesso significato all'interno di quella classe, quindi estrai alle costanti all'interno della classe.

3. Se hai solo un numero limitato di ripetizioni come tring, o se sono identiche ma non è garantito che siano sempre in futuro, allora le lascerei in linea.

4. Se una delle situazioni precedenti renderebbe difficile la manutenzione, imposta le regole da 1 a 3 e fai tutto il possibile per te.

Ovviamente, assicurati che il nome della costante renda il codice semanticamente valido come la stringa che contiene. Ciò vale anche per altre cose che non sono stringhe (come i Predicati, per esempio).

For hard-coding strings, the three sides are whether to put all strings into constants (public static final) in a separate file (class or interface), put them all in the same file (private static final), or don't use constants for strings at all. (e.g. new Button("Click Me") vs. new Button(BUTTON_LABEL_CLICK)). We also discuss the Hungarian notation issue quite a bit but I've seen that discussed here in other questions.

Se si desidera un'esperienza utente di alta qualità, tutto ciò che viene presentato all'utente (etichette dei pulsanti, messaggi di errore, ecc.) deve essere esaminato dal progettista dell'interfaccia utente. Nella mia esperienza, quando gli sviluppatori stanno scrivendo il codice, ciò non accade. Gli sviluppatori fanno il meglio che possono, ma il risultato è un insieme di messaggi ed etichette che sono poco più che casuali.

Apple usa gli articoli - in modo incoerente - nel loro codice ObjC. Aggiunge niente alla leggibilità del loro codice o alla descrittività dei loro nomi di variabili:

- (id)viewWithTag:(NSInteger)aTag;
- (id)initWithFrame:(NSRect)frameRect mode:(int)aMode cellClass:(Class)factoryId numberOfRows:(int)rowsHigh numberOfColumns:(int)colsWide;

Nota aTag e aMode rispetto a frameRect .

Odio il semi-standard e non lo uso. Rende il codice suonato come un idiota.