Mengapa Paman Bob menyarankan agar standar pengkodean tidak dituliskan jika Anda dapat menghindarinya?


145

Ketika saya membaca pertanyaan ini , jawaban yang paling banyak dikutip mengutip Paman Bob tentang standar pengkodean , tetapi saya bingung dengan tip ini:

  1. Jangan menuliskannya jika Anda bisa menghindarinya. Alih-alih, biarkan kode menjadi cara standar ditangkap.

Ini memantul di otak saya, tetapi saya tidak dapat menemukan tempat untuk menempel. Jika orang baru bergabung dengan tim, atau mengubah standar pengkodean, tidak bisakah ada kebingungan informasi?

Mengapa saya tidak menulis standar pengkodean?


47
Hmm. Saya mencoba membayangkan bagaimana ini akan bekerja di perusahaan multinasional besar dengan ratusan pengembang dan basis kode yang mencakup beberapa dekade.
Matthew James Briggs

31
@MatthewJamesBriggs: ini berfungsi paling tidak sebagus standar yang ditulis sebagian besar devs abaikan, atau yang memiliki konten berbeda pada saat kode tersebut ditulis pada awalnya.
Doc Brown

7
@MatthewJamesBriggs: setuju. Panduan gaya harus berisi informasi yang cukup untuk mengenali konvensi sebelumnya yang sekarang sudah usang, jika tidak budaya "salin gaya yang ada" akan menemukan kengerian 10 tahun untuk dibangkitkan. Juga, ketika klik-klik terbentuk secara tidak sengaja yang menggunakan spesimen yang berbeda dan tidak kompatibel untuk menyimpulkan gaya resmi, panduan gaya tertulis mengatakan yang mana di antara mereka yang benar (atau idealnya, mencegah pembentukan klik di tempat pertama). Dan jika beberapa dari ratusan devs Anda tidak membaca dokumen, di perusahaan besar Anda hanya bisa memecat mereka untuk muppetry kotor.
Steve Jessop

14
Meskipun untuk bersikap adil, Bob juga mengatakan Anda tidak seharusnya memiliki standar pengkodean seluruh perusahaan, tertulis atau tidak tertulis. Sebaliknya, setiap tim / klik harus mengembangkan sendiri.
Steve Jessop

37
Alih-alih menulis dokumen yang tidak akan dibaca siapa pun, gunakan linter yang memberlakukan kode dengan cara tertentu. Jika itu bagian dari proses pengembangan Anda, itu tidak dapat dihindari.
Seiyria

Jawaban:


256

Ada beberapa alasan.

  1. Tidak ada yang membaca dokumentasi.
  2. Tidak ada yang mengikuti dokumentasi bahkan jika mereka membacanya.
  3. Tidak ada yang memperbarui dokumentasi bahkan jika mereka membacanya dan mengikutinya.
  4. Menulis daftar praktik jauh lebih efektif daripada menciptakan budaya.

Standar pengkodean bukan tentang apa yang harus dilakukan orang, tetapi tentang apa yang sebenarnya mereka lakukan. Ketika orang menyimpang dari standar, ini harus diambil dan diubah melalui proses peninjauan kode dan / atau alat otomatis.

Ingat, inti dari standar pengkodean adalah untuk membuat hidup kita lebih mudah. Mereka adalah jalan pintas untuk otak kita sehingga kita dapat menyaring hal-hal yang diperlukan dari hal-hal penting. Jauh lebih baik untuk menciptakan budaya peninjauan untuk menegakkan ini daripada memformalkannya dalam sebuah dokumen.


11
Dan jika Anda ingin menegakkan sesuatu, Anda harus memiliki langkah proses pembangunan yang menegakkannya, bukan panduan gaya yang melakukannya.
Wayne Werner

31
Apakah Anda benar-benar tidak memiliki dokumen standar, tetapi hanya berteriak pada orang-orang selama beberapa minggu pertama di setiap ulasan kode? Sepertinya pada dasarnya Anda mengharapkan pemula untuk merekayasa balik panduan gaya pengkodean Anda. Atau ini lebih hipotetis "Saya pikir itu yang dia maksudkan"? Sekarang jika ini tentang alat otomatis yang menegakkan aturan itu - disepakati, itu penting. Tetapi saya tidak ingin harus dengan susah payah mencari tahu aturannya.
Voo

13
@ Oh, mengapa Anda merasa perlu berteriak selama tinjauan kode jika ada masalah?
Jaap

20
@ Jaap saya pikir hiperbola itu jelas .. ternyata tidak. Tidak tidak meneriaki orang, tetapi mengatakan kepada mereka bahwa mereka harus kembali dan memperbaiki semua hal yang mereka langgar karena mereka tidak bisa lebih tahu.
Voo

5
@ Voo: Anda tidak perlu "membalikkan panduan gaya pengkodean insinyur". Konvensi harus jelas ketika melihat kode yang ada. Segala sesuatu yang tidak langsung melompat ke mata adalah baik, tidak umum atau bahkan tidak diperbaiki. Jika ada aturan yang sangat penting tentang sesuatu yang jarang terjadi, mungkin ada baiknya membahasnya dengan pengembang baru, ketika mereka yang harus menulis kode seperti itu. Komunikasi tidak bisa diremehkan.
Holger

112

Ada interpretasi lain. Saya tidak percaya itu yang dimaksud Paman Bob, tetapi patut dipertimbangkan.

Jangan menangkap standar pengkodean dalam dokumen. Tangkap dalam kode, dengan memiliki proses otomatis yang memverifikasi standar terpenuhi .

Jangan mengandalkan orang yang mereferensikan dokumen, tetapi pada saat yang sama, jangan bergantung pada orang yang menafsirkan kode yang sudah ada dan mengidentifikasi konvensi apa dan kebetulan apa.

Masukkan sesuatu seperti Checkstyle ke dalam komit Anda. Ini dapat menegakkan aturan dasar seperti memformat dan menamai standar, dan bukannya mengeluarkan upaya mental dalam mempertimbangkan gaya, yang semuanya bisa diturunkan ke proses bodoh yang setidaknya dijamin menyeluruh.

Jika itu penting, maka tentukan dengan tegas apa yang Anda inginkan, dan gagal jika itu salah.


6
Sebenarnya, saya curiga bahwa hal seperti ini setidaknya merupakan bagian dari alasan Paman Bob untuk saran tersebut. Otomatisasi standar pengkodean berjalan bersama pengujian otomatis sebagai cara yang berguna untuk meningkatkan kualitas, dan saya yakin Bob tahu bahwa ...
Jules

10
Mungkin layak disebut aturan # 6: After the first few iterations, get the team together to decide.Dengan hanya aturan # 3 sepertinya dia menganjurkan tidak ada standar pengkodean, tetapi ketika mempertimbangkan semua aturan bersama-sama, dan yang paling utama semua # 6, sepertinya dia benar-benar berkata: "Jangan memaksakan standar pengkodean pada awalnya. Biarkan berkembang secara organik, dan setelah beberapa saat duduk dengan tim Anda untuk menuntaskan detail. " Yang sangat berbeda dari "Jangan memformalkan standar pengkodean Anda" (yang tampaknya menjadi inti dari banyak jawaban).
Shaz

Jika Anda membaca item yang saya pikir Anda akan menemukan bahwa ini tentu saja bukan apa yang ia maksudkan, misalnya yang satu ini saja harus memberi tahu Anda sesuatu: 2. Biarkan mereka menjadi tim yang spesifik, bukan khusus perusahaan.
Bill K

Perhatikan bahwa saya menjawab pertanyaan "Mengapa saya tidak menulis standar pengkodean" - bukan "Apa maksud Paman Bob". Itu mungkin bertentangan dengan judul pertanyaan, tetapi tidak semangatnya.
Tom Johnson

Perhatikan bahwa sistem format pengkodean otomatis yang tidak menyediakan klausa melarikan diri (tempat saya dapat mematikannya untuk bagian kode) hampir pasti akan menjadi malware di beberapa titik.
Yakk

66

Orang-orang mengabaikan tujuan sebenarnya dari suatu dokumen standar pengkodean, yaitu untuk menyelesaikan perselisihan .

Sebagian besar keputusan dalam standar pengkodean hanya akan memiliki efek yang sangat kecil pada keterbacaan dan produktivitas. Terutama jika Anda mengadopsi gaya 'normal' untuk bahasa tersebut, dan perancang bahasa mulai menyadari bahwa ini harus menjadi bagian dari spesifikasi (misalnya Go).

Karena mereka sangat sepele, argumen dapat menjadi sangat panas dan berjalan tanpa henti, benar-benar merusak produktivitas dan kohesi tim. Atau dapat mengaburkan riwayat perubahan Anda dengan memformat ulang tanpa akhir antara dua atau lebih gaya yang disukai orang.

Memiliki standar tertulis mengakhiri argumen. Manajer dapat mengarahkannya dan membelokkan ketidakpuasan terhadap dokumen. Anda bisa berdebat dengan selembar kertas tetapi itu tidak akan mendengarkan Anda.

(Lihat juga The Tyranny of Structurelessness )


19
Ini sangat penting bagi tim yang berurusan dengan kode lama. Terutama ketika beralih dari kode yang mengikuti satu set standar (atau tidak mengikuti standar apa pun) ke yang lain. Tanpa panduan untuk merujuk, tidak mungkin untuk mengetahui gaya kode mana yang harus diikuti ketika ada beberapa gaya yang sudah ada dalam basis kode. Saya pikir saran untuk tidak menuliskan standar dimaksudkan untuk tim yang sangat kecil mengerjakan proyek greenfield tanpa pergantian risiko - kasus yang sangat langka, dalam pengalaman saya.
thomij

4
Jauh lebih penting untuk menyetujui suatu standar, daripada isi standar yang sebenarnya. Anda bisa terbiasa dengan gaya apa pun jika Anda bekerja cukup lama.
Mark Ransom

3
Berdebat tentang hal-hal sepele adalah tanda ketidakmampuan, IMHO. Menyelesaikan sengketa konkret tidak akan memperbaiki masalah yang mendasarinya.
Jørgen Fogh

1
Ya, penyelesaian sengketa dan menjaga agar sejarah perubahan tidak tercemar sangat besar, terutama ketika Anda memiliki campuran pengembang OCD dan tidak-terlalu-OCD di tim Anda. Namun, saya telah menemukan standar tertulis sebagai arbiter yang jauh kurang efektif daripada alat otomatis seperti StyleCop, yang menetapkan hukum tanpa membuatnya pribadi atau membuang-buang waktu manajer.
Eric Hirst

12
"Berdebat tentang hal-hal sepele adalah pertanda ketidakmampuan" - Saya berharap ini benar dalam rekayasa perangkat lunak ... Saya khawatir beberapa dev, sangat kompeten (setidaknya secara teknis) adalah orang-orang yang paling suka berdebat tentang hal-hal sepele. Sial, ini olahraga nasional mereka. "Tak terbatas adalah argumen para penyihir" -Ursula Le Guin
Spike0xff

21

Karena komentar adalah dusta .

Standar pengkodean adalah komentar besar yang bagus tentang apa yang harus kode. Kode itu sendiri adalah sumber utama kebenaran. Kebenaran dalam hal ini bukan perilaku kode, itu gaya yang diungkapkan. Jika standar Anda belum tercermin dalam kode Anda, Anda memiliki banyak pekerjaan di depan Anda.

Paman Bob melihat komentar sebagai kegagalan pribadi programmer, karena itu membuktikan bahwa ia tidak berhasil mengekspresikan tujuan fragmen kode dengan bahasa pemrograman itu sendiri. Demikian pula, dokumen standar adalah kegagalan untuk mengekspresikan gaya yang koheren dalam basis kode.

Pemrogram baru harus menghabiskan waktu melihat kode, tidak menghabiskan berhari-hari membaca dokumen standar multi-bab (saya harus melakukan ini, huh).

Sebuah dokumen standar bukanlah ide yang buruk, tapi saya pernah berada di toko pemrograman tempat mempertahankan dokumen standar adalah pekerjaan penuh waktu seseorang. Tolong, jika Anda harus menyimpan dokumen standar, simpan ke halaman. Tetapi jika Anda sudah memiliki kode, tidak adakah yang bisa mengumpulkan dokumen yang sama dalam waktu kurang dari sehari?

Memiliki standar kode adalah penting. Memiliki dokumen yang menentukan apa yang bukan.


22
Saya benar-benar mengalami basis kode multi-dekade dengan kebijakan "tidak ada komentar"; sementara itu memang mendorong nama metode deskriptif yang sangat panjang, itu benar-benar mengerikan dalam menangkap maksud, alasan untuk tidak melakukan sesuatu, dan kami hanya lolos begitu saja dengan memiliki salah satu penulis asli masih bersama kami.
pjc50

7
+1 "Memiliki standar kode adalah penting. Memiliki dokumen yang menentukan apa yang bukan standarnya." Baik dan ringkas.
David

4
@ pjc50 Saya belum pernah mendengar Paman Bob menganjurkan kebijakan tanpa komentar. Dia tidak mengajarkan bahwa Anda tidak boleh berkomentar. Dia mengajarkan bahwa Anda harus merasa tidak enak ketika Anda merasa harus melakukannya agar dapat dipahami. Tidak terbaca tidak terbaca <dikomentari tidak terbaca <kode yang dapat dibaca yang tidak memerlukan komentar. Perhatikan bahwa komentar yang Anda sebutkan adalah komentar yang sepenuhnya dipisahkan untuk BAGAIMANA kode berfungsi. Dokumen standar dapat berubah menjadi daftar periksa yang mati otak yang dicentang dalam tinjauan kode. Yang penting bukanlah Anda mendapatkan semua kutu Anda. Ini karena orang-orang di meja memahami kode Anda.
candied_orange

3
"Pemrogram baru harus menghabiskan waktu melihat kode, bukan menghabiskan berhari-hari membaca dokumen standar multi-bab". Tidak tahu panduan pengodean apa yang Anda ikuti, tetapi panduan gaya C ++ Google dapat dengan mudah dibaca dalam waktu kurang dari satu jam dan jauh lebih mudah untuk diketahui daripada harus merekayasa balik gaya yang dipilih berdasarkan kode yang ada (yang terdengar sangat mengerikan bagi saya). Hal yang sama berlaku untuk setiap panduan gaya lain yang pernah saya baca.
Voo

5
@CandiedOrange: Seringkali, komentar yang paling berguna adalah komentar yang menjelaskan alasan hal-hal tertentu tidak dilakukan [karena dengan tidak adanya komentar seperti itu, programmer masa depan mungkin membuang-buang waktu untuk mencoba mengimplementasikan dan kemudian menarik kembali "perbaikan" yang tampaknya jelas-jelas terjadi menjadi tidak bisa dijalankan]. Kecuali ada yang benar-benar gila dengan nama-nama variabel, tidak mungkin kode yang paling mudah dibaca dapat menangkap informasi itu.
supercat

16

Mengapa Paman Bob menyarankan agar standar pengkodean tidak dituliskan jika Anda dapat menghindarinya?

Jika Anda menanyakan alasan di balik pendapatnya, maka Anda mungkin memiliki jawaban hanya jika dia akan mengirim jawaban di sini ( pendapat kami tidak relevan), namun ...

Mengapa saya tidak menulis Standar Pengkodean?

Jika Anda bertanya apakah dia benar tentang hal itu: biarkan saya menjadi satu-satunya yang tidak populer (sejauh ini) untuk mengatakan bahwa Anda tidak punya alasan untuk menghindarinya.

MENULISKANNYA . Namun saya akan mencoba menjelaskan alasan saya ...

David menyarankan dalam komentar bahwa poin utama dari jawaban Stephen bukanlah mengapa Anda tidak harus menulis dokumen tetapi dalam bentuk apa mereka. Jika pedoman diformalkan dalam alat (bukan hanya tinjauan kode manual) maka saya dapat setuju (ketika hukum tidak mensyaratkan hal lain). Harap perhatikan bahwa sayangnya alat tidak dapat memeriksa semuanya (teori perhitungan bukan teman kami) sering karena mereka terbatas pada unit terjemahan atau paket tertentu atau apa pun bahasa favorit Anda yang disebut batas .

Namun kata-kata Paman Bob tidak membuat saya berpikir dia berbicara tentang itu.

Bisakah saya tidak setuju dengan pakar senior seperti itu? Saya lakukan, untuk hampir setiap poin dalam posting yang dikutip (lihat juga bagian kedua dari jawaban ini untuk perincian). Mari kita coba memahami mengapa (dengan asumsi Anda sudah tahu bahwa pedoman pengkodean bukan hanya tentang masalah format kecil ).

  • Dalam beberapa keadaan, standar pengkodean tertulis diwajibkan oleh hukum.
  • Saya membaca dokumentasi dan saya yakin saya tidak sendirian. Anggota tim dapat berubah seiring waktu, pengetahuan tidak dapat berada dalam basis kode 5-10 tahun atau dalam pikiran anggota tim. Organisasi harus memecat orang yang tidak mengikuti pedoman internal.
  • Standar pengkodean, setelah disetujui , tidak akan sering berubah dan jika mereka ingin Anda mengetahuinya. Jika standar berubah maka dokumentasi Anda (dalam kode) kedaluwarsa karena semua kode Anda tidak mengikuti standar baru. Pemformatan ulang / refactoring mungkin lambat tetapi Anda selalu memiliki pedoman otoritatif tertulis untuk diikuti.
  • Lebih baik membaca dokumen 5 halaman daripada memeriksa 10 / 20K LOC untuk memperkirakan aturan (yang mungkin Anda salah pahami, BTW), tidak diragukan lagi.
  • Sungguh ironis bahwa seseorang yang menulis banyak buku tentang prinsip-prinsip desain dan gaya pengkodean menyarankan agar Anda tidak menulis pedoman Anda sendiri, bukankah lebih baik jika ia mencampakkan kita dengan beberapa contoh kode? Tidak, karena pedoman tertulis tidak hanya memberi tahu Anda apa yang harus dilakukan tetapi juga dua hal lain yang tidak memiliki kode: apa yang tidak boleh dilakukan dan alasan untuk melakukannya atau tidak.

"Free self-organizing programming" baik untuk seorang ninja berusia 16 tahun tetapi organisasi memiliki persyaratan lain :

  • Kualitas kode harus diberikan (dan ditentukan) di tingkat perusahaan - itu bukan sesuatu yang bisa diputuskan oleh satu tim. Mereka bahkan mungkin tidak memiliki keterampilan untuk memutuskan mana yang lebih baik (berapa banyak pengembang, misalnya, memiliki semua keterampilan yang diperlukan untuk meninjau MISRA atau bahkan hanya memahami setiap aturan?)
  • Anggota dapat dipindahkan di tim yang berbeda: jika semua orang mengikuti standar pengkodean yang sama maka integrasi menjadi lancar dan lebih sedikit rawan kesalahan.
  • Jika sebuah tim mengorganisir diri sendiri maka standar akan berkembang seiring waktu ketika anggota tim berubah - Anda kemudian akan memiliki basis kode besar yang tidak mengikuti standar yang berlaku saat ini .

Jika Anda memikirkan orang sebelum proses maka saya hanya bisa menyarankan membaca tentang TPS: manusia adalah bagian utama Lean tetapi prosedurnya sangat formal.

Tentu saja organisasi kecil dengan hanya satu tim dapat membiarkan tim memutuskan standar untuk diadopsi tetapi kemudian harus ditulis. Di sini, di Programmers.SE Anda dapat membaca posting oleh Eric Lippert: Saya kira kita semua setuju dia adalah pengembang yang berpengalaman, ketika dia bekerja untuk Microsoft dia harus mematuhi pedoman tertulis mereka (bahkan jika beberapa aturan mungkin salah , tidak berlaku atau tidak berguna padanya.) Bagaimana dengan Jon Skeet? Pedoman Google sangat ketat (dan banyak orang tidak setuju dengan mereka) tetapi dia harus mematuhi pedoman tersebut. Apakah itu tidak sopan kepada mereka? Tidak, mereka mungkin bekerja untuk mendefinisikan dan meningkatkan pedoman tersebut, sebuah perusahaan tidak dibuat oleh satu anggota (atau satu tim) dan masing-masing tim bukan pulau .

Contohnya

  • Anda memutuskan untuk tidak menggunakan beberapa kelas warisan dan bersarang di C ++ karena Anda anggota tim yang sebenarnya tidak memahaminya dengan baik . Kemudian seseorang yang ingin menggunakan multiple inheritence harus menelusuri seluruh 1M LOC untuk melihat apakah ia pernah digunakan. Itu buruk karena jika keputusan desain tidak didokumentasikan Anda harus mempelajari basis kode keseluruhan untuk memahaminya. Dan bahkan kemudian, jika belum digunakan, apakah itu karena itu melanggar standar pengkodean, atau apakah itu diizinkan, tetapi tidak ada situasi sebelumnya di mana banyak pewarisan cocok?
  • Di C # Anda memiliki metode kelebihan untuk memberikan parameter default karena basis kode Anda dimulai ketika parameter opsional tidak tersedia di C #. Kemudian Anda berubah dan Anda mulai menggunakannya (refactoring kode lama untuk menggunakannya setiap kali Anda harus memodifikasi fungsi tersebut). Bahkan kemudian Anda memutuskan bahwa parameter opsional buruk dan Anda mulai menghindari menggunakannya. Apa aturan kode Anda memberi tahu Anda? Itu buruk karena standar berevolusi tetapi basis kode lebih lambat untuk berkembang dan jika itu dokumentasi Anda maka Anda dalam kesulitan.
  • Jon pindah dari tim A ke tim B. Jon harus belajar standar baru; sambil belajar dia mungkin akan memperkenalkan bug yang lebih halus (atau, jika beruntung, hanya perlu waktu lama untuk memahami kode yang ada dan membuat ulasan kode lebih lama).
  • Tim A pindah ke basis kode yang sebelumnya dimiliki oleh tim B. Ini memiliki standar pengkodean yang sama sekali berbeda. Menulis kembali? Menyesuaikan? Campuran? Semuanya sama-sama buruk.

Paman Bob

Biarkan mereka berkembang selama beberapa iterasi pertama.

Benar, sampai Anda tidak memiliki standar dan organisasi Anda memberi Anda tugas untuk membangunnya .

Biarkan mereka menjadi tim spesifik, bukan khusus perusahaan.

Tidak, untuk semua alasan yang dijelaskan di atas. Bahkan jika Anda berpikir untuk memformalkan pemformatan kode saja (hal yang paling tidak berguna yang mungkin ingin Anda formalkan), saya masih memiliki memori perang tanpa akhir (dan tidak berguna) tentang pemformatan. Saya tidak ingin menghidupkannya lagi dan lagi, atur sekali untuk semua.

Jangan menuliskannya jika Anda bisa menghindarinya. Alih-alih, biarkan kode menjadi cara standar ditangkap.

Tidak, untuk semua alasan yang dijelaskan di atas (tentu saja kecuali jika Anda akan memperbaiki semua kode Anda dalam sekali pakai ketika pedoman berubah). Apakah Anda ingin membiarkan kode apa adanya? Bagaimana Anda memeriksa basis kode untuk memahami pedoman saat ini ? Mencari berdasarkan usia file dan mengadaptasi gaya pengkodean Anda ke sumber usia file?

Jangan membuat undang-undang desain yang bagus. (mis. jangan bilang orang tidak menggunakan goto)

Benar, pedoman harus singkat atau tidak ada yang akan membacanya. Jangan ulangi yang sudah jelas.

Pastikan semua orang tahu bahwa standarnya adalah tentang komunikasi, dan tidak ada yang lain.

Tidak hanya, standar yang baik adalah tentang kualitas kecuali jika Anda ingin memiliki standar hanya tentang detail kecil .

Setelah beberapa iterasi pertama, buat tim bersama untuk memutuskan.

Lihat poin pertama dan jangan lupa bahwa standar pengkodean biasanya merupakan proses yang membutuhkan waktu bertahun-tahun untuk dikembangkan dan disempurnakan: beberapa iterasi, mungkin dengan pengembang junior? Benarkah? Apakah Anda ingin mengandalkan memori satu anggota senior (jika ada)?

Tiga catatan:

  • Menurut pendapat saya kekurangan lebih serius dengan beberapa bahasa daripada yang lain, misalnya dalam C ++ standar tingkat perusahaan bahkan lebih dibutuhkan daripada di Jawa.
  • Alasan ini mungkin tidak berlaku sepenuhnya (dan alasan Paman Bob mungkin tidak terlalu ekstrem ) jika Anda bekerja di perusahaan yang sangat kecil di mana Anda hanya memiliki satu tim kecil.
  • Anda dipekerjakan (sebagai tim) dan Anda akan bekerja sendiri dengan satu proyek baru maka Anda akan melupakannya dan melanjutkan. Dalam hal ini Anda mungkin tidak peduli (tetapi majikan Anda harus ...)

5
Saya telah menurunkan nilai ini karena saya merasa jawabannya tidak sesuai dengan pertanyaan, yang mengapa Anda (dan khususnya Paman Bob) tidak menulis standar pengkodean , bukan mengapa Anda harus melakukannya. Saya pikir semua orang memahami poin plus dari memiliki standar tertulis, tetapi kelemahannya lebih sulit untuk ditentukan dan ketika seorang senior industri yang disegani keluar dengan posisi menentang praktik yang biasa dalam industri, memeriksa mengapa tentu saja merupakan hal yang berharga untuk dilakukan.
Jules

5
@gnat terima kasih, saya tidak perlu upvotes untuk posting di luar topik, bukankah "Kenapa Pak X melakukannya?" di luar topik dalam kasus ini? Kami tidak tahu alasannya dan dia tidak menjelaskannya, bukankah seharusnya pertanyaan ditutup di luar topik? Bagaimana Anda menjawab pertanyaan ini? Menemukan alasan acak atau mengatakan bahwa premis itu salah?
Adriano Repetti

1
@AdrianoRepetti - Paman Bob telah melakukan banyak penjelasan selama bertahun-tahun, jadi masuk akal untuk mempertimbangkan seseorang mungkin memiliki wawasan tentang cara berpikirnya, tetapi Anda benar jika interpretasi langsung Paman Bob diperlukan.
JeffO

3
Ya ampun, jika pertanyaan adalah tentang "mengapa ia berpikir begitu" maka jawabannya hanyalah tebakan. Jika pertanyaan adalah "apakah itu benar?" maka jawaban pribadi saya benar-benar tidak.
Adriano Repetti

1
"Ketika dia bekerja untuk Microsoft dia harus mematuhi pedoman tertulis mereka" - Anda bertaruh saya lakukan. Dan tentu saja kami menggunakan FXCop dan StyleCop untuk mencegah beberapa pola buruk tidak pernah masuk.
Eric Lippert

12
  1. Agar berguna, standar pengkodean tidak boleh berbicara tentang masalah substansi; hanya masalah gaya. Seharusnya hanya menentukan hal-hal yang sewenang-wenang dan ambigu. mis. Penempatan brace, kedalaman lekukan, spasi vs tab, konvensi penamaan, dll.
  2. Masalah gaya adalah lokal, bukan global. Setiap tim harus mengadopsi gaya khas mereka sendiri, disesuaikan dengan tugas mereka, dan kepribadian mereka. Ini menjaga standar sederhana dan ringan. Standar perusahaan menjadi terbebani dengan semua pertimbangan, konfigurasi, dan pengecualian yang dimungkinkan.
  3. Dalam sebuah tim, satu-satunya alasan untuk menulis dokumen gaya pengkodean terpisah adalah jika kode yang dihasilkan oleh tim tidak memenuhi standar. Dalam hal ini Anda tidak memiliki standar. Agar efektif, standar harus dinyatakan oleh kode itu sendiri. Dan jika demikian, tidak perlu dokumen terpisah.
  4. Dalam sistem lama tim dan gaya berubah seiring waktu. Tidak ada yang salah dengan itu. Kode lama akan memiliki gaya yang lebih lama. Kode yang lebih baru akan memiliki gaya yang lebih baru. Tim harus mengetahui gaya dan usia mereka. Setiap kali kode baru ditulis, itu harus dalam gaya baru, di mana pun dalam kode itu berada.

Saya memiliki beberapa kebingungan: 1) menjadi berguna standar pengkodean tidak boleh berbicara hanya tentang pemformatan (masalah perang suci tetapi mudah dipahami membaca kode) tetapi membangun untuk menghindari, pola pengkodean (untuk mencegah kesalahan umum, tidak mudah dimengerti bahasa fitur) dan masalah keamanan. Ini adalah pedoman pengkodean (lebih bermanfaat daripada masalah pemformatan). 2) Mengingat premis poin 1 maka ini bukan tentang kepribadian (tetapi mungkin tentang tugas ), Anda dapat memiliki standar perusahaan yang ringan, itu tugas Anda sendiri untuk membuatnya ringan.
Adriano Repetti

3) Kode dapat memberi tahu Anda apa yang harus dilakukan tetapi tidak dapat menyampaikan apa yang tidak boleh Anda lakukan (kecuali jika Anda ingin mempelajari seluruh basis kode dan bahkan dalam kasus itu ... hanya tidak perlu menggunakan X construct atau itu a no-no?) Hal penting lainnya adalah alasannya: mengapa tidak? dan mengapa ya? Hal-hal dapat berubah dari waktu ke waktu tetapi bagaimana Anda tahu jika bangunan awal masih valid? 4) dan ketika Anda seorang anggota tim baru dan Anda menulis kode baru ... apakah Anda mempelajari basis kode dengan usia yang sama untuk mempertahankan gaya pengkodean itu? Sehari setelah Anda pindah ke komponen lain yang lebih baru dan Anda mempelajari basis kode lagi (pemfilteran menurut tanggal pembuatan?)
Adriano Repetti

BTW jika, sebaliknya, Anda menyarankan untuk tidak menuliskan hanya gaya pemformatan kode maka saya mungkin setuju (well, sebenarnya tidak tetapi dengan alasan yang tidak begitu kuat selain ingatan diskusi tanpa akhir dan tidak berguna yang pasti akan muncul setiap waktu - dan yang menjadi pedoman perusahaan) akan menghindari sekali untuk semua) namun Anda harus membuatnya jelas atau orang akan menafsirkan kata-kata Anda terlalu harfiah (lihat sebagian besar jawaban + komentar di sini). Juga poin tentang "goto" agak menyesatkan dalam pengertian ini (IMO)
Adriano Repetti

4

Mengapa saya tidak menulis Standar Pengkodean?

Ada banyak alasan untuk ini. Berikut beberapa pertimbangan:

  1. Berapa banyak waktu orang menghabiskan "belajar" standar kode hanya untuk memiliki banyak waktu masuk ke seluruh tim meninjau, berdiskusi, mendokumentasikan, merevisi ... dll. Standar kode. Ini seperti terus-menerus mendiskusikan "Buku Pegangan Karyawan" Anda - seberapa sering hal itu masuk dalam agenda rapat tim?

  2. Ketika sebuah proyek mengalami kerusakan / disimpan / dll. maka beberapa orang yang tetap biasanya tidak dapat terus mematuhi (atau mungkin bahkan belum membaca) standar. Hal berikutnya yang Anda tahu, semua upaya untuk "menjaga kode tetap bersih" ternyata terbuang sia-sia.

  3. Jika proyek terhenti atau pimpinan baru dimasukkan, sangat mungkin orang tersebut akan mengabaikan aturan sebelumnya dan ingin melakukannya dengan cara yang baru. Sekali lagi, apa yang diperoleh dengan mengkodifikasi standar ??

Anda harus yakin membaca # 6:

Setelah beberapa iterasi pertama, buat tim bersama untuk memutuskan.

Dengan kata lain, ketika saatnya untuk memulai suatu proyek, ikuti saja alirannya untuk sementara waktu. Kemudian diskusikan aturan umum standar pengkodean yang digunakan oleh tim saat ini - dan pada dasarnya ikuti mereka. Dengan begitu, Anda memaksimalkan upaya yang dilakukan untuk meningkatkan produk sambil meminimalkan upaya yang diperlukan untuk menulis, meninjau dan mendokumentasikan "gula sintaksis" yang digunakan untuk mendapatkan kode yang dapat dieksekusi.

Sangat sedikit tim yang memperoleh manfaat besar dari standar pengkodean. Biasanya, "keterbacaan" terlalu kabur - dan sebagian besar pengembang tidak mendapatkan banyak manfaat dari aturan yang tepat tentang penspasian, baris baru, dll. Tetapi Anda dapat menghindari pengembang yang terus-menerus mengganggu dengan memiliki setidaknya beberapa aturan.


4

Jawaban lain yang menurut saya tidak cukup jelas dinyatakan, adalah itu juga berarti bahwa orang tidak mengikuti aturan secara membabi buta. Ini berarti bahwa orang harus datang dengan pembenaran aktual untuk keputusan desain dan konvensi pengkodean mereka, daripada hanya bergantung pada fakta bahwa itu telah ditulis untuk membenarkannya.


4

Pertama, sejauh yang saya tahu, Paman Bob adalah orang Jawa, ini sangat penting untuk memahami apa yang dikatakannya.

Ketika bekerja di tim Java atau C #, jika kode saat ini telah ditulis oleh pengembang yang berpengalaman, mudah bagi saya untuk mengambil gaya pengkodean dan mengikuti perkembangannya. Jika saya tidak mau melakukannya, mungkin saya bukan orang yang tepat untuk pekerjaan itu ... Jika tidak ada peninjauan kode atau pemrograman pasangan untuk menjemput saya ketika saya tidak mengikuti gaya, maka perusahaan memiliki masalah yang lebih besar dari cara saya memberi nama bidang anggota!

Baik Java dan C #, bersama dengan sebagian besar bahasa modern, telah didefinisikan sehingga ada beberapa perangkap "sederhana" bagi seorang programmer.

Namun ketika saya mulai pemrograman saya menggunakan C (dan kemudian C ++). Di C Anda dapat menulis kode seperti

if (a = 3);
{
   /* spend a long time debugging this */
}

Kompiler tidak akan memberikan kesalahan, dan itu sulit dikenali ketika membaca banyak kode. Namun, jika Anda menulis:

if (3 = a)
{
   /* looks odd, but makes sense */
}

Kompiler memberikan kesalahan, dan saya mudah untuk mengubah kode 3 == a. Demikian juga, jika standar pengkodean tidak memungkinkan =untuk digunakan dalam ifkondisi atau " ifpernyataan kosong ", maka pemeriksa kode dapat digunakan sebagai bagian dari sistem build untuk melacak kesalahan ini.

Pandangan saya tentang standar pengkodean berubah sangat ketika saya pindah dari C / C ++: Saya dulu suka standar pengkodean yang ditegakkan secara ketat, dan banyak halaman panjangnya. Saya sekarang berpikir Anda hanya perlu membuat daftar alat yang digunakan, dan mendapatkan persetujuan informal antara anggota tim asli pada beberapa konvensi penamaan. Kami tidak lagi tinggal di dunia tim yang terdiri lebih dari 30 pengembang yang menulis aplikasi dalam C / C ++ ...

Ada alasan saya tidak pernah menyukai JScript, dan menganggap TypeScript adalah hal terbaik yang terjadi pada pengembangan web selama bertahun-tahun. Saya berharap bahwa pengembang Web UI masih membutuhkan standar pengkodean karena cacat dalam desain HTML / CSS / JScript dll.


4
"Kompilator tidak akan memberikan kesalahan" kebanyakan kompiler C dan C ++ modern mendukung pelaporan perilaku seperti itu dengan peringatan atau, jika diinginkan, kesalahan penuh. gcc.gnu.org/onlinedocs/gcc/Warning-Options.html
JAB

2
"Pertama sejauh yang saya tahu Paman Bob adalah orang Jawa, ini sangat penting dalam memahami apa yang dia katakan", itu tidak benar, Paman Bob telah menulis artikel fantastis tentang C ++ dan dia pasti telah bekerja beberapa tahun dengan C juga.
Alessandro Teruzzi

@ JAB, Syukurlah C / C ++ berhenti digunakan untuk "aplikasi bisnis" baru sejak lama, (misalnya sebelum modem C / C ++ kompiler), dan sekarang sebagian besar hanya digunakan oleh para ahli C / C ++, daripada orang-orang yang ahli UI (MFC) misalnya.
Ian

1
@AlessandroTeruzzi Tes unit akan memberi tahu Anda bahwa suatu metode gagal. Mengapa gagal adalah masalah yang berbeda - bahkan jika Anda memiliki unit test untuk metode dengan kode semacam itu, Anda akan mengalami kesulitan untuk mencari tahu apa yang salah. C ++ adalah salah satu bahasa yang paling menghukum untuk debug.
T. Sar

2
Saya pikir ada kesalahpahaman di sini, Anda tidak dapat mengambil satu kalimat pun dari PamanBob dan menganalisisnya secara terpisah. Jika Anda memiliki perangkat lunak SOLID dengan kelas kecil, metode pendek dan cakupan uji unit antipeluru, standar pengkodean adalah berlebihan. Jika Anda memiliki kode yang lemah, antarmuka yang besar, fungsi besar dan cakupan yang kecil, standar pengkodean dapat memberi Anda beberapa manfaat. Tetapi, UncleBob tidak menyarankan untuk tidak memilikinya, tetapi untuk menyebarkannya secara lisan dengan kolaborasi dan refactoring (menghapus kode yang lemah dari basis sumber). Jadikan kode Anda standar pengodean langsung.
Alessandro Teruzzi

3

Memiliki sumber menjadi standar pengkodean self-documenting menyiratkan dua hal.

  1. Orang-orang harus berkonsultasi dengan basis kode dan meninjaunya untuk menjadi kontributor yang mahir. Ini sangat penting. Membaca pedoman pengkodean adalah buang-buang waktu dibandingkan dengan menyelam ke dalam basis kode.
  2. Ini mengakui bahwa perbedaan kecil tidak penting. Sangat penting untuk menyetujui dan memahami prinsip-prinsip dasar. Mempertahankan gaya yang konsisten tidak diupayakan karena l'art pour l'art. Itu tidak memungkinkan nitpickers yang tidak kreatif mengganggu dan mengalihkan perhatian orang lain. Ini adalah tentang memfasilitasi komunikasi melalui kode dalam sebuah tim.

2

Dokumen standar kode yang sering diperbarui dan ditulis dengan baik bisa sangat berguna, tetapi biasanya tidak demikian. Dokumen standar tidak mencerminkan standar pengkodean aktual yang digunakan oleh perusahaan karena sangat sulit untuk membuat dokumen standar yang baik dan bahkan lebih sulit untuk tetap memperbaruinya.

Daripada memiliki dokumen standar pengkodean yang buruk dan menyesatkan, lebih baik tidak memilikinya dan membiarkan kode itu sendiri mewakili standar tersebut. Apa pun bagian terpenting adalah menerapkan standar dalam kode, dan ini membutuhkan lebih dari sekadar dokumen. Motivasi, proses, pelatihan, alat dll jauh lebih penting.


2

Satu hal yang sangat penting yang belum dinyatakan dengan cukup jelas adalah bahwa standar pengkodean seperti bahasa: mereka berkembang. Standar pengkodean tertulis menghalangi hal ini, dan jika tidak, standarnya terus-menerus usang dan tidak berguna.

Tidak memiliki standar coding dipaku tidak terlalu buruk. Jika Anda melakukan peer review pada saat check-in, setiap kali sesuatu yang tidak sesuai dengan standar pengkodean memasuki repositori yang berarti 2 orang memikirkannya * dan memutuskan manfaat variasi ini lebih besar daripada ketidakkonsistenan dengan sisa kode.

Tidak memiliki standar tertulis juga menghilangkan birokrasi yang akan mencegah tim perusahaan untuk mencoba variasi baru dari standar pengkodean untuk proyek baru, baik karena mereka ingin mencoba sesuatu, atau mungkin karena standar yang berbeda memiliki aplikasi praktis pada beberapa alat otomatis yang mereka gunakan.

Menulis standar memiliki kecenderungan untuk menghapus lebih banyak fleksibilitas daripada yang semula dimaksudkan, sementara juga mengambil cukup banyak waktu yang dapat dihabiskan untuk melakukan hal-hal lain. Saya tidak mengatakan Anda seharusnya tidak pernah menuliskan standar pengkodean, standar tertulis tentu memiliki manfaatnya, terutama jika tim yang bekerja di lokasi yang berbeda bekerja pada basis kode yang sama.

Sangat terkait: Evolusi dalam standar pengkodean, bagaimana Anda menghadapinya?


* Jika orang tidak berpikir sambil mengintip kode peninjauan saat check-in, masalah Anda jauh lebih besar dari sekadar standar pengkodean.


1

Mengubah mereka menjadi rintangan utama, dan orang akan mematuhi surat hukum dengan aman daripada melibatkan otak dan melakukan hal yang benar.

Akan datang suatu hari ketika bagian dari standar tidak membantu, dan membuat kode lebih buruk. Beberapa orang akan mematuhi standar, karena itu ditulis dan mereka aman, dan karena ada aturan yang harus diikuti. Orang yang ingin menulis kode yang baik daripada kode yang sesuai standar akan frustrasi dan marah. Akan ada argumen dan perbedaan pendapat, sedangkan jika standar tidak ditulis, akan ada eksplorasi dan diskusi.


0

Saya pikir banyak posting di sini membingungkan standar pengkodean dengan panduan gaya .

Memastikan bahwa modul yang dikembangkan oleh tim yang berbeda memiliki opsi kompiler yang sama dan ABI adalah hal yang berbeda dari berapa banyak ruang yang diindentasi.

Hal-hal seperti cara yang tepat untuk membuat struktur #include file dan tidak mencemari namespace global dalam file header harus didokumentasikan sehingga mereka dapat digunakan sebagai daftar periksa selama pengkodean awal dan ulasan kode.

Khususnya "jangan gunakan XXX karena menyebabkan masalah kompatibilitas dengan YYY" bukanlah sesuatu yang akan Anda lihat dengan contoh dalam mengikuti kode lain, karena itu tidak ada. Jadi biarkan kode menjadi cara standar ditangkap mungkin tidak jelas atau benar-benar hilang untuk beberapa jenis standar, dan dengan demikian ini tidak dapat menjadi rencana universal.

Sesuatu yang serius meresap dan penting seperti tidak menggunakan pengecualian atau tidak menggunakan newdalam sistem embedded tertentu tidak bisa begitu saja dibiarkan menjadi pengetahuan budaya umum, karena "informasi itu budaya (saja)" bertentangan dengan prinsip-prinsip dasar standar manufaktur seperti ISO-9000, bahwa pengembang sistem embedded ini menggunakan (misalnya untuk aplikasi otomotif). Hal-hal penting ini harus didokumentasikan, ditandatangani, dan disimpan secara formal.

Tapi itu berlaku untuk coding , bukan style .

Para penemu C dan C ++ menunjukkan, dengan contoh, penggunaan nama huruf kecil dan bukan CaMelCaSe. Jadi mengapa banyak pengembang tidak mengikuti contoh implisit dari sumber? Bukankah seharusnya gaya perpustakaan standar dan bahan ajar kanonik menjadi gaya implisit untuk diikuti?

Sementara itu, orang-orang melakukan mencontoh header perpustakaan standar untuk hal-hal yang tidak boleh disalin, seperti penggunaan __Uglynama untuk parameter makro dan menyertakan file pola non-repeat.

Jadi memiliki barang sering tidak dipandang sebagai gaya yang penting, atau sebaliknya memiliki contoh mungkin tidak jelas mengenai apa yang tidak boleh diikuti dalam kode proyek. Keduanya merupakan contoh berlawanan dengan tesis bahwa "gaya" (atau aturan pengkodean) sebaiknya dibiarkan tersirat.

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.