Apakah menerapkan format kode yang sama untuk semua pengembang adalah ide yang bagus?

Kami sedang mempertimbangkan untuk memaksakan format kode standar tunggal dalam proyek kami (format otomatis dengan tindakan simpan di Eclipse). Alasannya adalah bahwa saat ini ada perbedaan besar dalam format kode yang digunakan oleh beberapa (> 10) pengembang yang membuat lebih sulit bagi satu pengembang untuk bekerja pada kode pengembang lain. File Java yang sama terkadang menggunakan 3 format berbeda.

Jadi saya percaya keuntungannya jelas (keterbacaan => produktivitas) tetapi apakah itu ide yang baik untuk memaksakan ini? Dan jika tidak, mengapa?

PEMBARUAN
Kita semua menggunakan Eclipse dan semua orang mengetahui rencananya. Sudah ada format kode yang digunakan oleh sebagian besar tetapi tidak ditegakkan karena beberapa lebih suka tetap pada format kode mereka sendiri. Karena alasan di atas beberapa orang lebih suka untuk menegakkannya.

Saat ini saya bekerja di tempat di mana format kode standar diberlakukan dan kode secara otomatis diformat saat menyimpan file, sama seperti yang akan Anda lakukan. Sebagai anggota baru perusahaan saya menemukan bahwa aturan format umum memberi saya perasaan hangat dan kabur bahwa "orang-orang ini tahu apa yang mereka lakukan", jadi saya tidak bisa lebih bahagia. ;) Sebagai catatan samping yang terkait, dengan aturan pemformatan umum kami juga menerapkan pengaturan peringatan compiler tertentu yang agak ketat di Eclipse, dengan sebagian besar diatur ke Kesalahan, banyak yang diatur ke Peringatan, dan hampir tidak ada yang diatur ke Abaikan.

Saya akan mengatakan ada dua alasan utama untuk menegakkan format kode tunggal dalam suatu proyek. Pertama-tama berkaitan dengan kontrol versi: dengan semua orang yang memformat kode secara identik, semua perubahan dalam file dijamin bermakna. Tidak hanya menambahkan atau menghapus spasi di sini atau di sana, apalagi memformat ulang seluruh file sebagai "efek samping" dari benar-benar mengubah hanya satu atau dua baris.

Alasan kedua adalah bahwa itu semacam menghilangkan ego programmer dari persamaan. Dengan setiap orang memformat kode mereka dengan cara yang sama, Anda tidak dapat lagi dengan mudah mengatakan siapa yang telah menulis apa. Kode menjadi lebih anonim dan milik umum, jadi tidak ada yang perlu merasa tidak nyaman untuk mengubah kode "orang lain".

Itulah alasan utama, ada alasan lain juga. Saya merasa nyaman bahwa saya tidak perlu repot memikirkan memikirkan pemformatan kode, karena Eclipse akan melakukannya untuk saya secara otomatis ketika saya menyimpan. Ini bebas perawatan, seperti menulis dokumen dengan LaTeX: diformat setelahnya dan Anda tidak perlu khawatir tentang hal itu saat menulis. Saya juga pernah bekerja di proyek-proyek di mana setiap orang memiliki gaya mereka sendiri. Maka Anda harus memikirkan masalah-masalah bodoh dan tidak berarti seperti apakah boleh mengubah kode orang lain dengan gaya Anda sendiri, atau jika Anda harus mencoba meniru gaya mereka.

Satu-satunya argumen terhadap pengaturan pemformatan kode umum yang dapat saya pikirkan untuk kasus Anda adalah bahwa itu tampaknya merupakan proyek yang sedang berlangsung, sehingga akan menyebabkan banyak perubahan yang tidak perlu di semua file, mengacaukan sejarah file yang sebenarnya. Skenario kasus terbaik adalah jika Anda dapat mulai menerapkan pengaturan langsung dari awal proyek.

Setiap pengembang perangkat lunak profesional akan lebih memilih untuk mengadopsi standar (baik) daripada masuk ke perang evangelis atas gaya, karena alasan yang telah Anda uraikan.

Banyak pengembang perangkat lunak melakukan perang evangelis ......

Bergantung pada posisi Anda dalam tim dan dinamika tim, Anda dapat memutuskan bahwa memenangkan perang tidak dimungkinkan. Dalam hal ini, mungkin sebaiknya tidak memulai ...

Ya, itu bagus untuk memiliki satu gaya format kode untuk semua pengembang.

Rancang format gaya kode dan impor itu ke semua pengembang gerhana.

Ini akan membantu ketika kita membuat mergingkode untuk sistem 'Versi control'.

Apa yang ingin Anda peroleh, seberapa besar Anda akan menerapkan anal dalam menegakkannya (dan pada tingkat detail "aturan" Anda akan ditetapkan), apakah Anda akan mencoba untuk menegakkannya pada kode yang ditulis dalam berbagai bahasa, Anda akan mencoba memberlakukannya secara surut pada kode yang ada?

1. tampilan dan nuansa yang umum terhadap kode memang dapat membantu membuat kode lebih mudah dibaca, tetapi juga dapat memperburuk keadaan jika itu adalah tampilan dan nuansa yang salah. Notasi _hUngarian_lpfstr menjadi contoh utama :)
2. Saya telah melihat "standar kode" menegakkan jumlah ruang spasi putih di antara di blok komentar, urutan abjad nama metode, dan omong kosong lainnya. Jangan lakukan itu.
3. Bahasa yang berbeda memiliki standar yang berbeda yang digunakan orang yang berpengalaman dalam menggunakannya. Beberapa bahkan mengamanatkan standar ini (berpikir Python, Cobol, Visual Studio secara otomatis memaksakan konvensi penahan gaya C ++ sementara Java menggunakan gaya C oleh konvensi, dll.).
4. jangan pernah mengubah kode yang ada demi mengubahnya, Anda hanya memperkenalkan masalah baru seperti itu. Dan itu berarti bagian kode serta seluruh file sumber. Jadi jangan pergi memformat ulang kode yang ada ketika seseorang mengubah satu baris dalam file 1000 baris.
5. programmer berpengalaman bisa jauh lebih produktif jika mereka tidak perlu berpikir setengah waktu apakah apa yang mereka tulis akan "terlihat benar" untuk sistem persetujuan otomatis, atau pengulas. Mereka juga akan terbiasa menulis kode bersih hanya karena itulah yang berhasil, bahkan jika ada perbedaan kecil antara gaya alami mereka.

Jadi, meskipun ada alasan bagus untuk memaksakan gaya dan standar tertentu, ada alasan bagus untuk tidak melakukannya (terlalu) secara ketat.

Ya, konsistensi adalah ide yang baik, untuk alasan lain telah disebutkan .

Saya hanya ingin menambahkan beberapa poin yang belum pernah digunakan di tempat lain:

• Oracle telah menerbitkan serangkaian konvensi untuk Java, yang merupakan standar de facto.
  • Menggunakan ini akan membantu Anda menghindari argumen tentang gaya mana yang harus diikuti.
  • Banyak perpustakaan umum dan proyek sumber terbuka cenderung menggunakan konvensi ini, jadi ketika Anda perlu melihatnya, formatnya harus familier.
  • Formatter Eclipse memiliki aturan bawaan untuk mencocokkan konvensi ini, yang juga dapat membantu.
• Anda mungkin ingin mempertimbangkan untuk membangun kait ke pengaturan kontrol sumber Anda sehingga kode diformat secara otomatis sebelum masuk ke cabang utama.
  • Anda dapat menghindari pertempuran dengan programmer yang keras kepala yang menolak untuk mengikuti standar. Mereka bahkan dapat menggunakan format mereka sendiri saat mereka bekerja, yang akan distandarisasi nanti!
  • Jika Anda akhirnya menggunakan pengaturan pemformatan khusus (mis. Banyak orang mengabaikan konvensi "maks 80 karakter per baris"), Anda hanya perlu melakukan perubahan di satu tempat.

Saya berada di tim yang menggunakan plugin Checkstyle . Daripada menggunakan fitur out-of-the-box, kami membentuk sebuah komite kecil pengembang yang tertarik. Kami berdebat tentang apa yang tampaknya hilang, apa yang tampak berlebihan, dan menyelesaikan berbagai hal. Kami semua belajar sesuatu dalam proses itu, dan memperkuat otot-otot pengembang itu.

(Contoh keputusan kami: Lebar 72 karakter terlalu kecil, tetapi 120 lebih baik; lebih baik menggunakan _ALLCAPS untuk final statis; menegakkan keluar tunggal dari suatu fungsi adalah ide yang bagus.)

Ketika kami mendapat ulasan kode, salah satu pertanyaan pertama adalah: "Sudahkah Anda menjalankannya melalui Checkstyle?" Mematuhi standar pengkodean sebagian besar otomatis, dan itu menarik perhatian dari resensi yang pilih-pilih. Sangatlah mudah untuk memiliki Checkstyle menyoroti tanda tangan metode, klik kanan, dan ubah variabel menjadi final. Itu juga bisa memperbaiki lekukan dan kawat gigi sehingga kode semua orang memiliki tampilan dan nuansa yang sama. Kehilangan Javadoc untuk fungsi publik? Checkstyle akan menandai fungsi tersebut.

(Menghapus bau kode lebih penting daripada pemformatan yang konsisten. Ini adalah manfaat alat otomatis.)

Saya akan menempatkan alat otomatis seperti Checkstyle kurang memaksakan format yang sama dan lebih pada mendorong tampilan dan nuansa yang sama. Dan saat Anda menggembalakan kucing, alat otomatis dapat membantu mempertajam keterampilan dan mengurangi bau kode tanpa memar ego yang rapuh.

Jika Anda akan tetap menggunakan IDE yang sama dan menggabungkan beberapa alat format, itu ide yang bagus karena Anda tidak membutuhkan terlalu banyak usaha. Buat aturan tetap sederhana dengan fokus pada keterbacaan dan bukan retensi anal . Itu harus menjadi tongkat pengukur.

Meskipun bola lumpur yang diformulasikan secara konsisten lebih baik dari pada hanya bola lumpur, waktu Anda akan lebih baik dihabiskan untuk membersihkannya daripada menjadi terlalu pilih-pilih tentang arah kurung. Jangan berubah menjadi manajer berkepala pin yang merasa seperti sedang melakukan pekerjaan mereka dengan menghitung ruang indentasi selama tinjauan kode bersama dengan memastikan bahwa lembar-lembar sampul yang baru ada di Laporan TPS .

Preferensi pribadi hanya itu dan jarang meningkatkan produksi: https://stackoverflow.com/questions/249432/whats-the-reasoning-behind-the-different-brace-forms

Jika ya, lupakan dan lakukan sesuatu.

Saya sangat merekomendasikan bahwa manusia menegakkan pemformatan kode, dan bahwa pelanggaran kecil diabaikan atau disentuh. Alasan untuk ini adalah, secara singkat,

1. Mesin melakukan kesalahan pada waktu yang paling buruk, dan biasanya ketika Anda menggunakan fitur bahasa baru. Bagaimana cara menangani penutupan di Jawa, dll? Jalopy memiliki masalah dengan enum dengan fungsi anggota.
2. Saya pikir ini adalah beban yang sangat masuk akal untuk memakai programmer untuk menghasilkan kode untuk perusahaan yang terlihat seperti kode perusahaan. Saya merasa sangat membantu untuk menyebutkan bahwa ini adalah bagaimana kode diformat "di sini," bukan bagaimana semua kode harus diformat di mana-mana. Perusahaan mereka sebelumnya mungkin telah memilih jalur yang berbeda, dan itu tidak masalah. Tidak seperti bahasa sehari-hari, ada idiom khusus untuk budaya kode Anda yang ingin Anda sampaikan.
3. Penegakan sintaksis kode paling baik dilakukan dengan ulasan kode:
   1. Jika pemformatan itu penting, maka itu menarik organisasi Anda untuk melakukan tinjauan kode. Ini sangat bermanfaat.
   2. Jika aturan pemformatan dilanggar, manusia dapat melihatnya dan menilai lebih baik daripada mesin jika tujuannya disampaikan lebih bersih. Ini sangat jarang, tetapi kadang-kadang terjadi.

Mengenai "keterbacaan => produktivitas", struktur kode (seperti kelas dan fungsi tanggung jawab tunggal) akan memberi Anda jauh lebih cepat daripada pemformatan kode. Pemformatan kode bisa membantu, tetapi pikiran yang berbeda menguraikan pernyataan secara berbeda - tidak semua orang akan "lebih produktif." Saya ingin melakukan double-down pada struktur kode di atas pemformatan karena itu adalah sesuatu yang juga akan menarik Anda untuk melakukan tinjauan kode dan membuat tim berpikir tentang bagaimana program bekerja, bukan bagaimana satu loop terlihat.

Saya bukan penggemar berat Domain Driven Design, tetapi ini adalah salah satu model terbaru yang memiliki ide yang SANGAT jelas tentang bagaimana kode harus terstruktur dan konvensi pemformatan kode mengalir secara alami dari program terstruktur Domain Driven Design. Sekali lagi ... Saya tidak suka DDD, tetapi ini adalah contoh yang bagus karena sangat terdefinisi dengan baik.

Saya kira tema dari jawaban ini adalah, Lakukan review kode dan biarkan aliran format dari budaya dan keluar dari proses review.

Secara umum, dengan asumsi Anda mempekerjakan pengembang yang masuk akal, itu adalah ide yang buruk untuk memaksakan format kode universal. Namun itu adalah ide yang baik untuk mengadopsi pedoman kode .

Saya belum pernah melihat seperangkat aturan pemformatan kode yang mengoptimalkan keterbacaan dalam semua kasus. Demikian juga tidak ada 100% aturan tata bahasa yang berlaku dalam bahasa Inggris: otak kita tidak terhubung dengan kabel seperti itu. Jadi gunakan pedoman, tetapi beri pengembang kebebasan untuk menimpanya sesuai keinginan mereka.

Yang sedang berkata, aturan yang lebih sulit dari "mengikuti konvensi kode yang sudah ada dalam file / proyek" adalah yang bagus.

Namun perlu diingat bahwa pemformatan berkontribusi jauh lebih sedikit terhadap keterbacaan daripada sekadar bagaimana kode diatur secara logis. Saya telah melihat banyak kode spaghetti yang tidak dapat dibaca dengan format sempurna!

Saya tidak berpikir ada jawaban sederhana untuk ini. Itu bukan pertanyaan ya atau tidak. Meskipun saya percaya bahwa gaya dan konvensi penamaan penting sampai batas tertentu, juga cukup mudah untuk membuang waktu untuk memikirkannya. Jawaban terbaik adalah dengan memberi contoh.

Pada satu proyek khusus saya, tidak ada konvensi sama sekali. Setiap pengembang melakukan sesuatu dengan caranya sendiri. Karena kurangnya pengalaman tim ini, pergi dari satu kelas ke kelas berikutnya benar-benar menggelegar. Gaya itu kurang dari masalah daripada masalah konvensi penamaan. Satu pengembang akan mereferensikan elemen UI dengan notasi Hungaria yang mengerikan (praktik konyol di zaman IDE modern), satu akan menamai anggota pribadi dengan satu cara, yang lain akan menamai mereka secara berbeda. Anda tidak pernah tahu apa yang Anda lihat.

Sebaliknya, satu tim menggunakan StyleCop (ini adalah proyek .Net) sebagai bagian dari proses pembangunan mereka. Yang lebih buruk, adalah bahwa mereka juga menggunakan sebagian besar aturan default. Jadi Anda akan melakukan sesuatu yang benar-benar normal dalam hal penspasian garis atau penempatan braket keriting, dan build akan muntah karenanya. Begitu banyak waktu yang terbuang hanya dengan menambah spasi dan garis pada barang, dan semua orang, termasuk dudes yang bersikeras menggunakan StyleCop, akhirnya melakukannya hampir setiap komit. Itu buang-buang waktu dan uang.

Jadi yang saya maksudkan di sini adalah menjadi tidak fleksibel bukanlah jawabannya, tetapi berada di Wild West juga tidak. Jawaban sebenarnya adalah menemukan tempat yang paling masuk akal, yang menurut saya adalah tidak memiliki alat otomatis memeriksa barang-barang, tetapi juga tidak membuang konvensi ke angin.

Argumen utama saya terhadap gaya pengkodean yang umum adalah bahwa seorang programmer yang berpengalaman digunakan untuk membaca gayanya sendiri. Anda dapat melatih tangan untuk menulis gaya tertentu tetapi hampir tidak mungkin untuk melatih mata untuk memahami gaya yang Anda benci. Seorang programmer menulis beberapa kode sekali dan kemudian membacanya berulang kali selama pengembangan dan debugging. Jika setiap kali dia membaca kode sendiri, dia berjuang untuk memahaminya karena dia dipaksa untuk menulisnya dengan gaya BAD, dia akan sangat tidak bahagia dan kurang produktif. Ini dari pengalaman saya.

Saya tidak terlalu terbiasa dengan Eclipse tetapi format otomatis pada save terdengar seperti ide yang mengerikan. Pengembang harus memiliki kontrol penuh atas kode-nya terlepas dari apakah gaya pengkodean diberlakukan atau tidak. Operasi 'save' tidak boleh mengubah satu karakter tanpa persetujuan eksplisit dari pengguna.

Jika perusahaan Anda menjual kode sumber maka gaya pengkodean lebih penting tetapi jika Anda menjual kode yang dikompilasi maka itu jauh kurang relevan.

Berharap bahwa gaya pengkodean akan membuat pembuat kode asli kurang dapat dibedakan dan mencegah perang ego adalah omong kosong dalam kasus terbaik dan jelas bodoh dalam kasus terburuk. Pemrogram yang hebat akan selalu menghasilkan kode elegan terlepas dari gaya.

Saya juga sangat pro memberikan setiap pengembang kepemilikan unit kode tertentu dan melarang semua orang menyentuh setiap bagian kode secara bebas. Mengembangkan seluruh unit dalam kode dan bertanggung jawab atas hal itu memungkinkan pengembang menumbuhkan kebanggaan pada pekerjaannya dan mencegahnya mengembangkan kode jelek mengetahui bahwa bug akan kembali untuk memburunya.

Akhirnya, siapa pun yang pro gaya pengkodean selalu menganggap bahwa gaya pengkodeannya sendiri akan dipilih dan semua orang akan mengikuti. Bayangkan bahwa gaya pengkodean yang paling tidak Anda sukai dari semua co-developer Anda dipilih sebagai standar. Apakah Anda masih mendukung penerapan gaya pengkodean?

Satu format untuk mengatur semuanya ... apakah ini benar-benar optimal?

Ini seperti mengendarai mobil orang lain ...

Tentu Anda dapat masuk dan mengendarai mobil apa pun, tetapi Anda akan lebih aman, lebih nyaman, dan lebih kecil kemungkinannya untuk menabrak jika Anda meluangkan waktu untuk menyesuaikan kursi, setir dan cermin sesuai keinginan ANDA .

Dengan kode, pemformatan memengaruhi kenyamanan Anda dalam membaca dan memahami kode. Jika terlalu jauh dari apa yang Anda terbiasa maka akan membutuhkan lebih banyak upaya mental. Apakah perlu untuk menimbulkan ini pada pengembang?

+1 untuk semua manfaat yang disebutkan sejauh ini, tetapi ...

Penegakan otomatis datang dengan biaya yang perlu dipertimbangkan:

-1 pada kenyataan bahwa pemformat kode tidak memahami estetika pemformatan kode. Berapa kali Anda memiliki pemformat kode menghancurkan blok komentar yang disejajarkan dengan baik dalam bentuk tabel? Berapa kali Anda dengan sengaja menyelaraskan ekspresi kompleks dengan cara tertentu untuk meningkatkan keterbacaan, hanya dengan memformatnya secara otomatis, mengubahnya menjadi sesuatu yang "mengikuti aturan", tetapi jauh lebih mudah dibaca?

Kadang-kadang ada solusi untuk hal-hal ini, tetapi pengembang memiliki hal-hal yang lebih penting untuk dipikirkan daripada bagaimana menjaga formatter otomatis dari mengacaukan kode.

Memiliki aturan pemformatan, tetapi memungkinkan beberapa kebebasan untuk menerapkan akal sehat.

Pengembang yang baik adalah orang-orang kreatif, memberi mereka beberapa lisensi artistik. "Keep it simple" harus menjadi mantra pemrogram. Saya punya dua aturan:

Aturan 1: Berikan variabel / kursor / objek / prosedur / apa pun NAMA YANG DAPAT DITERIMA. Nama yang tidak ambigu yang membawa arti dan pemahaman pada kode Anda.

Aturan 2: Gunakan lekukan untuk menunjukkan struktur kode Anda.

Itu dia.

Bagi saya, keuntungan utama dari format umum yang diterapkan secara otomatis adalah membantu pelacakan perubahan & ulasan kode kami. git (dan sebagian besar alat kontrol sumber lainnya) dapat menunjukkan perbedaan dari versi file-file sebelumnya. Dengan menerapkan gaya umum, ini meminimalkan perbedaan preferensi programmer.

Panduan gaya juga memungkinkan parsing kode program lebih mudah untuk berbagai keperluan analitis.

Google telah menerbitkan sebuah makalah tentang ini yang disebut "Mencari Utang Bangun: Pengalaman Mengelola Utang Teknis di Google" .

Bahasa bukan kode. Kami manusia memiliki lebih dari 6000 bahasa, jadi kami menerjemahkannya. Jadi, jika Anda ingin "kode" Anda berkomunikasi, Anda harus melakukan penyesuaian. Anda lihat kami pengguna harus mengubah format data kami sehingga kami tidak akan kehilangan data kami.

Saya akan mengatakan tidak. Struktur / format kode umum di antara tim jelas merupakan hal yang baik, tetapi secara otomatis menegakkannya bukan. Ini harus dilakukan oleh manusia, bukan oleh komputer.

Masalah terbesar saya dengan konsep tersebut adalah

1. Jika saya menulis kode dalam satu format dan secara otomatis diformat ulang, insentif apa yang ada untuk benar-benar mempelajari format itu?
2. Mengikuti poin sebelumnya, jika Anda tidak mempelajari formatnya, seluruh titik autoformatting (untuk membuat kode lebih mudah dibaca dan dimodifikasi) benar-benar hilang. Anda masih harus meluangkan waktu untuk mengetahui format saat Anda membaca kode karena Anda belum mempelajari format itu
3. Saya pikir itu akan menjadi pengalaman yang menggelikan sebagai dev untuk menulis kelas suatu hari, menutupnya, dan kembali pada hari berikutnya untuk melihat itu benar-benar berbeda. Itu berarti bahwa tidak hanya orang lain yang harus mempelajari kode Anda , Anda harus mempelajari kode Anda.
4. Itu juga bisa mendorong pengkodean malas. Alih-alih mendorong dev untuk mempelajari format, mereka dapat menulis dalam format apa pun di bawah matahari dan itu akan secara otomatis terlihat seperti yang diinginkan semua orang. Ini kembali ke # 2 di mana Anda tidak mempelajari gaya dan masih tidak dapat membacanya dengan benar.

Sekarang, saya mungkin cenderung mengatakan bahwa menjalankan format-otomatis pada proyek yang sudah selesai akan menjadi ide yang baik. Ini akan memulai setiap dev dengan kaki yang sama untuk proyek ketika Anda pergi untuk memperbaiki / menambah fitur nanti. Namun, selama pengembangan aktif, saya pikir itu adalah pilihan yang sangat buruk.

Pada dasarnya: Taruh tanggung jawab pada karyawan untuk mempelajari gaya perusahaan, jangan memaksakan kode mereka menjadi sesuatu yang bukan.