È una buona idea formattare il codice in eclipse usando il formato automatico

Uso eclipse per la codifica e il linguaggio che usiamo è Java. Una volta mi è stato suggerito da qualcuno di formattare correttamente il codice, usando il formatter automatico (CTRL + MAIUSC + F) Mentre questo comando formatta il codice, ma a volte sento che l'aspetto generale diventa strano, e in realtà non è molto leggibile.

Quindi è una cosa raccomandata da fare? In caso contrario, qual è la migliore formattazione del nostro codice in eclipse?

Regole di formattazione rigorosa del codice sono utili quando diversi sviluppatori lavorano sullo stesso codice utilizzando un sistema di controllo della versione. La fusione può essere una seccatura se sviluppatori diversi hanno regole di formattazione diverse poiché lo stesso codice apparirebbe diverso per lo strumento di fusione.

Eclipse (o qualsiasi buon IDE per quella materia) ha regole di formattazione del codice che possono essere personalizzate nella sezione delle preferenze (Java> Stile del codice> Formatter). Scegli quello che ti piace di più, ma dai anche un'occhiata alle convenzioni del codice standard Java . Molti progetti open source hanno anche le loro convenzioni di codice che possono essere applicate con il formatter di Eclipse.

Inoltre, esistono strumenti standard come CodeStyle, PMD e Findbugs che applicano regole aggiuntive e aiutano a evitare schemi e errori comuni (di basso livello).

Ho trovato l'autoformatter molto utile. Invece di prendere costantemente microdecisioni su come formattare il codice - qualcosa che è soggetto a errori e causa "attrito cognitivo" - puoi impostare regole di formattazione e lasciare che Eclipse formatta il codice per te (idealmente automaticamente usando "Salva azioni" ). Ovviamente, ciò richiede di disporre di una base di codice con una formattazione coerente o di disporre del mandato di riformattare il codice in base alle regole impostate.

Avere "autoformat-on-save" abilitato è un po 'come avere una compilazione incrementale, permette al tuo cervello di rimanere concentrato sul codice stesso, invece di occuparsi di problemi banali come la formattazione del codice o la sintassi.

Ma sì, a volte l'autoformatter rovinerà qualche tavolo ben formattato che hai. In questi casi utilizzo "tag on / off". Questi sono configurati nella scheda "tag on / off" nel profilo di formattazione del codice. Usandoli, puoi escludere le aree del tuo codice dalla formattazione automatica:

// @formatter:off

... my nicely formatted table here ...

// @formatter:on

Se è raccomandato dipenderà o meno da chi chiedi.

Posso immaginare che preferiresti formattare il codice da solo, dopo tutto, sai cosa è meglio e più facile da leggere da solo. Tra i lati positivi, se sei una persona premurosa puoi renderlo più leggibile anche per altri esseri umani.

Le macchine non hanno questo tipo di lungimiranza e possono (proprio come hai detto tu) far sembrare il tuo codice un po 'un casino, anche se lo formattano secondo regole rigide.

Un buon IDE o strumento può spesso fare un lavoro semi-decente nella formattazione del codice per te, ma non lo renderà sempre il più leggibile possibile.

Quindi, il mio consiglio: non usarlo a meno che tu non riceva codice da qualcun altro, ed è un tale casino che non puoi leggere diversamente.

Dovresti usarlo sempre per assicurarti di usare uno stile coerente in tutti i tuoi file sorgente. Ciò consentirà anche di risparmiare un sacco di tempo che di solito spenderesti cercando di regolare manualmente la formattazione.

Il formattatore Java in Eclipse fa un ottimo lavoro ed è completamente personalizzabile. Se non sei d'accordo con le impostazioni predefinite (che posso capire completamente), allora dovresti adattare il formatter alle tue preferenze di stile personali o qualunque sia lo standard che usi. Puoi farlo nelle preferenze in Java / Code Style / Formatter.

I formattatori sono ancora più utili quando non lavori da solo. È molto probabile che tu e il tuo team non sarete d'accordo su quello che pensate sia lo stile di codice perfetto ™. In tal caso dovresti concordare una base comune e definire una volta per tutte le regole di formattazione per questo particolare stile di codice. Quindi tutti possono semplicemente scegliere la scorciatoia del formato e tutto si adatta allo stile concordato. In questo modo le tue preferenze personali (durante la scrittura) non interferiranno. E nota che lo stile del formattatore può essere memorizzato nei file di progetto di Eclipse, quindi sono possibili anche diversi formattatori per ciascun progetto.

Anche se mi piace avere il codice formattato automaticamente al momento del salvataggio (in effetti l'ho abilitato sui miei progetti personali). Ho scoperto che non potevo raccomandare pienamente questa pratica nei team di progetto che utilizzano prodotti basati su Eclipse poiché il formatter di Eclipse ha alcuni bug critici che mi impediscono di consigliarlo.

In particolare se si dispone di "pulizia del codice" + "formattatore" abilitato, i rientri vengono corretti / non fissati ad ogni salvataggio.

Ogni nuova versione di Eclipse potrebbe cambiare il formattatore (in meglio) ma introdurrebbe cambiamenti significativi come JavaDocs che rimuoveva finalmente quello spazio extra dopo il *ma che è stato introdotto qualche tempo dopo che Helios e molte aziende stanno usando la vecchia versione di eclipse di Rational Software che usa Helios come base.

Il formattatore di codice fornito da Eclipse non è estensibile per la loro API in realtà indica esplicitamente CodeFormatter javadoc

Questa classe non è destinata alla sottoclasse dei client.

Certo, non ho ancora trovato alcuna valida alternativa non commerciale . Jalopy non è stato aggiornato per anni e le forcelle in github non sono ancora organizzate per farmi consigliare nessuno di loro. Né ha alcun sito di aggiornamento per Eclipse per averlo integrato. In realtà stavo pianificando di rendere la formattazione del codice come parte della build, proprio come ho fatto con cleanpom-maven-plugin usando Jalopy ma quell'idea è caduta a causa della mancanza di aggiornamenti per Jalopy.