Apakah ide yang baik untuk memformat kode dalam gerhana menggunakan format otomatis


20

Saya menggunakan eclipse untuk coding, dan bahasa yang kami gunakan adalah Java. Setelah itu disarankan oleh seseorang untuk memformat kode dengan benar, menggunakan pemformat otomatis (CTRL + SHIFT + F) Sementara perintah ini memformat kode, tetapi kadang-kadang saya merasa bahwa keseluruhan tampilan menjadi aneh, dan sebenarnya tidak terlalu mudah dibaca.

Jadi apakah ini hal yang disarankan untuk dilakukan? Jika tidak, apa yang lebih baik dari memformat kode kita di gerhana?


Saya menggunakan kapasitas pemformatan otomatis emacs setiap saat - ada potensi tabrakan (misalnya dengan penggabungan SC) .. tetapi secara keseluruhan, menstandarkan format Anda sangat membantu
warren

Jawaban:


34

Aturan pemformatan kode yang ketat berguna ketika beberapa pengembang bekerja pada kode yang sama menggunakan sistem kontrol versi. Penggabungan dapat menjadi masalah jika pengembang yang berbeda memiliki aturan pemformatan yang berbeda karena kode yang sama akan terlihat berbeda untuk alat penggabungan.

Eclipse (atau IDE yang bagus dalam hal ini) memiliki aturan pemformatan kode yang dapat dikustomisasi di bagian preferensi (Java> Code Style> Formatter). Pilih apa yang paling Anda sukai, tetapi lihat juga konvensi kode standar Java . Banyak proyek open source juga memiliki konvensi kode sendiri yang dapat diberlakukan dengan formatter Eclipse.

Selain itu ada alat standar seperti CodeStyle, PMD dan Findbugs yang menegakkan aturan tambahan dan membantu menghindari anti-pola dan kesalahan umum (tingkat rendah).


4
Setelah Anda mengatur formatter Anda seperti yang Anda inginkan. Ada tombol "Ekspor" yang akan memungkinkan Anda menyimpannya ke file .xml. Kami memasukkan ini ke dalam Gudang SVN kami, sehingga semua orang memiliki akses ke sana ketika mereka memeriksa proyek.
Chris

Saya setuju dengan ini, dan menggunakan PMD dan FindBugs dan semuanya. Tapi ini hanya ide yang bagus jika semua orang di tim mengikuti dan menggunakan aturan pemformatan kode. Kalau tidak, Anda berakhir dengan komit yang merupakan perubahan + pemformatan oleh beberapa devs dan bukan yang lain, dan sulit untuk melihat perubahan "nyata". Dengan kata lain, jika kode lama belum diformat dengan pemformat otomatis, jangan memformatnya dengan perubahan tambahan dalam satu komit.
Mufasa

2
Jika Anda menyesuaikan pengaturan pemformatan kode, masukkan pengaturan itu ke kontrol sumber sehingga semua pengembang mendapatkannya, atau menerbitkannya dalam semacam wiki atau dokumentasi pengembang sehingga semua orang dapat menyetujui gaya tersebut.
Mufasa

24

Saya menemukan autoformatter sangat berguna. Daripada terus-menerus mengambil keputusan mikro tentang bagaimana kode harus diformat - sesuatu yang rawan kesalahan dan menyebabkan "gesekan kognitif" - Anda dapat mengatur aturan pemformatan dan membiarkan Eclipse memformat kode untuk Anda (idealnya secara otomatis menggunakan "Simpan tindakan" ). Tentu saja, ini mengharuskan Anda memiliki basis kode dengan pemformatan yang konsisten, atau Anda memiliki mandat untuk memformat ulang kode sesuai dengan aturan yang Anda siapkan.

Memiliki "autoformat-on-save" diaktifkan sedikit seperti memiliki kompilasi tambahan, ini memungkinkan otak Anda untuk tetap fokus pada kode itu sendiri, daripada khawatir dengan masalah sepele seperti pemformatan kode atau sintaksis.

Tapi ya, terkadang autoformatter akan mengacaukan meja yang diformat dengan baik yang Anda miliki. Dalam kasus seperti itu saya menggunakan "on / off tag". Ini dikonfigurasikan di bawah tab "on / off tag" di profil pemformatan kode. Dengan menggunakannya, Anda dapat mengecualikan kawasan dalam kode Anda agar tidak diformat secara otomatis:

// @formatter:off

... my nicely formatted table here ...

// @formatter:on

5
+1: Saya tidak pernah tahu tentang (atau lebih tepatnya, saya tidak pernah repot-repot mencari tahu) tag on / off.
Paul Cager

1
Autoformat-on-save baik jika semua orang di proyek menggunakannya. Jika hanya beberapa pengembang yang menggunakannya, maka terlalu mudah untuk melakukan perubahan dengan perubahan pemformatan kode pada saat yang sama, yang membuatnya sulit untuk menemukan perubahan "nyata" dalam komit.
Mufasa

@ Mufasa Ya, Anda benar.
JesperE

1
Bila Anda tidak ingin memformat komentar, Anda dapat menulis / * - format super saya * / Eclipse tidak memformat komentar semacam itu :)
Dawid Drozd

5

Apakah itu direkomendasikan atau tidak tergantung pada siapa yang Anda tanya.

Saya bisa membayangkan bahwa Anda lebih suka memformat kode sendiri, setelah semua, Anda tahu apa yang terbaik dan termudah untuk dibaca sendiri. Di sisi positifnya, jika Anda orang yang perhatian, Anda dapat membuatnya lebih mudah dibaca oleh manusia lain juga.

Mesin tidak memiliki pandangan ke depan seperti itu, dan dapat (seperti yang Anda katakan) membuat kode Anda terlihat sedikit berantakan, bahkan jika mereka memformatnya dengan aturan yang ketat.

IDE atau alat yang bagus sering dapat melakukan pekerjaan semi-layak dalam memformat kode untuk Anda, tetapi tidak akan selalu membuatnya terbaca sebanyak yang Anda bisa.

Jadi, saran saya: jangan menggunakannya kecuali Anda menerima kode dari orang lain, dan itu berantakan sehingga Anda tidak bisa membacanya sebaliknya.


5

Anda harus menggunakannya setiap saat untuk memastikan bahwa Anda menggunakan gaya yang konsisten di semua file sumber Anda. Ini juga akan menghemat banyak waktu yang biasanya Anda habiskan untuk mencoba menyesuaikan pemformatan secara manual.

Formatter Java di Eclipse melakukan pekerjaan yang cukup bagus dan sepenuhnya dapat dikustomisasi. Jika Anda tidak setuju dengan pengaturan default (yang saya benar-benar bisa mengerti), maka Anda harus menyesuaikan formatter dengan preferensi gaya pribadi Anda atau apa pun standar yang Anda gunakan. Anda dapat melakukannya di preferensi di bawah Java / Code Style / Formatter.

Pemformat bahkan lebih berguna ketika Anda tidak bekerja sendirian. Sangat mungkin bahwa Anda dan anggota tim Anda akan tidak setuju pada apa yang Anda anggap sebagai gaya kode sempurna â„¢. Dalam hal ini Anda harus menyetujui dasar yang sama dan sekali dan untuk semua menentukan aturan formatter untuk gaya kode khusus ini. Kemudian semua orang bisa menekan format-pintas dan semuanya sesuai dengan gaya yang disepakati. Dengan begitu preferensi pribadi Anda (saat menulis) tidak akan menghalangi. Dan perhatikan bahwa penata formatter dapat disimpan dalam file proyek Eclipse, sehingga pemformat yang berbeda untuk setiap proyek juga dimungkinkan.


0

Meskipun saya suka kode diformat secara otomatis di save (sebenarnya saya mengaktifkannya di proyek pribadi saya). Saya menemukan bahwa saya tidak bisa sepenuhnya merekomendasikan praktik ini dalam tim proyek menggunakan produk berbasis Eclipse karena formatter Eclipse memiliki beberapa bug kritis yang mencegah saya merekomendasikannya.

Khususnya jika Anda memiliki "pembersihan kode" + "formatter" diaktifkan indentasi diperbaiki / tidak tetap pada setiap penyimpanan.

Setiap versi baru Eclipse dapat mengubah formatter (menjadi lebih baik) tetapi akan memperkenalkan perubahan signifikan seperti JavaDocs akhirnya menghapus ruang ekstra setelah *tetapi yang diperkenalkan beberapa saat setelah Helios dan banyak perusahaan menggunakan versi gerhana perangkat lunak yang lebih lama dari eclipse yang menggunakan Helios sebagai basis.

Pemformat kode yang disediakan oleh Eclipse tidak dapat diperpanjang per API mereka, bahkan secara eksplisit menyatakan javadoc CodeFormatter

Kelas ini tidak dimaksudkan untuk subklas oleh klien.

Memang, saya belum menemukan alternatif non-komersial yang layak sampai sekarang. Jalopy belum diperbarui selama bertahun-tahun sekarang dan percabangan di github belum terorganisir untuk membuat saya merekomendasikan salah satu dari mereka. Juga tidak memiliki situs pembaruan untuk Eclipse untuk mengintegrasikannya. Saya sebenarnya berencana untuk membuat pemformatan kode sebagai bagian dari build seperti yang saya lakukan pada cleanpom-maven-plugin menggunakan Jalopy tetapi ide itu jatuh di pinggir jalan karena kurangnya pembaruan untuk Jalopy.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.