Conflitto di stili Java all'interno di un team

Esiste una tale organizzazione: Sun / Oracle stessa. Il documento si chiama Convenzioni sui codici per il linguaggio di programmazione Java e descrive la maggior parte delle convenzioni bisogno. Basta che tutti siano d'accordo a leggerlo e seguire i suoi consigli.

Sono veramente taggando alla risposta di Andres , concentrandomi sull'aspetto uniforme della formattazione del codice java.

Se si utilizza Eclipse, è possibile impostare il suo formattatore Java in modo che venga formattato automaticamente nello standard Java. Il formattatore di Eclipse ha anche altre impostazioni utili, come i caratteri per riga (cioè quanti caratteri per riga prima di rompersi in una nuova riga) e molti altri. La standardizzazione dei caratteri per riga semplifica il diff codice scritto da diversi sviluppatori senza avere molte differenze solo dalla spaziatura e dalle interruzioni di riga.

Infine, con Eclipse, dopo aver impostato tutte le impostazioni desiderate, esportare il formattatore come file che può essere importato da ogni membro del team. Pertanto, se utilizzi Eclipse, ti consiglio vivamente di esplorare a fondo tutte le opzioni per la formattazione automatica e la modifica del codice, quindi di condividere le impostazioni con l'intero team.

Suppongo che gli altri principali IDE java (IntelliJ e Netbeans) abbiano una funzione simile per l'esportazione delle impostazioni di formattazione.

This [different styles of coding] is paramount as with such a short deadline we can't afford to spend time trying to comprehend each others code.

In realtà. Non è fondamentale.

Dopo 30 anni come consulente, ho letto un lotto di codice da molti clienti. È importante notare che ogni cliente (e spesso all'interno dell'organizzazione di un cliente) ha stili diversi.

Dopo aver letto così tanti stili, ho imparato questo.

Lo stile non importa

Concentrati sulla scrittura di codice che funziona sempre e scrivi test di unità che dimostrano che funziona sempre.

Dopo che hai spedito il codice funzionante, puoi vestirlo se non hai più bug da correggere e miglioramenti da installare.

Non preoccuparti di scegliere un perfetto standard universale. Tutto ciò di cui hai bisogno è che il tuo team accetti lo uno standard e lo rispetti. Crea il tuo se lo desideri, ma sii coerente.

La coerenza migliora la collaborazione, la collaborazione migliora il codice.

Anche se la consistenza effettiva non aiuta, il fatto che il tuo team abbia lavorato insieme per raggiungere un accordo è una buona cosa. La loro incapacità di accettare qualcosa di semplice come le convenzioni di codifica dice che potrebbero esserci problemi di lavoro più grandi in agguato sotto la superficie.

Il Sun Java CC sopra menzionato non ha solo 13 anni e alcune delle sue regole sono obsolete (come 80 caratteri per riga), ma non definisce anche le convenzioni di denominazione, tranne quelle più generali (involucro di cammello per le classi , lettere maiuscole per variabili finali statiche e simili).

Devi definire i tuoi standard per i diversi tipi di classi, come DAO, EJB, entità, qualsiasi cosa tu usi. Il Sun Java CC è come una classe base astratta pensata per l'estensione:)

Come menzionato da altri qui, puoi cercare online una delle poche "guide di stile" per Java e persuadere tutti i membri del team a rispettarli. Alcuni strumenti di controllo del codice nel tuo IDE preferito potrebbero aiutarti a ricordarti quando non lo fai.

Tuttavia, a volte la politica è coinvolta. Mi trovo una volta in una situazione in cui lo sviluppatore più anziano del team continua a farlo a modo suo anche dopo che qualcuno ha menzionato la necessità di standardizzare. In una situazione del genere, forse è meglio osservare il suo stile di codice e seguirlo dato che probabilmente ha più conoscenza del codice base e dei requisiti e non si può perdere tempo a pestare i piedi, anche se è difficile. Questo è ciò che il resto di noi ha fatto in quella particolare situazione e lo seguo con riluttanza.

Quindi è importante considerare anche la tua situazione.

Lo zio Bob mostra uno stile di codifica più moderno e attuale nel suo libro "Codice pulito". Sfortunatamente non contiene nessun elenco di oggetti. Devi leggerlo. Si dice che per vedere le sue convenzioni, devi leggere il suo codice. Lo zio Bob è senza dubbio una specie di istituzione. Il libro è comunque un'ottima lettura, quindi anche se è troppo tardi per leggerlo ora, leggilo al più presto.

Ciò che conta davvero nel codice è la bassa complessità ciclomatica, la portata ridotta, l'alta coesione e la scelta degli identificatori espressivi. Detto questo, il codice diventa facile da afferrare e tale codice è buono.

Ti suggerisco di esaminare Programmazione spartana .

La maggior parte degli standard di codifica ti dice come far apparire carino il codice scritto male e la maggior parte delle discussioni sullo "stile di codifica" sono in realtà sulla formattazione. La formattazione del codice riguarda la rappresentazione visiva della struttura del codice. È banale e automatizzabile e non ha praticamente nulla a che fare con lo stile di codifica, perché lo stile di codifica non riguarda il modo in cui rappresenti la struttura del codice, ma il modo in cui strutturi il codice.
C'è anche un sacco di guerre religiose sulle convenzioni di denominazione, anche se in realtà sono solo un trucco per aggirare il design scadente. Un nome è buono, se dice cosa significa. Più piccoli e chiari sono i tuoi scopi, più facile è scegliere un nome simile.