Pernyataan tunggal jika blok - kawat gigi atau tidak? [Tutup]


59

Mana yang lebih baik / lebih umum diterima?

Ini:

if(condition)
{
  statement;
}

Atau:

if(condition)
  statement;

Saya cenderung lebih suka yang pertama, karena saya pikir itu membuatnya lebih mudah untuk mengetahui apa yang sebenarnya termasuk dalam blok if, itu menyelamatkan orang lain dari menambahkan kawat gigi nanti (atau membuat bug dengan melupakannya), dan itu membuat semua pernyataan if Anda seragam bukan beberapa dengan kawat gigi dan beberapa tanpa. Namun, yang kedua masih benar secara sintaksis dan jelas lebih ringkas. Saya ingin tahu melihat mana yang lebih disukai oleh orang lain.


2
Tetapi Anda memiliki brace pembuka di posisi yang salah. Itu sudah pasti.
Christian Mann

Dalam banyak bahasa, blok adalah pernyataan, karenanya, secara sintaksis, selalu jika pernyataan (ekspresi)
Ingo

2
Karena Anda tidak menentukan bahasa ... Bagaimana statement if condition;?
Dave Sherohman

@Christian - bagus Itu akan menjadi pertanyaan lain yang terpisah dari ini, bukan?
Zannjaminderson

@Ingo - poin bagus.
Zannjaminderson

Jawaban:


131

Yang pertama lebih baik karena yang kedua rawan kesalahan. Misalnya, katakanlah Anda sementara mengomentari kode untuk men-debug sesuatu:

if(condition) 
//      statement;
otherStatement;

Atau menambahkan kode dengan tergesa-gesa:

if(condition) 
    statement;
    otherStatement;

Ini jelas buruk. Di sisi lain, yang pertama kadang terasa terlalu bertele-tele. Karena itu, saya lebih suka meletakkan semuanya pada satu baris jika itu cukup pendek dan sederhana:

if(condition) statement;

Ini mengurangi kebisingan sintaksis sementara membuat konstruksi terlihat seperti itu melakukan apa yang sebenarnya dilakukannya, membuatnya lebih rentan kesalahan. Asalkan sintaks ini hanya digunakan untuk kondisi dan pernyataan yang sangat sederhana, singkat, saya merasa itu dapat dibaca dengan sempurna.


35
Poin bagus tentang meletakkan segala sesuatu dalam satu baris.
Neil Aitken

7
@artjomka: Jika pernyataan panjang, dan harus menggunakan jalurnya sendiri, maka saya menggunakan kawat gigi untuk keterbacaan. Intinya adalah bahwa Anda menginginkan konstruk yang paling pendek, paling tidak berisik, yang tidak ambigu bagi manusia yang membacanya dengan cepat alih-alih meneliti dengan cermat.
dsimcha

15
Saya lebih suka yang dengan kawat gigi karena alasan yang telah disebutkan. Saya tidak suka one-liner, karena tidak segera jelas apa yang terjadi ketika saya melangkahi baris dalam debugger. Saya harus mengambil langkah terpisah untuk melihat kondisi apa yang dievaluasi.
Jim A

10
Ruang kosong @TMN gratis, monitor berukuran besar dan otak Anda belajar mengenali bentuk yang membantu Anda mengurai kode.
Murph

5
@Murph: whitespace gratis? Saya pasti telah melewatkannya. Di layar saya, dibutuhkan banyak ruang. Lebih dari 50% sebenarnya. Yang dalam buku saya sepertinya sangat sia-sia. Secara pribadi, saya ingin memaksimalkan konten per sentimeter persegi dalam kode.
Konrad Rudolph

44

Saya selalu menggunakan tanda kurung hanya untuk aman.

Tidak masalah ketika Anda menulisnya, tetapi Anda tahu seseorang akan datang di masa depan dan memasukkan pernyataan lain tanpa menempatkan tanda kurung di sekitarnya.


20
Apakah orang benar-benar melihat ini terjadi? Saya tidak berpikir saya pernah melihat ini dalam 10 tahun pemrograman. Mungkin aku terlalu terlindung. :)
David

9
Saya ingin mengatakan tidak, tetapi sayangnya saya telah melihatnya.
Neil Aitken

13
Anda selalu menggunakan tanda kurung sehingga Anda tidak pernah lupa untuk menggunakan tanda kurung - sesederhana itu.
Murph

12
+1 ke @Murph. Alasan yang sama saya menggunakan sinyal belok ketika tidak ada orang di sekitar - dan di tempat parkir!
Dan Ray

7
Ini adalah praktik yang baik untuk membantu mencegah kesalahan saat menggabungkan dari cabang ke batang atau lintas cabang.
JBRWilkinson

27

Saya lebih suka versi tanpa kawat gigi jika memungkinkan.

Penjelasan berikut ini agak panjang. Tolong bersamaku. Saya akan memberikan alasan kuat bagi saya untuk memilih gaya ini. Saya juga akan menjelaskan mengapa saya berpikir bahwa argumen bantahan yang biasa tidak berlaku.

(Dekat-) jalur kosong adalah pemborosan

Alasan untuk ini adalah bahwa kurung kurawal memerlukan baris kode tambahan - dan demikian pula kurung kurawal, tergantung gaya. 1

Apakah ini masalah besar? Secara dangkal, tidak. Lagipula, kebanyakan orang juga meletakkan baris kosong dalam kode mereka untuk memisahkan blok yang sedikit independen secara logis, yang sangat meningkatkan keterbacaan.

Namun, saya benci membuang ruang vertikal. Monitor modern sebenarnya memiliki ruang horizontal yang luas. Tetapi ruang vertikal masih sangat, sangat terbatas (kecuali jika Anda menggunakan monitor dengan posisi tegak, yang tidak biasa). Ruang vertikal terbatas ini merupakan masalah: diakui secara luas bahwa metode individual harus sesingkat mungkin, dan bahwa kawat gigi yang sesuai (atau pembatas blok lainnya) tidak boleh lebih dari perbedaan ketinggian layar sehingga Anda dapat melihat seluruh blok tanpa bergulir.

Ini adalah masalah mendasar : sekali Anda tidak bisa melihat seluruh blok lagi di layar, semakin sulit untuk dipahami.

Sebagai akibatnya, saya benci garis kosong yang berlebihan. Di mana satu baris kosong sangat penting untuk membatasi blok independen (lihat saja tampilan visual teks ini), baris kosong berturut - turut adalah gaya yang sangat buruk dalam buku saya (dan menurut pengalaman saya, itu biasanya merupakan pertanda programmer pemula).

Demikian juga, garis yang hanya menahan penyangga, dan yang bisa dihemat, seharusnya. Blok pernyataan tunggal yang dibatasi oleh kawat gigi membuang satu hingga dua baris. Dengan hanya 50 garis ish per tinggi layar, ini terlihat.

Menghilangkan kawat gigi mungkin tidak ada salahnya

Hanya ada satu argumen yang menentang penghapusan kawat gigi: bahwa seseorang nantinya akan menambahkan pernyataan lain ke blok yang dimaksud dan akan lupa untuk menambahkan kawat gigi, sehingga secara tidak sengaja mengubah semantik kode.

Ini memang akan menjadi masalah besar.

Tapi menurut pengalaman saya, tidak. Saya seorang programmer yang ceroboh; namun, dalam dekade pengalaman pemrograman saya, saya dapat dengan jujur ​​mengatakan bahwa saya tidak pernah lupa untuk menambahkan kawat gigi ketika menambahkan pernyataan tambahan ke blok tunggal.

Saya bahkan merasa tidak masuk akal bahwa ini harus menjadi kesalahan umum: blok adalah bagian mendasar dari pemrograman. Resolusi dan pelingkupan tingkat blok adalah proses mental yang mendarah daging secara otomatis bagi para programmer. Otak hanya melakukannya (jika tidak, penalaran tentang pemrograman akan jauh lebih sulit). Tidak ada upaya mental tambahan yang diperlukan untuk mengingat menempatkan kawat gigi: pemrogram juga ingat untuk indentasi pernyataan yang baru ditambahkan dengan benar, setelah semua; jadi programmer telah secara mental memproses blok yang terlibat.

Sekarang, saya tidak mengatakan bahwa menghilangkan kawat gigi tidak menyebabkan kesalahan. Apa yang saya katakan adalah bahwa kita tidak memiliki bukti satu atau lain cara. Kami hanya tidak tahu apakah itu menyebabkan kerusakan.

Jadi sampai seseorang dapat menunjukkan kepada saya data keras, yang dikumpulkan dari eksperimen ilmiah, menunjukkan bahwa ini memang masalah dalam praktiknya, teori ini tetap merupakan " cerita biasa-biasa saja ": hipotesis yang sangat meyakinkan yang belum pernah diuji, dan bahwa harus tidak digunakan sebagai argumen.


1 Masalah ini kadang-kadang diselesaikan dengan meletakkan segala sesuatu - termasuk kawat gigi - pada baris yang sama:

if (condition)
{ do_something(); }

Namun, saya yakin aman untuk mengatakan bahwa kebanyakan orang membenci ini. Lebih jauh lagi, itu akan memiliki masalah yang sama dengan varian tanpa kawat gigi jadi itu yang terburuk dari kedua dunia.


6
Menghilangkan kawat gigi merusak keterbacaan dan dapat dengan mudah menyebabkan masalah ketika kode dimodifikasi.
Josh K

15
@Josh: klaim pertama konyol, karena bahasa seperti Python ditampilkan (buat cadangan dengan bukti jika Anda berpikir sebaliknya). Yang kedua telah dimentahkan dalam jawaban saya. Apakah Anda memiliki bukti untuk mendukungnya? Kalau tidak, komentar Anda adalah indikasi bahwa Anda belum benar-benar membaca teks saya. Silakan lakukan sebelum mengkritiknya.
Konrad Rudolph

8
+1 untuk pemikiran Anda, tetapi saya pikir posisi Anda mengalahkan diri sendiri. Anda mengatakan "tunjukkan data keras kepada saya, yang dikumpulkan dari eksperimen ilmiah, menunjukkan bahwa ini memang masalah dalam praktik" namun jatuh pada pengalaman anekdotal (milik Anda) untuk mempertahankan posisi Anda. Anda berkata, "dalam pengalaman saya ... dalam dekade pengalaman saya ... Saya merasa itu tidak masuk akal ..." dan seterusnya. Bisakah Anda menunjukkan data yang keras, yang dikumpulkan dari percobaan ilmiah, mendukung klaim Anda, "Menghilangkan kawat gigi tidak membahayakan"? Pengalaman pribadi baik-baik saja ketika mendukung pendapat, tetapi jangan meminta lebih banyak "bukti" daripada yang Anda mau berikan.
bedwyr

3
@bedwyr: ada perbedaan kualitatif. Pertama, saya membuatnya jelas bahwa saya benar-benar akan dibujuk oleh data, dan saya membuatnya sama jelasnya bahwa saya hanyalah sebuah hipotesis, tidak didukung oleh data. Kedua, saya telah menyatakan (setidaknya bagi saya) argumen yang masuk akal untuk keyakinan saya bahwa klaim itu salah dan mengapa itu perlu dikuatkan. Yang membawa saya ke ketiga: tanggung jawab di sini adalah pada oposisi untuk membuktikan klaim mereka, bukan pada saya untuk membantahnya. Dan selain masalah masuk akal, saya telah menunjukkan satu argumen faktual yang tidak terkait yang mendukung gaya pengkodean saya.
Konrad Rudolph

4
@ Konrad - python tidak menunjukkan sebaliknya karena lekukan yang signifikan dan karenanya kawat gigi implisit. Programmer yang baik dan cerdas, tipe yang ada di sini, mungkin tidak akan membuat kesalahan sering jika sama sekali (dalam banyak tahun saya mungkin melihat masalah hanya pada beberapa kesempatan) tetapi ada banyak yang kurang bagus programmer di luar sana yang melakukan hal-hal bodoh yang merupakan salah satu alasan mengapa standar pengkodean diperlukan di tempat pertama. (Dan karena tenggat waktu dan stres dapat membuat yang terbaik dari kita menjadi kurang baik.)
Murph

19

Saya pergi dengan yang kedua. Itu lebih ringkas dan kurang bertele-tele.

Saya mencoba untuk tidak menulis ke penyebut umum terendah, jadi saya berharap bahwa pengembang lain tahu bagaimana menulis salah satu struktur aliran kontrol yang paling umum dalam pemrograman saat ini.


11
benar! Lagi pula, jika kodenya sulit untuk ditulis, itu juga akan sulit dipertahankan! ;-)
Steven A. Lowe

3
@ Sebelas Jika Anda lupa kawat gigi, saya pikir ada masalah lain di sini.
TheLQ

lebih banyak succint == less verbose
UncleZeiv

5
@SnOrfus: agak sarkastik, karena 2 karakter tambahan itu sepele dan mencegah kesalahan perawatan yang sangat umum. Mileage Anda Mungkin Bervariasi ;-)
Steven A. Lowe

1
Bagi saya indentasi memperjelas apa yang terjadi. Bentuk pertama membakar ruang layar ekstra dan karenanya negatif bagi saya.
Loren Pechtel

16

Saya akan menggunakan yang berikut (konsensus di sini):

if (condition) {
    any_number_of_statements;
}

Juga mungkin:

if(condition) single_compact_statement;

Tidak begitu baik, terutama dalam bahasa C / C ++ - seperti:

if(condition) 
    single_compact_statement;

(Tidak ada pilihan di sini di Python ;-)


Di Perl , Anda akan menggunakan:

$C = $A**3 if $A != $B;

atau

$C = $A**3 unless $A == $B;

(Ini bukan kodesemu ;-)


1
Pikiranku persis. Jika pernyataan tunggal terlihat bagus pada satu baris setelah ifklausa, saya tidak menggunakan kawat gigi. Untuk ifpernyataan lain (atau pernyataan apa pun yang menggunakan banyak baris), saya selalu menggunakan kawat gigi. Khususnya, jika ada elseklausa, setiap kasing memiliki kawat gigi.
eswald

9
Saya belum pernah melihat seseorang membingungkan perl dengan pseudocode sebelumnya. Karakter acak ya, kodesemu - tidak.
Joe D

3
Saya ingin tahu apakah ada yang membuat generator program Perl hanya dengan menghubungkan / dev / acak ke penerjemah Perl ...
Christian Mann

Saya suka pendekatan ruby ​​di sini. Menawarkan gaya perl baris tunggal <statement> if <condition>atau gaya blok multiline if <condition>/ <do something>/ end(ruby menghindari kawat gigi, jadi di sini kurung pembuka disiratkan oleh ifdan kurung ujung diganti dengan literal end). Itu bahkan tidak menawarkan pernyataan multiline-tapi-benar-hanya-satu-baris jika aneh.
Ben Lee

One-liner tidak bekerja dengan sebagian besar debugger (tidak mungkin memicu jeda ketika konten klausa 'jika' akan dieksekusi).
Peter Mortensen

11

Saya menggunakan metode kawat gigi - untuk semua alasan di atas ditambah satu lagi.

Penggabungan kode. Sudah diketahui terjadi pada proyek yang saya kerjakan pada pernyataan tunggal jika telah rusak oleh penggabungan otomatis. Yang menakutkan adalah lekukan terlihat benar meskipun kodenya salah, jadi bug jenis ini sulit dikenali.

Jadi saya pergi dengan kawat gigi - di jalur mereka sendiri. Lebih mudah menemukan level-level seperti itu. Ya, itu memboroskan real estat layar vertikal dan itu adalah kerugian asli. Namun pada keseimbangan, saya pikir itu sepadan.


10

Tidak ada kawat gigi Jika beberapa programmer lain menambahkan pernyataan kedua ke kode saya, itu bukan kesalahan saya daripada jika saya membiarkan seseorang mengendarai mobil saya dan mereka melewati tebing.


3
Persis! Bukan salah kami, dia tidak tahu sintaksisnya.
kirk.burleson

3
Contoh buruk Yang bagus adalah mobil dengan pedal salah tempat - gas bukan rem. Ini mobil Anda, jadi Anda tidak peduli dengan orang lain. Itu masalah mereka tidak tahu tentang posisi pedal yang unik. Apakah Anda seorang insinyur mobil yang baik dalam hal ini?
yegor256

Ini akan menjadi kesalahan Anda jika Anda memberi mereka mobil Anda tahu mereka mungkin mabuk. Demikian pula kita harus mencoba mengasumsikan sesedikit mungkin tentang pengembang masa depan untuk membantu memudahkan pemeliharaan.
Aram Kocharyan

8

Kami telah memiliki argumen ini lebih dari sekali di sini, dan konsensus keseluruhan adalah untuk selalu menggunakan kawat gigi. Alasan utamanya adalah tentang keterbacaan / pemeliharaan.

Jika Anda perlu menambahkan kode ke ifblok, Anda tidak perlu mengingat / mencari kawat gigi. Ketika programmer masa depan membaca kode, kawat gigi selalu jelas.

Di sisi positifnya, ReSharper akan secara otomatis menambahkan kawat gigi untuk pemrogram malas di Visual Studio, dan saya berasumsi ada tambahan untuk IDE lain yang juga akan melakukannya.


3
Saya pasti tidak membeli klaim keterbacaan. Python adalah salah satu bahasa yang paling mudah dibaca dan tidak perlu pembatas. Klaim itu tidak benar. Saya juga tidak membeli klaim pemeliharaan karena sejauh ini tidak terbukti dan masih berulang kali diulangi. Tetapi dalam kasus ini saya sebenarnya sangat tertarik pada bukti empiris. Ini adalah sesuatu yang bisa dengan mudah diketahui oleh sebuah penelitian, dan diselesaikan sekali dan untuk selamanya.
Konrad Rudolph

Karena Python menggunakan indentasi alih-alih pembatas, mereka implisit bukan pembandingan yang valid.
Murph

@ Konrad - bukti empiris: Ketika saya adalah seorang programmer baru, saya pribadi menambahkan kode ke blok un-bracing tanpa menyadari bahwa programmer sebelumnya tidak peduli dengan kawat gigi. Saya pribadi melihat orang lain melakukan ini dengan mata kepala sendiri. Memang, hanya sekali saya melihat seseorang membutuhkan bantuan untuk menemukan masalah setelah menjalankan kode mereka, tetapi itu lebih berkaitan dengan keterampilan pengujian yang buruk.
shimonyk

@shimonyk: jadi pada dasarnya pengamatan Anda mendukung pernyataan saya bahwa masalah ini tidak penting? Ngomong-ngomong, pengamatan pribadi adalah anekdot, mereka tidak dianggap sebagai bukti empiris.
Konrad Rudolph

@Konrad dengan sangat baik, silakan mengutip sumber Anda juga. Saya menganggap Anda memiliki studi double-blind peer review yang Anda rujuk? Jika tidak, daripada hanya mencemooh anekdot Anda sendiri dalam upaya untuk membuktikan orang lain salah sementara menuntut poster lain merujuk pada 'bukti' paling munafik. Ketika seseorang lebih jauh tentang topik ini menulis "tanggung jawab di sini adalah pada oposisi untuk membuktikan klaim mereka, bukan pada saya untuk membantahnya".
shimonyk

7

Saya menggunakan sintaks pertama, hampir tanpa kecuali. Karena itu tidak bisa disalahartikan .

"Jangan membuatku berpikir" tidak hanya berlaku untuk antarmuka pengguna, kalian semua ;-)


4
Saya dulu melakukan ini, tetapi saya dimenangkan oleh argumen bahwa programmer perlu tahu bahasa dan mereka harus dibuat untuk berpikir.
kirk.burleson

2
Saya menganggap itu milik umum ... untuk masa depan saya sendiri.
Steven A. Lowe

5

Saya pribadi lebih suka yang kedua. Yang pertama terlihat jelek, canggung, dan menyia-nyiakan ruang horisontal. Masalah utama dengan yang kedua adalah makro dan orang-orang memodifikasi kode Anda di kemudian hari salah.

Untuk ini, saya katakan "jangan gunakan makro". Saya juga mengatakan, "indentasikan kode sialan Anda dengan benar". Mempertimbangkan bagaimana setiap editor teks / IDE yang digunakan untuk pemrograman melakukan lekukan secara otomatis, ini seharusnya tidak terlalu sulit untuk dilakukan. Saat menulis kode di Emacs, saya akan menggunakan indentasi otomatis untuk mengidentifikasi jika saya menulis sesuatu yang salah pada baris sebelumnya. Kapan saja Emacs mulai mengacaukan lekukan, saya biasanya tahu saya telah melakukan sesuatu yang salah.

Dalam praktiknya, saya akhirnya mengikuti konvensi pengkodean apa pun yang telah ditetapkan sebelumnya. Tapi ini mengganggu saya (dan membuat saya jauh lebih bahagia ketika saya kode dalam Python dan seluruh bencana braket ini hilang):

if (condition) {
    statement;
} // stupid extra brace looks ugly

Kemudian

if (condition) // the brackets have now just become noise
{ statement; } // also can't see the indentation, harder to read

Meskipun jujur, dua pernyataan dalam pernyataan if mengganggu saya jauh lebih dari satu pernyataan. Sebagian besar karena itu tanda kurung diperlukan dan itu masih terlihat lucu dengan hanya dua pernyataan dalam pernyataan if.


Jika Anda akan menulis makro, Anda harus menulisnya untuk memastikan makro dapat dimasukkan ke bagian mana pun dari kode tanpa melanggar.
Covar

4

Saya menggunakan versi dua baris tanpa kawat gigi (bentuk ke-2), tetapi tidak untuk menghemat ruang.

Saya menggunakan formulir itu karena saya merasa lebih mudah dibaca, lebih menarik secara visual, dan lebih mudah untuk diketik. Saya hanya menggunakan formulir itu jika persyaratan itu dipenuhi; yaitu ifkondisi harus cocok dengan satu baris, dan pernyataan yang sesuai harus cocok dengan baris berikut. Jika bukan itu masalahnya, maka saya akan menggunakan kawat gigi untuk meningkatkan keterbacaan.

Jika saya menggunakan formulir ini, saya memastikan bahwa ada baris kosong (atau baris yang hanya berisi tanda kurung) sebelum dan sesudah ifpernyataan (atau di atas komentar, jika ada). Meskipun ini bukan aturan yang secara sadar saya ikuti, saya perhatikan sekarang setelah membaca pertanyaan ini.

Menghemat ruang layar bukan prioritas bagi saya. Jika saya membutuhkan lebih banyak ruang, saya akan menggunakan monitor yang lebih besar. Layar saya sudah cukup besar bagi saya untuk membaca apa pun yang saya butuhkan untuk memfokuskan perhatian saya. Tidak mungkin saya perlu fokus pada begitu banyak baris kode pada satu waktu sehingga mereka mengambil seluruh layar saya. Jika ada begitu banyak bersarang terjadi dengan sepotong kode yang saya tidak dapat memahaminya tanpa melihatnya lebih banyak pada satu waktu, maka saya harus mempertimbangkan apakah logika dapat lebih baik diwakili oleh refactoring.

Di bawah ini adalah beberapa contoh yang menunjukkan bagaimana saya menggunakan bentuk ifpernyataan ini.

    string GuardConditions(Plan planForWorldDomination)
    {
        if (planForWorldDomination == null)
            throw new ArgumentNullException("planForWorldDomination");

        if (!planForWorldDomination.IsComplete())
            return "Doh!";

        planForWorldDomination.Execute();
    }

    void ProcessingLogic()
    {
        OneBlankLineAbove();

        if (simpleCondition)
            simpleStatement();

        OneBlankLineBelow();
        OneBlankLineAbove();

        // optional comment on the line above an if statement
        if (simpleCondition)
            simpleStatement();

        OneBlankLineBelow();
    }

    void Assignment(string drive)
    {
        OneBlankLineAbove();

        string prompt;
        if (simpleCondition)
            prompt = "simple assignment";
        else
            prompt = null;

        OneBlankLineBelow();
    }

    string Return()
    {
        OneBlankLineAbove();

        if (simpleCondition)
            return "simple return";
        else
            return null;

        OneBlankLineBelow();
    }

3

Kawat gigi. Selalu. Saya agak menyukai mereka, karena memberikan kode konsistensi. Dan juga seperti @dsimcha menulis - lebih sedikit kemungkinan untuk kesalahan dalam menambahkan baris kode tambahan.

"Kejelekan" kawat gigi di sekitar satu baris kode kurang berbahaya daripada pekerjaan tambahan yang mungkin dalam kasus tersebut dengan debugging dan / atau menambahkan kode.


1
Saya belum pernah melihat orang yang membuat kesalahan yang Anda bicarakan.
kirk.burleson

1
Saya baru saja membuatnya kemarin pada seseorang lain sepotong kode. :-) Saya hanya ingin tahu bagaimana hulu akan terlihat, antara lain penambahan kode, menambahkan kawat gigi pada semua nya jika ia benar-benar tampaknya berasal dari sisi yang berbeda dari saya dalam hal ini. :-) (tenang, saya bercanda, diedit hanya apa yang saya harus ...)
Vedran Krivokuća

2

Secara pribadi saya pergi dengan kurung.

Mengapa?

Nah jika ada yang datang dan perlu menambahkan kode ke pernyataan if 100% jelas di mana ruang lingkupnya.

Itu membuat format ifpernyataan konsisten, tidak peduli berapa banyak pernyataan yang ada di blok.

Namun, jika gaya proyek tidak berjalan, patuhi itu.


1

Saya hampir selalu menggunakan tanda kurung hanya untuk berada di sisi yang aman. Namun, kadang-kadang jika isi blok benar-benar pendek saya akan meninggalkannya dan menjadikannya satu-baris seperti:

if (x==5) Console.WriteLine("It's a five!");

Tebak seseorang bukan penggemar keringkasan.
JohnFx

2
Singkatnya agar mudah dibaca? Benar-benar tidak. Ini kode, bukan kontes golf.
Josh K

3
Saya pikir keterbacaan adalah alasan yang bagus untuk singkatnya, secara pribadi. Dalam kasus apa pun: Ruang kosong tidak masuk dalam buku aturan kode-golf saya.
JohnFx

Satu-satunya masalah dengan ini adalah cenderung untuk penyalahgunaan
Conrad Frix

2
Maka jangan menyalahgunakannya. Saya tidak mengatakan menggunakannya sebagai standar pengkodean. Kebetulan ada banyak waktu di mana Anda memiliki persyaratan yang sangat singkat diikuti oleh pernyataan tunggal yang sangat singkat dan ini bekerja dengan baik. Misalnya sebuah if (menegaskan) log.write ("menegaskan gagal");
JohnFx

1

Saya lebih suka kawat gigi untuk konsistensi, tetapi tidak membuang terlalu banyak ruang putih (jadi kode yang lebih mudah diformat dalam bidang pandang saya yang terbatas). Jadi saya menulis ini untuk baris yang cukup pendek:

If (cond) { statement; }

Menarik, saya tidak benar-benar melihat kode seperti ini, tetapi saya agak menyukainya.
Thomas Eding

0

Saya biasanya menggunakan kawat gigi, tetapi ada beberapa kasus di mana saya tidak.

object GetObject() {
    // calculate obj1
    if(obj1 != null)
        return obj1;

    // calculate obj2
    if(obj2 != null)
        return obj2;

    // calculate obj3
    if(obj3 != null)
        return obj3;

    return defaultObj;
}

Bagi saya, konyol jika menambahkannya di sana. Jika seseorang menambahkan pernyataan setelah itu return, kami memiliki masalah yang lebih besar daripada masalah pelingkupan.


Anda dapat dengan mudah menggunakanreturn (obj != null) ? obj : "Error";
Josh K


Dalam hal ini saya akan menggunakan sesuatu seperti Object returnObj = defaultObj; /* Three else-if's to change it to obj1/2/3 */ return returnObj;.
Josh K

@Josh, Baca melalui stackoverflow.com/questions/36707/… . Pertama mengomentari jawaban pertama, "Meskipun memiliki beberapa titik keluar bisa lepas kendali, saya pasti berpikir itu lebih baik daripada meletakkan seluruh fungsi Anda di blok IF ."
Catatan untuk diri sendiri - pikirkan nama

0

Jika IDE memiliki pemformatan kode yang tersedia, saya tidak menggunakan kawat gigi.

Di sisi lain, di mana kode dapat diedit di editor lain yang tidak mendukung pemformatan otomatis, berbahaya untuk tidak memasang kawat gigi seperti yang disebutkan dalam posting lain. Tetapi meskipun demikian saya memilih untuk tidak menggunakan kawat gigi, dan itu tidak menjadi masalah bagi saya.

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.