Cosa rende "buono stile" in Java? [chiuso]

9

Avevo posto questa domanda su StackOverflow e prima che venisse fischiato, ho ricevuto l'utile suggerimento di Péter Török che questo potrebbe essere un posto migliore per pubblicarlo.

Sto programmando in Java da alcuni anni. Ho discusso spesso delle decisioni di progettazione con i colleghi sulla base di ciò che costituisce un "buon stile". In effetti, ci sono un certo numero di domande / risposte StackOverflow che discutono di un progetto sulla base del fatto che qualcosa sia o meno "buono stile".

Ma cosa rende il "buon stile"? Come molte cose, lo so quando lo vedo ... ma volevo avere un'idea migliore della mia coscienza dicendo che questo design non sembra giusto.

Quali sono le cose a cui pensi per produrre codice valido e ben progettato?

(Riconosco che questo è in qualche modo soggettivo, poiché ciò che è "buon stile" dipenderà dal compito da svolgere). (Inoltre, dovrei aggiungere che non sono interessato agli stili di squadra, ad esempio "usiamo rientri di 2 spazi anziché 4" ... e non sono interessato alle convenzioni del codice Java.)

Modifica: grazie per tutte le buone risposte / commenti finora. Sono particolarmente appassionato di risposte che aiuterebbero a codificare quelle cose che fanno stravolgere la coscienza di un programmatore (e forse lo stomaco)?

java coding-style

— amaidment
fonte

Tra le molte altre cose elencate qui, mi assicurerei sicuramente di affermare semplicemente che i computer possono compilare il codice in qualsiasi modo tu lo scriva, ma alla fine, il codice deve essere leggibile dall'uomo . Commenta come un matto! Un buon test che mi piace usare: una persona potrebbe leggere solo i miei commenti per sapere cosa fa il codice, quali dovrebbero essere gli input e gli output e gli algoritmi utilizzati per farlo?

— Brian,

1

@brian, fai spiegare al tuo codice come . Lascia commenti reali per spiegare il perché . In altre parole, non commentare come un matto (nel caso generale)

4

Brian: Quella tecnica non è sicuramente considerata una buona pratica. La buona pratica comune è mirare a rendere il codice il più autocompattante possibile (con nomi variabili chiari e coesione delle funzioni), con commenti che spieghino il "perché" e non il "come". I commenti che spiegano ogni piccolo dettaglio sono generalmente considerati fonte di distrazione e spesso pericolosi, poiché le persone hanno meno probabilità di conservare i commenti rispetto al codice.

— Casey Patton,

1

@Brian: la tua ultima affermazione dice tutto. Il codice dovrebbe essere leggibile. I commenti diventano stantii. Il codice non lo fa mai. Se senti la necessità di commenti, rifletti fino a quando il codice non è così chiaro che i commenti dovrebbero semplicemente ripetere ciò che dice il codice. L'unico commento positivo è quello che dice perché il codice funziona in un modo particolare - come evitare un bug in una libreria di terze parti - in modo che qualcuno non torni indietro e lo cambi in qualcosa che non funzionerà per un motivo questo non è immediatamente evidente.

— Ryan Stewart,

2

Sono stato ufficialmente umiliato. Siamo spiacenti @amaidment. Immagino sia necessario ricercare buoni standard di codifica quando si tratta di commenti.

— Brian,

17

Alcuni brevi punti:

Nomi rivelatori di intenti
Nessun commento non istruttivo
Nessun metodo con una complessità così alta da non poterlo mettere in testa tutto in una volta
Oggetti a responsabilità singola
Segui le convenzioni sul codice (hai detto che non ti importava, ma è di vitale importanza)

— Ryan Stewart
fonte

3

+1. Forse il più critico: minimizzare il codice duplicato. Se sei tentato di tagliare e incollare più di alcuni token, devi estrarre una funzione. Anche se la funzione è una singola riga di codice.

— Kevin Cline,

4

Sul codice duplicato, prendo la seguente posizione. Taglia e incolla = ok. Questo è solo lo spostamento del codice (supponendo che tu usi incolla una volta). Copia e incolla = orribile. Se rimuovi semplicemente il pulsante Copia dal tuo vocabolario, hai maggiori probabilità di fare la cosa giusta.

— jsternberg,

@jsternberg: +1 per la distinzione taglia / copia, ma noto che molte persone dicono "taglia / incolla" quando intendono "copia / incolla". Non so come si sia persa la distinzione.

— Ryan Stewart,

5

Non essere ripetitivo. Non essere ripetitivo. Non essere ripetitivo.

— configuratore

1

@configurator, hai un odore un po 'divertente ...

9

Aggiunta all'elenco di Ryan:

Seguire i principi SOLID
Assicurati che il tuo codice non abbia troppa complessità ciclica
Test Driven Java è sempre una buona cosa
Se hai una xFactoryFactorylezione, la stai sbagliando :-)
Date le librerie open source nell'ecosistema Java, reinventare la ruota è un cattivo stile
Utilizzare l' ora di Joda per data e ora

Mi fermerò qui.

— Martijn Verburg
fonte

2

E la HammerFactoryFactoryFactoryclasse? ;-)

— Wayne Molina,

@Wayne, le fabbriche indicano che alcune decisioni devono essere ritardate, e FactoryFactoryFactories indica che c'è una decisione che doveva davvero essere presa in fase di esecuzione ma non poteva.

Lo so, ero sarcastico e riferivo a quell'articolo sul perché allora-J2EE era eccessivamente complesso, con HammerFactories e HammerFactoryFactories e penso HammerFactoryFactoryFactories. :)

— Wayne Molina,

@Martijn - grazie per il collegamento SOLID; Non l'ho mai visto prima. Suggerisci di usare JodaTime; è solo una (appropriata) avversione per le classi Calendario / Data di Java? Che dire di JSR310 (il successore di JodaTime)?

— amaidment,

Si spera che JSR-310 arrivi a Java 8 (ci sono un sacco di noi che si stanno preparando per provare ad aiutare a farlo, contattami se vuoi essere coinvolto). Nel frattempo, Joda time è il defacto standard per gestire la data e l'ora in Java. Ci sono così tante cose che non vanno nel sistema Date e Calendar di Java che non so nemmeno da dove cominciare ;-). Il killer è che le date sono mutevoli e che non esiste il concetto di un istante o di un periodo o ... no, mi fermerò qui :-).

— Martijn Verburg,

1

Pur apprezzando le risposte degli altri, ho pensato che fosse giusto condividere alcune delle cose a cui penso quando provavo a scrivere un buon codice:

cosa bisogna sapere su questa classe / metodo / variabile? cioè dove dovrebbe vivere questa conoscenza?
in che modo questo codice può influire sulla memoria / sulle prestazioni della mia applicazione? (Riconosco che "l'ottimizzazione prematura è la radice di tutti i mali"; quindi non sto suggerendo di dedicare molto tempo all'ottimizzazione, ma piuttosto una coscienza mentre inizialmente scrivo il mio codice.)
è chiaro (dal codice e dalle strutture del codice) che cosa fa? (Cerco di seguire la massima: "Sforzati di non permettere alle persone di capire, sforzati di rendere impossibile alle persone fraintendere").

— amaidment
fonte

1

Leggi la classe String e ArrayList per eccellenti esempi di corretta programmazione Java. Ma sono altamente concisi, quasi in stile C, il che non è necessariamente il migliore per codice gestibile con documenti java minimi. La pratica comune nel mio negozio non prevede commenti, quindi provo a commentare in base al codice usando i nomi verbali camelCase var e l'uso eccessivo di newline per delimitare una linea di pensiero da un'altra. Discuto ancora usando le schede per separare i vari dai loro valori. Le schede possono migliorare la leggibilità, IMO, ma solo se fatto in modo minimale ed è molto soggettivo. Trovo che riguardi davvero il pubblico. Non c'è la migliore risposta qui.

— carlmart
fonte