Stili Java in conflitto all'interno di una squadra

Faccio parte di un team di sviluppo Java con una scadenza di 6 settimane. Ciò richiede di scrivere molto rapidamente molto codice. Tuttavia, il nostro team di sviluppo ha diversi stili di codifica. Tutto, dalle convenzioni sui nomi ai metodi di astrazione differisce tra il nostro team. Qualcuno sa di alcuni documenti che dettano "standard" per Java?

Per chiarire, mi chiedevo se ci fosse un'organizzazione che avrebbe dettato la giusta convenzione di denominazione per variabili e funzioni, ad esempio. Ciò è fondamentale in quanto con una scadenza così breve che non possiamo permetterci di passare il tempo a cercare di comprendere il reciproco codice.

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

Mi sto davvero concentrando sulla risposta di Andres e mi concentro sull'aspetto formattando uniformemente il codice java.

Se si utilizza Eclipse, è possibile impostare il suo formattatore Java per formattare automaticamente allo standard Java. Il formatter di Eclipse ha anche altre impostazioni utili, come i caratteri per riga (ovvero quanti caratteri per riga prima che si interrompa su una nuova riga) e molti altri. La standardizzazione dei caratteri per riga semplifica la diffusione del 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, quindi esportare il formatter come file che può essere importato da ogni membro del team. Quindi, se stai usando Eclipse, ti consiglio vivamente di esplorare tutte le opzioni che si formatteranno automaticamente e modificheranno il codice per te, quindi condividendo le impostazioni con l'intero team.

Suppongo che gli altri principali IDE Java (IntelliJ e Netbeans) abbiano una funzione simile per esportare le impostazioni del formato.

Questo [diversi stili di codifica] è fondamentale in quanto con una scadenza così breve che non possiamo permetterci di passare il tempo a cercare di comprendere il reciproco codice.

In realtà. Non è fondamentale.

Dopo 30 anni come consulente, ho letto un sacco 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 tanti stili, ho imparato questo.

Lo stile non conta

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

Dopo aver spedito il codice di lavoro, puoi vestirlo se hai esaurito i bug da correggere e i miglioramenti da installare.

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

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

Anche se l'effettiva coerenza non aiuta, il fatto che la tua squadra abbia lavorato insieme per raggiungere un accordo è una buona cosa. La loro incapacità di concordare qualcosa di semplice come le convenzioni di codifica afferma che potrebbero esserci problemi di lavoro di squadra 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 convenzioni di denominazione, tranne quelle più generali (involucro di cammello per classi, capitelli di blocco per variabili finali statiche e simili).

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

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

Tuttavia, a volte è coinvolta la politica. Sono già una volta in una situazione in cui lo sviluppatore più anziano del team continua a fare 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, poiché probabilmente ha la maggior conoscenza della base di codice e dei requisiti e potresti non voler perdere tempo a fare un passo avanti, anche se è difficile. Il che è ciò che il resto di noi ha fatto in quella particolare situazione e io 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 "Clean Code". Purtroppo non contiene alcun elenco di articoli. 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 è bassa complessità ciclomatica, portata ridotta, elevata coesione e scelta di identificatori espressivi. Detto questo, il codice diventa facile da capire e tale codice è buono.

Ti suggerisco di esaminare la programmazione spartana .

La maggior parte degli standard di codifica ti dice come far apparire grazioso il codice scritto male e la maggior parte delle discussioni sullo "stile di codifica" riguarda in realtà la formattazione. La formattazione del codice consiste nel rappresentare visivamente la 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.
Ci sono anche molte guerre di religione 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 ambiti, più facile è scegliere un tale nome.