Adakah yang bisa menantang Paman Bob pada cintanya untuk menyingkirkan “kawat gigi yang tidak berguna”?


94

Saya benci referensi konten paywalled, tapi video ini menunjukkan apa yang saya bicarakan. Tepatnya 12 menit dalam Robert Martin melihat ini:

Beberapa kode

Dan mengatakan "Salah satu hal favorit saya untuk dilakukan adalah menyingkirkan kawat gigi yang tidak berguna" saat dia mengubahnya menjadi ini:

Lebih banyak kode

Dahulu kala, dalam pendidikan yang sangat jauh, saya diajari untuk tidak melakukan ini karena membuatnya mudah untuk memperkenalkan bug dengan menambahkan garis indentasi lain yang berpikir itu dikendalikan oleh ifsaat tidak.

Agar adil bagi Paman Bob, ia merecode metode Java yang panjang hingga fungsi kecil yang, saya setuju, jauh lebih mudah dibaca. Ketika dia selesai mengubahnya, (22.18) terlihat seperti ini:

Namun lebih banyak kode

Saya bertanya-tanya apakah itu seharusnya memvalidasi menghapus kawat gigi. Saya sudah terbiasa dengan praktik terbaik . Bisakah Paman Bob ditantang dalam hal ini? Apakah Paman Bob membela gagasan itu?


6
Saya memilih untuk menutup pertanyaan ini sebagai di luar topik karena jawaban apa pun akan menjadi "tidak" atau "ya, dan ini kutipannya."
Blrfl

35
Berikan beberapa tahun, mungkin dia akan menghapus linebreak yang tidak berguna juga, dan "jika (lihat (sesuatu)) katakan (sesuatu);" akan benar - benar menjadi baris kode ;-)
Steve Jessop

8
@SteveJessop Senang mendengar bahwa saya tahun depan. : D Tanpa baris baru, tidak ada risiko bug yang terkenal itu. Menambahkan / menghapus kawat gigi sesuai kebutuhan adalah overhead tambahan, tetapi lebih banyak disimpan ketika membaca.
maaartinus

9
Paman Bob membuat beberapa poin bagus untuk melakukannya dalam Kode Bersih, halaman 35. Jika sebuah ifblok hanya satu baris, itu tidak masalah. Jika Anda perlu menambahkan lebih banyak baris, itu harus fungsi lain yang mengurangi ifblok kembali ke satu baris (panggilan fungsi). Jika Anda mematuhi itu, maka kawat gigi tidak masalah - sama sekali .

13
dia hanya harus melakukan return (page==null) ? "" : includePage(mode,page);jika dia terlalu ingin mendapatkan ... Saya pikir gaya tanpa-penjepit itu keren sampai saya mulai mengembangkan aplikasi secara profesional. Diff noise, kemungkinan kesalahan ketik dll. Kawat gigi, berada di sana sepanjang waktu, menghemat waktu & overhead yang perlu Anda perkenalkan nanti.
vaxquis

Jawaban:


47

Keterbacaan bukanlah hal kecil.

Saya memiliki pikiran campuran ketika datang ke kawat gigi yang melampirkan metode tunggal. Saya pribadi menghapusnya untuk hal-hal seperti pernyataan pengembalian satu baris, tetapi meninggalkan kawat gigi seperti itu sebenarnya sangat menggigit kami di tempat terakhir saya bekerja. Seseorang menambahkan satu baris kode ke ifpernyataan tanpa juga menambahkan tanda kurung yang diperlukan, dan karena itu adalah C, itu menabrak sistem tanpa peringatan.

Saya tidak pernah menantang siapa pun yang religius tentang selalu menggunakan kawat gigi setelah kegagalan kecil itu.

Jadi saya melihat manfaat dari keterbacaan, tetapi saya sangat menyadari masalah yang dapat muncul ketika Anda meninggalkan kawat gigi itu.

Saya tidak akan repot mencari studi atau pendapat seseorang yang dipublikasikan. Setiap orang memiliki satu (pendapat, yaitu), dan karena ini adalah masalah gaya, satu pendapat sama baiknya dengan yang lain. Pikirkan masalah Anda sendiri, evaluasi pro dan kontra, dan buat pikiran terkutuk Anda sendiri. Jika toko tempat Anda bekerja memiliki standar pengkodean yang mencakup masalah ini, cukup ikuti itu.


7
Saya sedikit kesal dengan hal ini, ketika indentasi tidak aktif dan menyesatkan.
Andy

12
Karena itu C tanpa GCC 6-Wmisleading-indentation .
wchargin

2
@CandiedOrange: Adalah Paman Bob yang menantang dogma mapan.
Robert Harvey

1
@RobertHarvey Bukankah saya sudah menjelaskannya? Ya, dia menantang dogma. Dia menantang dogma SAYA. Saya hanya berusaha menjadi murid yang baik dan setidaknya mempertimbangkannya. Tapi Paman Bob sangat karismatik, itu membuatku bertanya-tanya apakah aku kehilangan objektivitas. Jadi saya meminta bantuan untuk menemukan penawar racun sebelum saya minum koolaid.
candied_orange

1
@CandiedOrange: Ini benar-benar hal konteks. Orang-orang yang hanya menerima dogma secara membabi buta tidak mempertimbangkan konteks; mereka adalah orang-orang yang masih menggunakan aturan "satu-satunya kembali" dalam bahasa yang dikelola, lama setelah aturan tersebut habis manfaatnya dan benar-benar menjadi penghalang.
Robert Harvey

133

Anda dapat menemukan beberapa promosi yang diterbitkan atau penolakan gaya tanpa penyangga di sini atau di sini atau di mana gudang sepeda dicat.

Melangkah menjauh dari gudang sepeda, ingat bug OS X / iOS SSL hebat tahun 2014?

if ((err = SSLHashSHA1.update(&hashCtx, &serverRandom)) != 0)
    goto fail;
if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 0)
    goto fail;
    goto fail;
if ((err = SSLHashSHA1.final(&hashCtx, &hashOut)) != 0)
    goto fail;

Yap, "disebabkan" oleh blok tanpa penyangga https://www.imperialviolet.org/2014/02/22/applebug.html

Preferensi mungkin tergantung pada gaya penyangga. Jika saya harus menulis

if (suiteSetup)
{
    includePage(mode, suiteSetup);
}

Saya mungkin cenderung menghemat ruang juga. Tapi

if (suiteSetup) {
    includePage(mode, suiteSetup);
}

hanya menggunakan satu baris "ekstra".


Saya tahu Anda tidak bertanya, tetapi jika saya bekerja sendiri, saya adalah bidat. Jika saya menghapus kawat gigi, saya lebih suka

if (suiteSetup != null) includePage(mode, suiteSetup);

Ini tidak memiliki masalah visual yang sama dengan bug iOS-style iOS, tetapi menyimpan lebih banyak baris "tidak perlu" daripada Paman Bob;) Dibaca dengan baik jika Anda terbiasa, dan memiliki penggunaan umum di Ruby ( includePage(mode, suiteSetup) unless suiteSetup.nil?). Oh well, ketahuilah bahwa ada banyak pendapat.


13
Plus, jika Anda menggunakan } else[if(...)] {, itu tidak menambahkan garis tambahan apa pun, sehingga hanya menambah satu baris tambahan di seluruh hal.
Random832

12
Saya senang Anda memunculkan bug iOS SSL. Sejak itu, saya semakin sering menggunakan kawat gigi dalam situasi seperti itu.
Zach Lipton

4
Mengenai bug "goto gagal", perlu dicatat bahwa aspek lain dari gaya pengkodean Paman Bob akan mencegahnya, juga, yang paling penting preferensi kuatnya untuk metode yang sangat pendek. Dia tidak akan pernah mentolerir metode 79-line di tempat pertama, dan jika metode tersebut dipecah menjadi yang lebih kecil (a) konflik penggabungan yang menyebabkan duplikasi mungkin tidak akan pernah terjadi dan (b) kontrol aliran yang lebih sederhana dalam metode mungkin berarti bahwa peringatan kompiler untuk kode yang tidak terjangkau akan dihasilkan yang seharusnya mencegah masalah tersebut.
Jules

16
"goto fail" bukan disebabkan oleh blok baris tunggal, itu disebabkan oleh pemrograman yang ceroboh, bahkan peninjauan kode yang lebih ceroboh, dan bahkan tidak sekali pun menelusuri kode secara manual.
gnasher729

35
Meh, kurangnya kawat gigi tidak menyebabkan bug itu. Pemrogram yang mengecewakan (dan kurangnya ulasan kode yang berarti, pengujian) lakukan. Perbaiki masalah dengan memecat mereka yang bertanggung jawab, bukan dengan mengikat tangan kita semua!
Lightness Races in Orbit

62

Paman Bob memiliki banyak lapisan pertahanan terhadap kesalahan seperti itu yang tidak biasa ketika "selalu menggunakan kawat gigi" adalah kebijaksanaan yang berlaku:

  1. Preferensi pribadi yang kuat untuk persyaratan jalur tunggal, sehingga yang multi-jalur menonjol dan menerima pengawasan ekstra.
  2. Editor yang secara otomatis ketinggalan zaman ketika Anda memasukkan baris kedua.
  3. Rangkaian lengkap unit test yang ia jalankan secara konstan.
  4. Serangkaian tes integrasi lengkap.
  5. Tinjauan sejawat dilakukan sebelum kodenya digabungkan.
  6. Jalankan kembali semua tes dengan server integrasi berkelanjutan.
  7. Pengujian dilakukan oleh departemen kualitas produk.

Saya pikir jika seseorang menerbitkan tantangan kepada Paman Bob, ia akan memiliki bantahan yang cukup bagus dengan poin-poin di atas. Ini adalah salah satu kesalahan termudah untuk ditangkap lebih awal.


16
Saya tidak pernah takut menabrak cara saya takut hal-hal yang gagal diam-diam. Setidaknya Anda tahu kapan kecelakaan terjadi. Bagian belakang otakku merinding ketika aku melihat barang-barang ini. Itu menggelitik dengan cara yang sama ketika aku melihatnya while(true);{break;}. Jika benar-benar ada konteks yang valid untuk ini, saya perlu waktu untuk mengatasinya.
candied_orange

9
Apakah kita memiliki cara pemeriksaan otomatis yang includePage()bukan makro yang ditulis dengan buruk dengan lebih dari satu pernyataan?
Martin York

51
@LokiAstari Ya, ini disebut "Java tidak memiliki makro".
svick

11
Semua hal di atas lebih "cara untuk menghindari bahwa kejatuhan terkait dengan kebijakan 'kawat gigi tidak berguna' menyakiti saya" daripada benar-benar "alasan untuk menggunakan 'kebijakan kawat gigi tidak berguna". Fakta-fakta yang Anda butuhkan (khususnya # 1) harus dianggap lebih sebagai kerugian daripada keuntungan.
SJuan76

16
@ Jules Oh ya! SEMUA produk yang saya terima atau dirilis di tempat kerja memiliki cakupan pengujian 100% (paling tidak), ditinjau oleh rekan (beberapa kali) dan semua bisnis di sekitar memiliki departemen QA Perangkat Lunak. Iya. Saya kira Anda telah menemukan hal yang sama dalam karier profesional Anda, karena setiap bisnis memiliki tim pemrogram, bukan pemrogram tunggal, dan mereka memberi mereka lebih dari cukup waktu untuk melakukan semua pengujian yang ingin mereka lakukan. Ya itu menggambarkan semua tempat kerja dengan sempurna. Mengapa harus khawatir tentang menambahkan beberapa bug tambahan ketika kami yakin perangkat lunak kami SELALU mengirimkan 100% bug gratis?
SJuan76

31

Untuk sebagian besar ini adalah preferensi pribadi, namun ada beberapa hal yang perlu dipertimbangkan.

Kemungkinan Bug

Meskipun dapat dikatakan bahwa bug yang disebabkan oleh lupa untuk menambahkan-in kawat gigi jarang terjadi, dari apa yang saya lihat bahwa mereka tidak terjadi sesekali (tidak melupakan terkenal goto IOS gagal bug). Jadi saya pikir ini harus menjadi faktor ketika mempertimbangkan gaya kode Anda (beberapa alat memperingatkan tentang indentasi menyesatkan , jadi itu tergantung pada rantai alat Anda juga) .

Hari Code (yang berbunyi seperti itu mungkin menjadi bug)

Bahkan dengan asumsi proyek Anda tidak menderita dari bug tersebut, ketika membaca kode Anda mungkin melihat beberapa blok dari kode yang terlihat seperti mereka bisa menjadi bug - tetapi tidak, mengambil beberapa siklus mental Anda.

Kita mulai dengan:

if (foo)
    bar();

Pengembang menambahkan komentar yang bermanfaat.

if (foo)
    // At this point we know foo is valid.
    bar();

Kemudian pengembang mengembangkannya.

if (foo)
    // At this point we know foo is valid.
    // This never fails but is too slow even for debug, so keep disabled.
    // assert(is_valid(foo));
    bar();

Atau menambahkan blok bersarang:

if (foo)
    while (i--) {
        bar(i);
        baz(i);
    }

Atau menggunakan makro:

if (foo)
    SOME_MACRO();

"... Karena makro dapat mendefinisikan beberapa baris kode, apakah makro digunakan do {...} while (0)untuk banyak baris? Seharusnya karena itu ada dalam panduan gaya kita tapi aku lebih baik memeriksa kalau-kalau!"


Contoh di atas adalah semua kode yang valid, namun semakin banyak konten dalam blok-kode, semakin banyak yang perlu Anda baca untuk memastikan tidak ada kesalahan.

Mungkin gaya kode Anda mendefinisikan bahwa blok multi-line memerlukan penjepit (tidak peduli apa, bahkan jika itu bukan kode) , tetapi saya telah melihat komentar semacam ini ditambahkan dalam kode produksi. Ketika Anda membacanya, ada sedikit keraguan bahwa siapa pun yang terakhir mengedit baris-baris itu lupa menambahkan kurung kurawal, kadang-kadang saya merasa perlu memeriksa ulang berfungsi sebagaimana dimaksud (terutama ketika menyelidiki bug di area kode ini) .

Kebisingan Diff

Salah satu alasan praktis untuk menggunakan kawat gigi untuk saluran tunggal adalah untuk mengurangi kebisingan berbeda .

Yaitu, mengubah:

if (foo)
    bar();

Untuk:

if (foo) {
    bar();
    baz();
}

... menyebabkan garis kondisional muncul di dalam diff ketika sedang diubah, ini menambahkan beberapa overhead kecil tetapi tidak perlu.

  • baris muncul sebagai sedang diubah dalam tinjauan kode, jika alat Anda berbeda berbasis kata Anda dapat dengan mudah melihat bahwa hanya kurung kurawal yang berubah, tetapi itu membutuhkan lebih banyak waktu untuk memeriksa lalu jika garis tidak berubah sama sekali.
    Karena itu, tidak semua alat mendukung perbedaan berbasis kata, diff (svn, git, hg ... dll) akan menunjukkan seolah-olah seluruh baris berubah, bahkan dengan alat mewah, kadang-kadang Anda mungkin perlu dengan cepat melihat ke garis polos berbasis-diff untuk melihat apa yang berubah.
  • alat anotasi (seperti git blame) akan menunjukkan baris sebagai sedang diubah, membuat pelacakan asal dari suatu langkah lebih banyak untuk menemukan perubahan nyata .

Keduanya kecil, dan tergantung pada berapa banyak waktu yang Anda habiskan dalam tinjauan kode atau pelacakan yang melakukan perubahan baris kode.

Ketidaknyamanan yang lebih nyata karena perubahan garis tambahan dalam diff, kemungkinan kapalnya lebih tinggi bahwa perubahan dalam kode akan menyebabkan konflik yang menggabungkan dan perlu diselesaikan secara manual .


Ada pengecualian untuk ini, untuk basis kode yang memiliki {jalurnya sendiri - ini bukan masalah.

The diff kebisingan argumen tidak tahan jika Anda menulis dalam gaya ini:

if (foo)
{
    bar();
    baz();
}

Namun ini bukan konvensi umum, jadi terutama menambahkan jawaban untuk kelengkapan (tidak menyarankan proyek harus menggunakan gaya ini) .


8
Saya suka mengurangi suara diff berkomentar yang merupakan nilai tambah.
Martin York

2
Kalau saja semua orang yang marah tentang JSON memiliki pertimbangan untuk kebisingan yang berbeda! Saya melihat Anda, aturan no-last-koma.
Roman Starkov

1
Huh, saya belum mempertimbangkan manfaat beda-gaya dari {-pada-garis-sendiri. Saya benar-benar benci gaya itu, dan tidak suka mengerjakan proyek-proyek di mana gaya itu diperlukan. Mungkin dengan itu dalam pikiran, saya akan merasa sedikit kurang frustasi harus kode seperti itu. Kepadatan kode itu penting. Jika Anda dapat melihat semua fungsi pada monitor Anda sekaligus, Anda dapat lebih mudah melakukan semuanya. Saya suka meninggalkan garis kosong antara blok kode yang terpisah di dalam fungsi untuk keterbacaan (untuk pernyataan terkait kelompok), dan dipaksa untuk membuang-buang ruang di tempat lain membuat jeda yang dimaksudkan lebih lemah.
Peter Cordes

1
@ peter-cordes, juga bukan penggemar gaya {on-line-nya-sendiri, hanya memasukkannya untuk kelengkapan jawaban. Sedangkan untuk mempercayai makro untuk digunakan do{}while(0), saya menemukan masalah dengan ini adalah Anda dapat mempercayainya hampir setiap saat. Masalahnya adalah kecelakaan bisa terjadi, kesalahan dapat terjadi dengan ulasan kode ... dan bug dapat diperkenalkan yang tidak akan terjadi sebaliknya.
ideasman42

2
Jika kami mendaftar bug potensial, kemampuan untuk mengomentari setiap baris adalah hal yang baik. Saya melacak bug yang disebabkan oleh seseorang yang secara membabi buta berkomentar keluar dari tubuh pernyataan satu baris. Pernyataan berikut kemudian dieksekusi secara kondisional, bukan dieksekusi tanpa syarat.
Keju Eldritch

15

Bertahun-tahun yang lalu, saya dibawa untuk men-debug beberapa kode C. Bug itu sangat sulit ditemukan, tetapi akhirnya ia berubah menjadi pernyataan seperti:

if (debug)
   foo (4);

Dan ternyata orang yang menulisnya telah didefinisikan foosebagai makro. Makro dengan dua baris kode di dalamnya. Dan tentu saja, hanya yang pertama dari dua baris yang dikenakan if. (Jadi baris kedua dieksekusi tanpa syarat.)

Ini mungkin benar-benar unik untuk C dan preprosesornya - yang melakukan pergantian sebelum kompilasi - tetapi saya tidak pernah melupakannya. Hal semacam itu meninggalkan bekas pada Anda, dan mengapa tidak bermain aman - terutama jika Anda menggunakan berbagai bahasa dan perkakas dan tidak dapat memastikan bahwa kejahatan seperti itu tidak mungkin terjadi di tempat lain?

Sekarang saya inden dan menggunakan kawat gigi secara berbeda dari orang lain, tampaknya. Untuk satu baris if, saya akan lakukan:

if (debug) { foo (4); }

jadi tidak perlu jalur tambahan untuk memasukkan kawat gigi.


6
Dalam hal ini, siapa pun yang menulis makro itu yang salah.
gnasher729

6
Menulis macro preprocessor C dengan benar mungkin tidak intuitif, tetapi dapat dilakukan. Dan itu harus dilakukan, seperti yang ditunjukkan gnasher729. Dan contoh Anda adalah alasan mengapa makro apa pun yang berisi lebih dari satu pernyataan harus menyertakan tubuhnya dalam satu do { ... } while(0)lingkaran. Ini tidak hanya memastikan bahwa itu akan selalu diperlakukan dengan benar dengan melampirkan if()pernyataan, tetapi juga bahwa tanda koma di akhir pernyataan ditelan dengan benar. Siapa pun yang tidak tahu tentang aturan sederhana seperti itu, tidak boleh menulis macro preprocessor. Membela di situs panggilan adalah tempat yang salah untuk mempertahankan.
cmaster

18
@ cmaster: Benar, tetapi bagaimana makro (atau fitur bahasa lainnya) ditulis oleh orang lain di luar kendali saya. Bagaimana saya menggunakan kawat gigi ada di bawah kendali saya. Saya jelas tidak mengatakan ini adalah alasan berbalut besi untuk memasukkan kawat gigi, tetapi itu adalah sesuatu yang bisa saya lakukan untuk membela diri terhadap kesalahan orang lain jadi saya melakukannya.
Wayne

@ gnasher729, siapa yang peduli kalau itu kesalahan orang lain? Jika Anda melakukan tinjauan kode dan mengikuti beberapa standar kode yang masuk akal, itu mungkin juga kesalahan tim Anda. Dan jika mencapai pengguna, mereka akan menyalahkan organisasi mengeluarkan perangkat lunak kereta.
ideasman42

1
Siapa pun yang menemukan makro adalah yang salah.
Neme

14

"Paman Bob" diizinkan untuk memiliki pendapatnya, Anda diizinkan untuk memiliki pendapat Anda. Tidak perlu menantangnya.

Jika Anda ingin banding ke pihak berwenang, ambil Chris Lattner. Di Swift, jika pernyataan kehilangan tanda kurung, tetapi selalu disertai dengan tanda kurung. Tidak ada diskusi, itu bagian dari bahasa. Jadi jika "Paman Bob" mulai menghapus kawat gigi, kode berhenti mengkompilasi.

Memeriksa kode orang lain dan "menyingkirkan kawat gigi yang tidak berguna" adalah kebiasaan buruk. Hanya menyebabkan kerja ekstra ketika kode perlu ditinjau, dan ketika konflik tidak perlu dibuat. Mungkin "Paman Bob" adalah programmer yang sangat baik sehingga dia tidak perlu ulasan kode? Saya menyia-nyiakan satu minggu dalam hidup saya karena seorang programmer terkemuka mengubah "if (p! = NULL)" menjadi "if (! P)" tanpa ulasan kode, disembunyikan di tempat yang paling buruk.

Ini sebagian besar merupakan perdebatan gaya yang tidak berbahaya. Kawat gigi memiliki keuntungan bahwa Anda dapat menyisipkan baris kode lain tanpa menambahkan kawat gigi. Seperti pernyataan logging, atau komentar (jika diikuti oleh komentar diikuti oleh pernyataan hanya mengerikan). pernyataan pada baris yang sama seolah-olah memiliki kelemahan praktis bahwa Anda memiliki masalah dengan banyak debuggers. Tetapi lakukan apa yang Anda inginkan.


1
Saya kira ini tentang "tantangan" karena UB (sic!) Menyajikan pendapatnya sebagai fakta - setidaknya itu mengejutkan saya ketika saya mendengarkannya.
vaxquis

3
Mengatakan "Lakukan apa pun yang Anda sukai" sebenarnya setuju dengan Paman Bob mengenai hal ini karena itu yang ia katakan "tidak masalah". Dalam banyak bahasa ini bukan masalah. Saya sebelumnya telah berpikir dalam semua yang merupakan masalah Anda harus SELALU menggunakan kawat gigi dan tidak melihat ada yang menantang itu. Sekarang, inilah Paman Bob yang menantangnya dan saya bertanya-tanya apakah dia lolos karena dia bekerja dengan metode yang sangat sederhana atau karena dia penuh dengannya. Saya tidak menganggapnya tidak berbahaya karena jenis bug @PaulDraper menyebutkan jawabannya.
candied_orange

Re selalu : kebisingan sintaksis adalah mengganggu dan ekstra "kosong" baris untuk penjepit dekat menambahkan pemisah visual dalam paragraf di mana garis tidak boleh terpecah, lanjut menghambat pembacaan. Ini terutama penting dalam blok kecil ringkas yang Anda sebutkan.
JDługosz

9

Alasan saya untuk tidak melepas kawat gigi adalah:

  1. mengurangi keputusasaan keputusan. Jika Anda selalu menggunakan kawat gigi, Anda tidak perlu memutuskan apakah Anda akan membutuhkan kawat gigi atau tidak.

  2. mengurangi hambatan pengembangan: bahkan jika Anda berusaha untuk akhirnya mengekstrak semua baris logika untuk metode, harus mengkonversi gelang jika untuk menguatkan jika untuk menambah logika adalah sedikit hambatan pembangunan yang mengganggu. Jadi ada upaya menghapus kawat gigi, dan upaya menambahkannya lagi ketika Anda membutuhkan lebih banyak kode. Mungil, tapi menyebalkan.


0

Seorang rekan kerja muda mengatakan bahwa kawat gigi yang kita lihat mubazir dan tidak berguna sebenarnya berguna baginya. Saya tidak ingat persis mengapa, tetapi jika memungkinkan dia untuk menulis kode yang lebih baik lebih cepat, itu saja alasan untuk mempertahankannya.

Fwiw, kami sepakat pada kompromi yang menempatkan mereka pada satu baris tidak membuat prasyarat singkat seperti itu tidak dapat dibaca / mengganggu saya. Misalnya

if (!param) { throw invalid_argument (blahblah); }
if (n < 2) { return 0; }
// real code for function starts here...

Saya juga menunjukkan bahwa prasyarat pengantar ini sering merupakan pernyataan aliran kontrol untuk tubuh (misalnya a return) sehingga rasa takut untuk menambahkan pernyataan kedua yang dimaksudkan berada di bawah kondisi yang sama dan lupa untuk menulis kawat gigi sedang diperdebatkan. Pernyataan kedua dalam kondisi ini akan menjadi kode mati dan tidak masuk akal.

Saya menduga bahwa kelancaran dalam masalah membaca disebabkan oleh parser otak seseorang yang ditransfer untuk memiliki kawat gigi sebagai bagian dari pernyataan kondisional. Itu bukan representasi akurat dari tata bahasa C ++, tetapi bisa menjadi efek samping dari belajar bahasa lain tertentu terlebih dahulu, di mana itu terjadi.


1
Paman Bob mungkin berpikir dia menulis kode yang lebih baik lebih cepat tanpa mereka.
djechlin

2
Seperti halnya saya, dan yang lainnya fasih berbahasa C ++.
JDługosz

1
"Jika memungkinkan dia untuk menulis kode yang lebih baik lebih cepat, itu saja adalah alasan untuk menyimpannya" ++ Saya punya Jr yang mengatakan hal yang sama, jadi, kita menyimpannya.
RubberDuck

... dan hanya itulah alasannya untuk melakukannya seperti yang diinginkan Paman Bob.
djechlin

-1

Setelah menonton video itu sekarang, saya perhatikan bahwa menghilangkan kawat gigi membuatnya lebih mudah untuk melihat di mana kode masih perlu di refactored. Jika Anda membutuhkan kawat gigi, kode Anda mungkin bisa sedikit lebih bersih.

Karena itu, ketika Anda berada di tim, menghilangkan kawat gigi mungkin akan menyebabkan perilaku yang tidak terduga suatu hari nanti. Saya katakan menjaga mereka, dan Anda akan menyelamatkan diri Anda dari banyak sakit kepala ketika terjadi kesalahan.


ini sepertinya tidak menawarkan sesuatu yang substansial atas poin-poin yang dibuat dan dijelaskan dalam 10 jawaban sebelumnya
agas

-3

Saya diajari untuk tidak melakukan ini karena membuatnya mudah untuk memperkenalkan bug dengan menambahkan garis indentasi lain yang berpikir bahwa itu dikendalikan oleh if ketika tidak.

Jika kode Anda diuji unit dengan baik , "bug" semacam ini akan meledak di wajah.

Membersihkan kode dengan menghindari tanda kurung yang tidak berguna dan jelek adalah praktik yang saya ikuti.


9
Tentu saja, kebalikannya juga benar: jika kode Anda bebas bug, Anda tidak perlu uji unit apa pun. Kenyataannya adalah bahwa kita hidup di dunia yang tidak sempurna di mana kadang-kadang ada kesalahan dalam kode dan kadang-kadang kesalahan dalam ujian. (Dalam pengalaman saya, yang terakhir sebenarnya lebih umum.) Jadi, sementara tes tentu mengurangi risiko bug, ini bukan alasan untuk menemukan cara lain untuk meningkatkan risiko segera kembali lagi.
ruakh

3
Untuk menambahkan komentar ruakh: tidak mungkin 100% unit menguji kode.
BЈовић

Silakan lihat kode saya;) Saat berlatih TDD, selalu mungkin untuk menunjukkan bug semacam ini dengan sangat cepat.
Mik378

@ Mik378 itu terbukti tidak benar. Intinya adalah, jika Anda menggunakan kawat gigi, Anda bahkan tidak perlu khawatir.
GoatInTheMachine
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.