Seberapa penting pedoman pemformatan kode? [Tutup]


18

Standar pengkodean adalah umum di setiap organisasi pengembangan perangkat lunak, tetapi seberapa penting mereka harus diikuti? Saya dapat memahami perlunya konsistensi, tetapi ketika berhadapan dengan hal-hal sederhana seperti posisi kawat gigi, panjang garis, dll., Saya tidak yakin standar yang terlalu ketat berkontribusi banyak terhadap pengembangan perangkat lunak.

Bukankah lebih penting bahwa kode Anda dapat dibaca, bukan karena sesuai dengan standar yang telah ditentukan? Sepertinya mereka lebih seperti ... pedoman.

Jawaban:


12

Meminta setiap orang untuk 100% mematuhi pedoman pemformatan kode standar yang sama seperti meminta semua orang untuk berkolaborasi secara terpisah dalam menulis makalah 100 halaman dengan gaya penulisan yang sama.

Semoga semua orang akan menulis makalah dalam bahasa Inggris (atau bahasa yang sama), tetapi gaya yang berbeda akan terlihat jelas. Beberapa akan menulisnya dengan baik, yang lain tidak. Beberapa akan menggunakan kontraksi, beberapa akan mengeja kata-kata sepenuhnya (contoh: itu memang benar). Dll

Saya pikir Anda menyentuh pada poin paling penting:

  1. Itu pedoman
  2. Keterbacaan

Jika Anda ingin kode mematuhi format yang sama, seperti kertas dengan gaya penulisan yang sama, kode tersebut perlu diedit dan direvisi. Kode perlu dibersihkan, ditinjau, diperhitungkan ulang, dll.

Saya tidak pernah berada di toko tempat saya benar-benar senang dengan gaya pengkodean atau pemformatan pengembang lain (minimal karena tidak persis seperti milik saya). Tetapi saya akan puas jika saya bisa membaca / memahaminya dan jika itu konsisten. Yang lainnya adalah gula pada gula sintaksis.

Jadi untuk menjawab pertanyaan Anda: agak penting, tetapi tentu bukan akhir dunia jika tidak.


3
Terutama # 2: Keterbacaan. Terkadang sedikit kode tertentu dapat dibuat lebih mudah dibaca dengan menyimpang dari pedoman.
Bart van Heukelom

Berkat IDE hari ini, Anda bisa mendekati 100% jika Anda memformat ulang kode berdasarkan templat dengan setiap operasi penyimpanan. Eclipse melakukannya dengan sangat baik.
Markus

1
@ Markus ini berfungsi sampai seseorang ingin menggunakan IDE atau editor lain. Saya lebih suka melakukannya di pra-komitmen untuk memberikan lebih banyak kebebasan kepada para pengembang.
Gustav Karlsson

Fair point @GustavKarlsson, dengan cara ini Anda memusatkan pemformatan dan membuat satu titik perubahan jika "standar" berubah. Sebagai solusi (dengan lebih banyak upaya terlibat) Anda selalu bisa menulis templat tambahan untuk IDE baru.
Markus

5

Untuk memformat standar, saya mengikuti apa yang dilakukan orang lain. Jika mereka menggunakan PascalCase untuk semuanya, maka saya menggunakan PascalCase. Jika mereka menggunakan _camelCase, maka saya menggunakan _camelCase. Mengapa? Karena membatasi jumlah pemformatan ulang yang saya lakukan, dan membatasi apa yang harus dilakukan orang lain untuk membuatnya "terlihat baik". Memformat standar biasanya ada untuk memudahkan semua orang.


5

Di pekerjaan saya saat ini, salah satu tugas pertama saya adalah membuat standar pengkodean untuk grup pengembangan kami.

Upaya pertama saya adalah sekitar enam puluh halaman (itu menggabungkan banyak Kerangka Pedoman dari Microsoft). Saya diminta untuk memotongnya, dan upaya saya berikutnya adalah sepuluh halaman, menggunakan ide-ide dari berbagai sumber yang baik. Saya diminta untuk memotongnya lagi, dan akhirnya turun menjadi tiga atau empat halaman, saya pikir.

Itu tidak pernah diadopsi.

Mengapa? Karena saya bekerja dengan banyak orang yang benar-benar pintar, yang sudah mengikuti standar pengkodean yang masuk akal secara naluriah.

Untuk bagian saya, saya mengikuti pedoman yang diterima secara umum dari Microsoft, dan meniru gaya yang biasa digunakan orang lain (Javascript dan jQuery diformat secara berbeda dari C #, meskipun keduanya bahasa penjepit keriting). Saya juga melanggar aturan dari waktu ke waktu, ketika melakukannya akan membuat kode lebih mudah dibaca.


Mengapa Anda menulis standar pengkodean Anda sendiri ketika ada begitu banyak di luar sana, dan sebenarnya standar untuk bahasa / kerangka kerja yang digunakan?
Florian Margaine

2
Itu tidak pernah diadopsi - tadaa, dan ada pernyataan yang saya cari saat menelusuri jawaban. Itulah intinya: semakin banyak orang dan semakin tinggi kompleksitas dan kesewenang-wenangan aturan, semakin kecil kemungkinan mereka akan diadopsi oleh bahkan sebagian besar tim. Kecuali itu tidak diberlakukan entah bagaimana, seperti Visual Studio atau bahasa Go lakukan, pengembang cenderung mengikuti pikiran mereka sendiri. Saya menunggu hampir 10 tahun sekarang untuk IDE yang memisahkan konten kode dari styling kode.
JensG

2

Jika Anda menggunakan dan IDE yang melakukan dasar-dasar ini untuk Anda (Visual Studio misalnya), biarkan IDE melakukan hal itu dan apa pun yang tampaknya masih sulit dilihat Anda modifikasi selama Anda masih membiarkan IDE melakukan hal itu atau orang berikutnya yang memformat otomatisnya akan membunuhnya.

Apa yang paling mudah dibaca oleh satu orang tidak akan berlaku untuk semua orang.

Jika Anda tidak menggunakan IDE jenis ini, dapatkan satu. Bahkan memikirkan hal ini selama lebih dari 10 menit adalah pemborosan sumber daya IMHO.


4
Saya harus tidak setuju. Saya menemukan tidak ada yang lebih menjengkelkan daripada IDE yang mengubah format sendiri. Mengapa saya harus membiarkannya memodifikasi kode saya tanpa persetujuan saya? Itu memotong sebagian dari kontrol yang saya suka miliki atas pekerjaan saya.
derekerdmann

Bill, apakah Anda berbicara tentang konvensi penamaan drag-n-drop yang dihasilkan oleh IDE seperti TextBox01? Atau maksud Anda plugin Visual Studio seperti Resharper?
spong

derek - ya, itu menyebalkan, tapi waktu itu menyelamatkan saya dari tidak harus memperhatikannya 90% dari waktu bernilai 10% dari waktu saya harus bergulat.
Bill

sun - maksud saya memformat hanya dalam kasus ini. Saya akan baik-baik saja dengan nama kontrol default pada drop hanya jika sangat jelas apa yang sedang terjadi. dalam banyak bentuk yang berantakan setelah kontrol kedua. Saya bukan penggemar berat, tetapi ketika saya menggunakannya saya tidak mencoba dan memperbaiki apa yang menghasilkan banyak. Jangan melawan perangkat Anda saat Anda tidak harus melakukannya.
Bill

Mungkin ada beberapa IDE dalam tim yang sama - Misalnya Eclipse dan IDEA untuk Java. Diperlukan sedikit usaha untuk menyiapkan pemformatan kode dalam bentuk file konfigurasi - tetapi itu sepadan.
talonx

1

Saya pikir ada manfaat yang tidak disebutkan dalam membantu memahami kode dengan cepat. Semakin mirip pemformatan kode di seluruh proyek dan semua pengembang, semakin mudah (dan semakin tidak disadari) Anda akan dapat bekerja dengan kode tersebut.

Saya meminta pengembang junior datang kepada saya setelah mencoba menangani bug yang bahkan sederhana untuk jangka waktu yang lama. Setelah mengambil beberapa menit untuk menerapkan format kode kami dengan mereka, mereka dengan cepat dapat melihat bug yang mereka lewatkan sebelumnya.

Sementara keterbacaan jelas penting. Jika standar format kode Anda dipikirkan dengan baik, dan digunakan dengan benar, Anda mungkin menemukan bahwa Anda dapat melampaui hanya dengan dapat membaca kode, dan untuk dapat memahami kode lebih cepat lagi.

Satu set pedoman yang saya gunakan ketika mengembangkan atau memperbarui format pengkodean kami adalah Prinsip Pengelompokan Gestalt - http://en.wikipedia.org/wiki/Gestalt_psychology#Gestalt_laws_of_grouping

Sebagai akibat / contoh langsung pemformatan kode kami mengharuskan kode blok apa pun (jika, aktifkan, dll.) Memiliki kurung buka di baris berikutnya, sehingga sejajar dengan kurung penutup:

if(true)
{
}

Dengan alasan bahwa dengan Prinsip Simetri, pikiran Anda akan melihat kurung buka dan tutup dan lebih cepat dapat merasakan blok kode secara alami.


After taking a few minutes to apply our code format with them, they were quickly able to see the bug that they had missed before.Ini bukan karena format kode Anda membantu mereka melihat bug. Itu karena tugas memformat ulang kode memaksa mereka untuk melihat dengan hati-hati pada kode yang mereka skimming sebelumnya.
Brandin

1

Tidak peduli bahasa atau alat apa yang Anda gunakan, buat sesuatu. Konfigurasikan IDE Anda dan periksa di file konfigurasi.

Ketika ada yang memeriksa proyek, mereka akan menggunakan gaya format yang sama. Tidak masalah apa gayanya, hanya saja konsisten. Saya memiliki preferensi sendiri sehubungan dengan spasi v. Tab, dan garis mana kurung kurawal berjalan. Tetapi lebih dari preferensi saya sendiri, saya hanya peduli bahwa file kode sumber yang diberikan setuju dengan dirinya sendiri. Itu membuatnya jauh lebih mudah dibaca daripada menjadi mishmash yang dihasilkan dari perang format.


0

Hal terburuk yang saya temui sejauh ini adalah tidak menggunakan standar pengkodean. Dan Anda dilarang membuat beberapa blok kode lebih mudah dibaca karena merusak alat yang berbeda ... Karena kami menggunakan tambalan untuk menerapkan perubahan (permintaan perubahan / perbaikan bug -> perbaikan / ubah -> tambalan -> tambalan yang diterapkan oleh orang "tepercaya" -> commit) Anda bisa mendapatkan kode sumber yang tampak sangat lucu (dari sudut pandang keterbacaan). Setidaknya kami tidak memiliki siapa pun yang menggunakan dua variabel huruf (-.

[Kata-kata kasar] Yang paling lucu adalah semua orang setuju bahwa kita perlu mengubahnya. Bahkan ada beberapa upaya memformat ulang (otomatis pada komit), tetapi karena satu opsi pemformatan bitsy kecil mereka hilang - semuanya baru saja melewati. Sight ... [/ kata-kata kasar]


0

Pedoman membantu meningkatkan kualitas kode:

  • dari sudut pandang penulis: banyak aturan bertujuan mengurangi pengenalan bug. Misalnya, aturan yang menyatakan bahwa if()atau for(;;)konstruksi harus diikuti oleh sebuah blok dan bukan instruksi tunggal, membuat maksud dari pembuat kode awal eksplisit dan membantu pembuat kode berikutnya mempertahankannya.

  • dari sudut pandang pembaca: kode yang mengikuti pedoman yang disepakati ditinjau lebih efisien daripada kode dengan berbagai gaya. Peninjau tahu lebih baik dengan sedikit usaha di mana mencari bug yang mungkin.


0

Tidak ada standar universal untuk apa yang harus atau tidak seharusnya dilakukan oleh suatu tim. Beberapa tim perlu mengikuti panduan ketat, beberapa tidak.

Intinya, Anda harus bekerja bersama sebagai sebuah tim dan memutuskan apa yang terbaik untuk tim Anda . Kode harus mudah dibaca, karena itu dibaca urutan besarnya lebih dari yang tertulis. Jika tim Anda membutuhkan panduan untuk membuat kode yang dapat dibaca, patuhi standar pengkodean. Jika tidak, jangan.

Semua yang dikatakan, saya pikir sebagian besar tim akan mendapat manfaat dari menyepakati cara standar untuk menyebutkan variabel, fungsi dan kelas, kurung posisi, dan sebagainya. Jika tim tidak dapat menyetujui sesuatu yang sesederhana itu, bagaimana mereka dapat berharap untuk berkumpul dan membuat keputusan yang sangat penting? Plus, tim Anda tidak akan terdiri dari orang yang sama selamanya - orang pergi, orang baru dipekerjakan. Semakin mudah bagi orang baru untuk mendapatkan basis kode, semakin cepat mereka dapat berkontribusi pada tim tanpa menurunkan kualitas kode.

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.