Usi convenzioni particolari per nominare variabili complementari?

Question

Mi trovo spesso a cercare di trovare buoni nomi per coppie complementari di variabili; dove due variabili indicano concetti opposti, due partecipanti a una sorta di duologo e così via.

Questo potrebbe essere meglio spiegato da un contro-esempio: mantengo un'app che stampa due grafici come parte di un annuncio pubblicitario. Sono memorizzati nel database come TopLogo e LowerLogo , che devo interrompere e ricontrollare ogni volta che li utilizzo perché mi aspetto top per integrare bottom e lower dovrebbe integrare upper .

Ci sono alcuni esempi ovvi che penso funzionino bene:

client / server
source / target per copiare / spostare dati o file da una variabile all'altra
minimo / massimo

ma ci sono alcuni concetti che non si prestano a schemi di denominazione così accurati. Ad esempio, quando si esegue il paging attraverso i record, "last" significa "final" o "precedente"? Recentemente ho visto del codice che utilizzava firstPage , previousPage , nextPage e finalPage per evitare l'ambiente lastPage completamente, che pensavo fosse molto battuto, quindi questa domanda.

Hai delle coppie di nomi di variabili particolarmente pulite che ti piacerebbe condividere con noi? (Punti bonus se hanno la stessa lunghezza, il che rende il codice molto più ordinato nei caratteri a spaziatura fissa.)

Answer 1

Come per tutti i tipi di convenzioni sullo stile del codice, la coerenza è ciò per cui dovresti cercare.

Vorrei che il team di sviluppo fosse d'accordo su " standard " coppie di prefissi per scenari comuni come " sorgente / destinazione " o " da / a " e poi attenersi a loro per l'intero progetto. Fintanto che ogni sviluppatore è a conoscenza di cosa si intende con un prefisso particolare nella base di codice, è più facile evitare incomprensioni.

Le eccezioni alla regola dovrebbero essere chiarite nella documentazione se la variabile fa parte di un'API pubblica o nei commenti all'interno del codice, se la visibilità è limitata a una singola classe o metodo.

Answer 2

Nei miei database troverai molte tabelle temporali con stato valido (" storia ") contenenti una coppia di colonne denominate start_date e end_date . Nessun punto bonus per me, quindi, perché preferirei usare la "fine" comunemente usata piuttosto che cercare di trovare un'alternativa intuitiva con lo stesso numero di caratteri della parola "inizio".

Tendo a preferire questi termini generici anche quando termini più specifici del contesto possono essere praticabili, ad es. preferendo employee_start_date rispetto a employee_hire_date (cosa succederebbe se il loro impiego fosse iniziato per un motivo diverso dall'assunzione formale, ad esempio la loro società era oggetto di un'acquisizione). Detto questo, preferirei person_birth_date rispetto a person_start_date :)

Answer 3

Mentre si cerca di essere semanticamente coerenti in casi ovvi - ad esempio, il massimo va con il minimo e non "il più basso"; - nel codice OO ben strutturato (che non è tutto il codice, lo so) il problema scompare con un buon IDE. Le classi sono brevi, i metodi sono brevi e le variabili sono poche in ciascun metodo. Quindi non importa come chiamate le coppie di variabili purché siano chiare. Il tuo codice potrebbe non sembrare professionale, ma la vera qualità è nel codice, non nel aspetto del tuo codice.

Il problema scompare ulteriormente se esiste un buon JavaDoc o qualunque sia il sistema di documentazione e se hanno dei nomi di classe validi. Ad esempio, se hai un'istanza di una classe Connection e ha un metodo un metodo chiamato setDestination , va bene, ma se sai che setDestination accetta un parametro chiamato < code> destinazione ed è della classe Server , sei forte ... anche se potresti preferire chiamarlo target , aimHere , placeToSendTheData o qualunque (e i nomi corrispondenti, source , comingFromHere e placeToGetTheDataFrom ). Inoltre, il sistema doc dice a cosa serve , e questo non ha prezzo.

La prossima cosa potrebbe sembrare stupida e sono sicuro che verrò votato qui su StackOverflow, ma i nomi di variabili dal suono univoco non professionale hanno un grande vantaggio: so che le mie variabili hanno nomi come placeWeWantTheDataToGo (e l'IDE si occupa di digitarlo), ma il "serio" i ragazzi che fanno il JDK non userebbero mai nomi così sciocchi. Quindi so immediatamente che la variabile è una delle mie. Per inciso, quando ho lavorato con sviluppatori in Spagna e in Italia, scrivono codice con nomi di variabili spagnoli (non sempre, ma di solito). Ciò provoca lo stesso effetto: possiamo vedere rapidamente che la classe Conexion è nostra, ma la classe Connection non lo è.

[Inoltre, invece di digitare i nomi delle variabili, assegna loro una stringa costante da qualche parte nel codice e usala, quindi se la chiamano inferiore o inferiore invece di bassa, stai ancora bene.]

Answer 4

Sì, provo a nominare sistematicamente insiemi complementari di variabili in modo che la simmetria sia chiara. Non è sempre facile; a volte, nemmeno possibile. Bene, non è possibile usare le regole che stabilisco per me stesso - il che significa che di solito cerco di avere i nomi della stessa lunghezza. L'esempio "superiore" e "inferiore" mi farebbe impazzire (supponendo che non sia già impazzito, il che è tutt'altro che certo); Probabilmente userei 'upper' e 'lower' perché quelli hanno la stessa lunghezza; 'top' e 'bottom' mi frustrerebbero anche a causa della differenza di lunghezza.