Apa tujuan dari menggunakan kawat gigi (yaitu {}) untuk satu baris jika atau loop?

Saya membaca beberapa catatan kuliah dosen C ++ saya dan dia menulis yang berikut:

1. Gunakan Indentasi // OK
2. Jangan pernah mengandalkan prioritas operator - Selalu gunakan tanda kurung // OK
3. Selalu gunakan blok {} - bahkan untuk satu baris // tidak OK , kenapa ???
4. Objek Const di sisi kiri perbandingan // OK
5. Gunakan unsigned untuk variabel yang>> 0 // trik yang bagus
6. Setel Pointer ke NULL setelah penghapusan - Proteksi penghapusan ganda // tidak buruk

Teknik ke-3 tidak jelas bagi saya: apa yang akan saya dapatkan dengan menempatkan satu baris dalam { ... }?

Misalnya, ambil kode aneh ini:

int j = 0;
for (int i = 0 ; i < 100 ; ++i)
{
    if (i % 2 == 0)
    {
        j++;
    }
}

dan ganti dengan:

int j = 0;
for (int i = 0 ; i < 100 ; ++i)
    if (i % 2 == 0)
        j++;

Apa manfaat menggunakan versi 1?

Mari kita coba juga memodifikasi iketika kita menambah j:

int j = 0;
for (int i = 0 ; i < 100 ; ++i)
    if (i % 2 == 0)
        j++;
        i++;

Oh tidak! Berasal dari Python, ini terlihat ok, tetapi kenyataannya tidak, karena ini setara dengan:

int j = 0;
for (int i = 0 ; i < 100 ; ++i)
    if (i % 2 == 0)
        j++;
i++;

Tentu saja, ini adalah kesalahan konyol, tetapi yang bahkan bisa dilakukan oleh programmer berpengalaman.

Alasan lain yang sangat bagus ditunjukkan dalam jawaban ta.speot.is .

Yang ketiga yang bisa saya pikirkan adalah bersarang if:

if (cond1)
   if (cond2) 
      doSomething();

Sekarang, anggap Anda sekarang ingin doSomethingElse()ketika cond1tidak terpenuhi (fitur baru). Begitu:

if (cond1)
   if (cond2) 
      doSomething();
else
   doSomethingElse();

yang jelas salah, karena elsebergaul dengan batin if.

Sunting: Karena ini mendapat perhatian, saya akan mengklarifikasi pandangan saya. Pertanyaan yang saya jawab adalah:

Apa manfaat menggunakan versi 1?

Yang telah saya jelaskan. Ada beberapa manfaatnya. Tapi, IMO, aturan "selalu" tidak selalu berlaku. Jadi saya tidak sepenuhnya mendukung

Selalu gunakan blok {} - bahkan untuk satu baris // tidak OK, kenapa ???

Saya tidak mengatakan selalu menggunakan {}blok. Jika itu kondisi & perilaku yang cukup sederhana, jangan. Jika Anda mencurigai seseorang akan datang kemudian & mengubah kode Anda untuk menambah fungsionalitas, lakukan.

Sangat mudah untuk secara tidak sengaja mengubah aliran kontrol dengan komentar jika Anda tidak menggunakan {dan }. Sebagai contoh:

if (condition)
  do_something();
else
  do_something_else();

must_always_do_this();

Jika Anda berkomentar do_something_else()dengan komentar satu baris, Anda akan berakhir dengan ini:

if (condition)
  do_something();
else
  //do_something_else();

must_always_do_this();

Itu mengkompilasi, tetapi must_always_do_this()tidak selalu disebut.

Kami memiliki masalah ini di basis kode kami, tempat seseorang masuk untuk menonaktifkan beberapa fungsi dengan sangat cepat sebelum dirilis. Untungnya kami menangkapnya dalam ulasan kode.

Saya memiliki keraguan terhadap kompetensi dosen. Mempertimbangkan poinnya:

1. baik
2. Adakah yang benar-benar menulis (atau ingin membaca) (b*b) - ((4*a)*c)? Beberapa prioritas sudah jelas (atau seharusnya), dan kurung tambahan hanya menambah kebingungan. (Di sisi lain, Anda _harus_ menggunakan tanda kurung dalam kasus yang kurang jelas, bahkan jika Anda tahu bahwa mereka tidak diperlukan.)
3. Semacam. Ada dua konvensi penyebaran luas untuk memformat kondisional dan loop:

   if (cond) {
       kode;
   }
   

   dan:

   jika (cond)
   {
       kode;
   }
   

   Yang pertama, saya setuju dengannya. Pembukaannya {tidak terlalu terlihat, jadi sebaiknya Anda menganggapnya selalu ada. Namun, pada bagian kedua, saya (dan sebagian besar orang yang bekerja sama dengan saya) tidak memiliki masalah dengan menghilangkan kawat gigi untuk satu pernyataan. (Asalkan, tentu saja, bahwa lekukan itu sistematis dan Anda menggunakan gaya ini secara konsisten. (Dan banyak programmer yang sangat bagus, menulis kode yang sangat mudah dibaca, menghilangkan kawat gigi bahkan ketika memformat cara pertama.)
4. TIDAK . Hal-hal seperti if ( NULL == ptr )itu cukup jelek untuk menghalangi keterbacaan. Tulis perbandingan secara intuitif. (Yang dalam banyak kasus menghasilkan konstanta di sebelah kanan.) 4 Nya adalah nasihat yang buruk; apa pun yang membuat kode itu tidak alami membuatnya kurang mudah dibaca.
5. TIDAK . Apa pun kecuali intdicadangkan untuk kasus khusus. Untuk programmer C dan C ++ yang berpengalaman, gunakan unsignedoperator sinyal bit. C ++ tidak memiliki tipe kardinal nyata (atau tipe subrange efektif lainnya); unsignedtidak berfungsi untuk nilai numerik, karena aturan promosi. Nilai numerik yang tidak memungkinkan operasi aritmatika masuk akal, seperti nomor seri, mungkin bisa terjadi unsigned. Saya membantahnya, karena mengirimkan pesan yang salah: operasi bitwise juga tidak masuk akal. Aturan dasarnya adalah tipe integral adalah int_unless_, ada alasan signifikan untuk menggunakan tipe lain.
6. TIDAK . Melakukan ini secara sistematis menyesatkan, dan sebenarnya tidak melindungi terhadap apa pun. Dalam kode OO yang ketat, delete this;seringkali merupakan kasus yang paling sering (dan Anda tidak dapat mengatur thiske NULL), dan sebaliknya, sebagian deletebesar dalam destruktor, sehingga Anda tidak dapat mengakses pointer nanti. Dan mengaturnya agar NULLtidak melakukan apa-apa tentang pointer lain yang beredar. Mengatur pointer secara sistematis untuk NULLmemberikan rasa aman palsu, dan tidak benar-benar membelikan Anda apa pun.

Lihatlah kode di salah satu referensi umum. Stroustrup melanggar setiap aturan yang Anda berikan kecuali yang pertama, misalnya.

Saya sarankan Anda mencari dosen lain. Orang yang benar-benar tahu apa yang dia bicarakan.

Semua jawaban lain mempertahankan aturan dosen Anda 3.

Izinkan saya mengatakan bahwa saya setuju dengan Anda: aturannya berlebihan dan saya tidak akan menyarankannya. Memang benar bahwa secara teoritis mencegah kesalahan jika Anda selalu menambahkan kurung keriting. Di sisi lain, saya tidak pernah mengalami masalah ini dalam kehidupan nyata : bertentangan dengan apa yang dinyatakan oleh jawaban lain, saya tidak pernah lupa menambahkan tanda kurung keriting begitu diperlukan. Jika Anda menggunakan indentasi yang tepat, segera menjadi jelas bahwa Anda perlu menambahkan kurung keriting sekali lebih dari satu pernyataan yang indentasi.

Jawaban oleh "Komponen 10" sebenarnya menyoroti satu-satunya kasus yang mungkin di mana ini benar-benar dapat menyebabkan kesalahan. Tetapi di sisi lain, mengganti kode melalui ekspresi reguler selalu membutuhkan perhatian besar.

Sekarang mari kita lihat sisi lain dari medali: adakah kerugian untuk selalu menggunakan kurung keriting? Jawaban lain cukup mengabaikan hal ini. Tapi ada adalah kerugian: tidak memakan banyak ruang layar vertikal, dan ini pada gilirannya dapat membuat kode Anda terbaca karena itu berarti Anda harus gulir lebih dari yang diperlukan.

Pertimbangkan fungsi dengan banyak klausa penjaga di awal (dan ya, berikut ini adalah kode C ++ yang buruk tetapi dalam bahasa lain ini akan menjadi situasi yang cukup umum):

void some_method(obj* a, obj* b)
{
    if (a == nullptr)
    {
        throw null_ptr_error("a");
    }
    if (b == nullptr)
    {
        throw null_ptr_error("b");
    }
    if (a == b)
    {
        throw logic_error("Cannot do method on identical objects");
    }
    if (not a->precondition_met())
    {
        throw logic_error("Precondition for a not met");
    }

    a->do_something_with(b);
}

Ini adalah kode yang mengerikan, dan saya sangat berpendapat bahwa yang berikut ini jauh lebih mudah dibaca:

void some_method(obj* a, obj* b)
{
    if (a == nullptr)
        throw null_ptr_error("a");
    if (b == nullptr)
        throw null_ptr_error("b");
    if (a == b)
        throw logic_error("Cannot do method on identical objects");
    if (not a->precondition_met())
        throw logic_error("Precondition for a not met");

    a->do_something_with(b);
}

Demikian pula, loop bersarang pendek manfaat dari menghilangkan kurung keriting:

matrix operator +(matrix const& a, matrix const& b) {
    matrix c(a.w(), a.h());

    for (auto i = 0; i < a.w(); ++i)
        for (auto j = 0; j < a.h(); ++j)
            c(i, j) = a(i, j) + b(i, j);

    return c;
}

Dibandingkan dengan:

matrix operator +(matrix const& a, matrix const& b) {
    matrix c(a.w(), a.h());

    for (auto i = 0; i < a.w(); ++i)
    {
        for (auto j = 0; j < a.h(); ++j)
        {
            c(i, j) = a(i, j) + b(i, j);
        }
    }

    return c;
}

Kode pertama adalah ringkas; kode kedua membengkak.

Dan ya, ini dapat dikurangi sampai batas tertentu dengan menempatkan brace pembuka pada baris sebelumnya. Tapi itu masih kurang dibaca daripada kode tanpa tanda kurung keriting.

Singkatnya: jangan menulis kode yang tidak perlu yang memakan ruang layar.

Basis kode yang saya kerjakan tersebar dengan kode oleh orang-orang dengan keengganan patologis terhadap kawat gigi, dan bagi orang-orang yang datang kemudian, itu benar-benar dapat membuat perbedaan untuk pemeliharaan.

Contoh bermasalah yang paling sering saya temui adalah ini:

if ( really incredibly stupidly massively long statement that exceeds the width of the editor) do_foo;
    this_looks_like_a_then-statement_but_isn't;

Jadi ketika saya datang dan ingin menambahkan pernyataan saat itu, saya dapat dengan mudah berakhir dengan ini jika saya tidak hati-hati:

if ( really incredibly stupidly massively long statement that exceeds the width of the editor) do_foo;
{
    this_looks_like_a_then-statement_but_isn't;
    i_want_this_to_be_a_then-statement_but_it's_not;
}

Mengingat bahwa diperlukan ~ 1 detik untuk menambahkan kawat gigi dan dapat menghemat setidaknya beberapa menit debugging yang membingungkan, mengapa Anda tidak akan menggunakan opsi ambiguitas yang dikurangi? Sepertinya ekonomi palsu bagi saya.

2c saya:

Gunakan Indentasi

Jelas sekali

Jangan pernah mengandalkan prioritas operator - Selalu gunakan tanda kurung

Saya tidak akan menggunakan kata "tidak pernah dan" selalu ", tetapi secara umum saya melihat aturan ini berguna. Dalam beberapa bahasa (Lisp, Smalltalk) ini bukan masalah.

Selalu gunakan blok {} - bahkan untuk satu baris

Saya tidak pernah melakukan itu dan tidak pernah memiliki masalah tunggal, tetapi saya bisa melihat bagaimana itu bisa baik bagi siswa, khususnya. jika mereka mempelajari Python sebelumnya.

Objek Const di sebelah kiri perbandingan

Kondisi yoda? Tidak, kumohon. Itu menyakitkan keterbacaan. Cukup gunakan level peringatan maksimum ketika Anda mengkompilasi kode Anda.

Gunakan unsigned untuk variabel yang>> 0

BAIK. Cukup lucu, saya pernah mendengar Stroustrup tidak setuju.

Setel Pointer ke NULL setelah penghapusan - Proteksi penghapusan ganda

Saran yang buruk! Tidak pernah memiliki pointer yang menunjuk ke objek yang dihapus atau tidak ada.

itu lebih intuitif dan mudah dimengerti. Itu membuat maksudnya jelas.

Dan itu memastikan bahwa kode tidak rusak ketika pengguna baru mungkin secara tidak sadar melewatkannya {, }sambil menambahkan pernyataan kode baru.

Untuk menambah saran yang sangat masuk akal di atas, satu contoh yang saya temui saat refactoring beberapa kode di mana ini menjadi kritis adalah sebagai berikut: Saya mengubah basis kode yang sangat besar untuk beralih dari satu API ke yang lain. API pertama memiliki panggilan untuk menetapkan Id Perusahaan sebagai berikut:

setCompIds( const std::string& compId, const std::string& compSubId );

sedangkan penggantian membutuhkan dua panggilan:

setCompId( const std::string& compId );
setCompSubId( const std::string& compSubId );

Saya mulai mengubah ini menggunakan ekspresi reguler yang sangat sukses. Kami juga melewati kode melalui astyle , yang membuatnya sangat mudah dibaca. Kemudian, sebagian dari proses peninjauan, saya menemukan bahwa dalam beberapa kondisi bersyarat itu mengubah ini:

if ( condition )
   setCompIds( compId, compSubId );

Untuk ini:

if ( condition )
   setCompId( compId );
setCompSubId( compSubId );

yang jelas bukan apa yang dibutuhkan. Saya harus kembali ke awal melakukan ini lagi dengan memperlakukan penggantian sebagai sepenuhnya dalam satu blok dan kemudian secara manual mengubah apa pun yang akhirnya tampak konyol (setidaknya itu tidak akan salah.)

Saya perhatikan bahwa astyle sekarang memiliki opsi --add-bracketsyang memungkinkan Anda untuk menambahkan tanda kurung di mana tidak ada tanda kurung dan saya sangat merekomendasikan ini jika Anda pernah berada di posisi yang sama dengan saya.

Saya menggunakan di {}mana - mana kecuali beberapa kasus yang jelas. Satu baris adalah salah satu kasus:

if(condition) return; // OK

if(condition) // 
   return;    // and this is not a one-liner 

Mungkin menyakitkan Anda ketika Anda menambahkan beberapa metode sebelum kembali. Lekukan menunjukkan bahwa pengembalian sedang dieksekusi ketika kondisi terpenuhi, tetapi itu akan selalu kembali.

Contoh lain dalam C # dengan menggunakan statment

using (D d = new D())  // OK
using (C c = new C(d))
{
    c.UseLimitedResource();
}

yang setara dengan

using (D d = new D())
{
    using (C c = new C(d))
    {
        c.UseLimitedResource();
    }
}

Contoh paling relevan yang dapat saya pikirkan:

if(someCondition)
   if(someOtherCondition)
      DoSomething();
else
   DoSomethingElse();

Dengan yang mana ifakan elsedipasangkan? Lekukan menyiratkan bahwa bagian luar ifmendapatkan else, tetapi itu tidak benar-benar bagaimana kompiler akan melihatnya; bagian dalam if akan mendapatkan bagian luar else, dan bagian luarif tidak. Anda harus tahu itu (atau melihatnya berperilaku seperti itu dalam mode debugging) untuk mencari tahu dengan memeriksa mengapa kode ini mungkin gagal sesuai harapan Anda. Semakin membingungkan jika Anda tahu Python; dalam hal ini Anda tahu bahwa lekukan mendefinisikan blok kode, jadi Anda akan mengharapkannya untuk mengevaluasi sesuai dengan lekukan. C #, bagaimanapun, tidak memberikan flip terbang tentang spasi.

Sekarang, yang mengatakan, saya tidak terlalu setuju dengan aturan "selalu gunakan tanda kurung" di wajahnya. Itu membuat kode sangat vertikal berisik, mengurangi kemampuan untuk membacanya dengan cepat. Jika pernyataannya adalah:

if(someCondition)
   DoSomething();

... maka harus ditulis seperti ini. Pernyataan "selalu menggunakan tanda kurung" terdengar seperti "selalu mengelilingi operasi matematika dengan tanda kurung". Itu akan mengubah pernyataan yang sangat sederhana a * b + c / dmenjadi ((a * b) + (c / d)), memperkenalkan kemungkinan kehilangan orang dekat (kutukan banyak pengkode), dan untuk apa? Urutan operasi dikenal dan ditegakkan dengan baik, sehingga tanda kurung berlebihan. Anda hanya menggunakan tanda kurung untuk menjalankan urutan operasi yang berbeda dari yang biasanya diterapkan: a * (b+c) / dmisalnya. Kawat gigi blok serupa; menggunakannya untuk menentukan apa yang ingin Anda lakukan dalam kasus di mana ia berbeda dari default, dan tidak "jelas" (subyektif, tetapi biasanya cukup masuk akal).

Melihat melalui jawaban tidak ada yang secara eksplisit menyatakan jenis praktik yang saya biasakan, menceritakan kisah kode Anda:

int j = 0;
for (int i = 0 ; i < 100 ; ++i)
{
    if (i % 2 == 0)
    {
        j++;
    }
}

Menjadi:

int j = 0;
for (int i = 0 ; i < 100 ; ++i)
{
    if (i % 2 == 0) j++;
}

Menempatkan j++di baris yang sama dengan jika harus memberi sinyal kepada orang lain, "Saya hanya ingin blok ini terus bertambah j" . Dari coursethis hanya bermanfaat jika garis adalah sebagai sederhana mungkin, karena menempatkan breakpoint di sini, seperti peri menyebutkan, tidak akan menjadi sangat berguna.

Sebenarnya saya baru saja menjalankan bagian dari Twitter Storm API yang memiliki 'semacam' kode ini di java, di sini adalah potongan kode dari kode eksekusi, di halaman 43 dari tayangan slide ini :

...
Integer Count = counts.get(word);
if (Count=null) count=0;
count++
...

Blok loop for memiliki dua hal di dalamnya, jadi saya tidak akan inline kode itu. Yaitu tidak pernah :

int j = 0;
for (int i = 0 ; i < 100 ; ++i) if (i % 2 == 0) j++;

Ini mengerikan dan saya bahkan tidak tahu apakah itu berfungsi (sebagaimana dimaksud); jangan lakukan ini . Baris dan kawat gigi baru membantu membedakan bagian kode yang terpisah tetapi terkait, dengan cara yang sama seperti koma atau semi-kolon dalam prosa. Blok di atas sama buruknya dengan kalimat yang sangat panjang dengan beberapa klausa dan beberapa pernyataan lain yang tidak pernah putus atau jeda untuk membedakan bagian yang terpisah.

Jika Anda benar-benar ingin mengirim telegraf ke orang lain, itu hanya pekerjaan satu jalur saja menggunakan operator atau ?:formulir ternary :

for (int i = 0 ; i < 100 ; ++i) (i%2 ? 0 : >0) j++;

Tapi ini sedang dalam kode-golf, dan saya pikir ini bukan latihan yang bagus (Tidak jelas bagi saya apakah saya harus meletakkan j ++ di satu sisi :atau tidak). NB Saya belum menjalankan operator ternary di C ++ sebelumnya, saya tidak tahu apakah ini berfungsi, tetapi memang ada .

Pendeknya:

Bayangkan bagaimana pembaca Anda (yaitu orang yang mempertahankan kode) menafsirkan cerita Anda (kode) Buat sejelas mungkin bagi mereka. Jika Anda tahu kode pemula / siswa mempertahankan ini, mungkin bahkan meninggalkan sebanyak {}mungkin, supaya mereka tidak bingung.

Karena ketika Anda memiliki dua pernyataan tanpa {}, mudah untuk melewatkan masalah. Anggap kode itu seperti ini.

int error = 0;
enum hash_type hash = SHA256;
struct hash_value *hash_result = hash_allocate();

if ((err = prepare_hash(hash, &hash_result))) != 0)
    goto fail;
if ((err = hash_update(&hash_result, &client_random)) != 0)
    goto fail;
if ((err = hash_update(&hash_result, &server_random)) != 0)
    goto fail;
if ((err = hash_update(&hash_result, &exchange_params)) != 0)
    goto fail;
    goto fail;
if ((err = hash_finish(hash)) != 0)
    goto fail;

error = do_important_stuff_with(hash);

fail:
hash_free(hash);
return error;

Terlihat baik. Masalahnya sangat mudah untuk dilewatkan, terutama ketika fungsi yang mengandung kode jauh lebih besar. Masalahnya adalah yang goto faildijalankan tanpa syarat. Anda dapat dengan mudah membayangkan betapa frustrasinya ini (membuat Anda bertanya mengapa yang terakhir hash_updateselalu gagal, setelah semuanya hash_updateberfungsi dengan baik).

Namun, itu tidak berarti saya menambahkan di {}mana-mana (menurut saya, melihat di {}mana - mana itu mengganggu). Meskipun dapat menyebabkan masalah, itu tidak pernah terjadi pada proyek saya sendiri, karena gaya pengkodean pribadi saya melarang persyaratan tanpa {}ketika mereka tidak berada pada baris yang sama (ya, saya setuju bahwa gaya pengkodean saya tidak konvensional, tapi saya suka, dan saya gunakan gaya kode proyek saat berkontribusi ke proyek lain). Ini membuat kode berikut baik-baik saja.

if (something) goto fail;

Tapi bukan yang berikut.

if (something)
    goto fail;

Itu membuat kode Anda lebih mudah dibaca dengan mendefinisikan dengan jelas ruang lingkup loop dan blok bersyarat Anda. Ini juga menyelamatkan Anda dari kesalahan yang tidak disengaja.

wrt 6: Lebih aman karena menghapus pointer nol adalah larangan. Jadi, jika Anda secara tidak sengaja melewati jalur itu dua kali, Anda tidak akan menyebabkan korupsi memori menjadi membebaskan memori yang bebas atau telah dialokasikan untuk sesuatu yang lain.

Ini adalah sebagian besar masalah dengan objek ruang lingkup file statis dan lajang yang tidak memiliki masa hidup yang sangat jelas dan telah diketahui dapat diciptakan kembali setelah mereka dihancurkan.

Dalam kebanyakan kasus, Anda dapat menghindari kebutuhan ini dengan menggunakan auto_ptrs

Saya suka jawaban Luchian yang diterima, sebenarnya saya belajar dengan cara yang sulit bahwa dia benar, jadi saya selalu menggunakan kawat gigi, bahkan untuk blok baris tunggal. Namun, secara pribadi saya membuat pengecualian saat menulis filter, seperti Anda dalam contoh Anda. Ini:

int j = 0;
for (int i = 0 ; i < 100 ; ++i)
{
    if (i % 2 == 0)
    {
        j++;
    }
}

terlihat berantakan bagiku. Ini memisahkan for for dan pernyataan if menjadi tindakan yang terpisah, ketika maksud Anda sebenarnya adalah tindakan tunggal: untuk menghitung semua bilangan bulat yang dapat dibagi dengan 2. Dalam bahasa yang lebih ekspresif, ini dapat dituliskan seperti:

j = [1..100].filter(_%2 == 0).Count

Dalam bahasa yang tidak memiliki penutupan, filter tidak dapat diekspresikan dalam satu pernyataan, tetapi harus berupa for for diikuti oleh pernyataan if. Namun, itu masih satu tindakan dalam pikiran programmer, dan saya percaya itu harus tercermin dalam kode, seperti:

int j = 0;
for (int i = 0 ; i < 100 ; ++i)
  if (i % 2 == 0)
{
    j++;
}

Salah satu opsi untuk membantu mencegah kesalahan yang telah dijelaskan di atas adalah untuk menjelaskan apa yang Anda inginkan terjadi ketika Anda tidak menggunakan kawat gigi. Itu membuatnya lebih sulit untuk tidak melihat kesalahan ketika Anda mencoba mengubah kode.

if (condition) doSomething();
else doSomethingElse();

if (condition) doSomething();
    doSomething2(); // Looks pretty obviously wrong
else // doSomethingElse(); also looks pretty obviously wrong

Jika Anda seorang kompiler, itu tidak ada bedanya. Keduanya sama.

Tetapi untuk programmer, yang pertama lebih jelas, mudah dibaca dan lebih rentan kesalahan.

Contoh lain dari menambahkan kurung kurawal. Pernah saya mencari bug dan menemukan kode seperti itu:

void SomeSimpleEventHandler()
{
    SomeStatementAtTheBeginningNumber1;
    if (conditionX) SomeRegularStatement;
    SomeStatementAtTheBeginningNumber2;
    SomeStatementAtTheBeginningNumber3;
    if (!SomeConditionIsMet()) return;
    OtherwiseSomeAdditionalStatement1;
    OtherwiseSomeAdditionalStatement2;
    OtherwiseSomeAdditionalStatement3;
}

Jika Anda membaca metode baris demi baris, Anda akan melihat bahwa ada kondisi dalam metode yang kembali jika itu tidak benar. Tetapi sebenarnya ini terlihat seperti 100 penangan event sederhana lainnya yang menetapkan beberapa variabel berdasarkan beberapa kondisi. Dan suatu hari Fast Coder masuk dan menambahkan pernyataan pengaturan variabel tambahan di akhir metode:

{
    ...
    OtherwiseSomeAdditionalStatement3;
    SetAnotherVariableUnconditionnaly;
}

Akibatnya, SetAnotherVariableUnconditionnaly dieksekusi ketika SomeConditionIsMet (), tetapi orang cepat tidak menyadarinya karena semua garis hampir sama ukurannya dan bahkan ketika kondisi pengembaliannya indentasi secara vertikal, itu tidak terlalu terlihat.

Jika pengembalian bersyarat diformat seperti ini:

if (!SomeConditionIsMet())
{
    return;
}

itu jauh terlihat dan Fast Coder akan menemukannya dalam sekejap.

Saya menganggap yang pertama menjadi jelas kemudian kedua. Ini memberi perasaan menutup instruksi, dengan sedikit kode baik-baik saja ketika kode menjadi kompleks {...}banyak membantu bahkan jika itu endifataubegin...end

//first
int j = 0;
for (int i = 0 ; i < 100 ; ++i)
{
    if (i % 2 == 0)
    {
        j++;
    }
}


//second
int j = 0;
for (int i = 0 ; i < 100 ; ++i)
    if (i % 2 == 0)
        j++;
i++;

Yang terbaik adalah mengatur pointer ke NULL ketika Anda selesai menggunakannya.

Berikut ini contohnya:

Kelas A melakukan hal berikut:

1. Mengalokasikan satu blok memori
2. Kemudian beberapa waktu kemudian, ini menghapus blok memori ini tetapi tidak mengatur pointer ke NULL

Kelas B melakukan hal berikut

1. Mengalokasikan memori (dan dalam hal ini terjadi diberikan blok memori yang sama yang telah dihapus oleh kelas A.)

Pada titik ini baik Kelas A dan Kelas B memiliki pointer yang menunjuk ke blok memori yang sama, sejauh Kelas A yang bersangkutan blok memori ini tidak ada karena sudah selesai dengan itu.

Pertimbangkan masalah berikut:

Bagaimana jika ada kesalahan logika di Kelas A yang membuatnya menulis ke memori yang sekarang menjadi milik Kelas B?

Dalam contoh khusus ini, Anda tidak akan mendapatkan kesalahan pengecualian akses yang buruk karena alamat memori legal, sementara itu kelas A sekarang secara efektif merusak data kelas B.

Kelas B pada akhirnya bisa crash jika menemui nilai yang tidak terduga dan ketika itu crash, kemungkinan besar, Anda akan menghabiskan waktu yang cukup lama berburu bug ini di kelas B saat masalahnya ada di kelas A.

Jika Anda telah mengatur pointer memori yang dihapus ke NULL, Anda akan mendapatkan kesalahan pengecualian segera setelah kesalahan logika di Kelas A mencoba menulis ke pointer NULL.

Jika Anda khawatir tentang kesalahan logika dengan penghapusan ganda ketika pointer NULL untuk kedua kalinya, kemudian tambahkan menegaskan untuk ini.

Juga: Jika Anda akan memilih, harap jelaskan.

Selalu memiliki kurung kurawal adalah aturan yang sangat sederhana dan kuat. Namun kode tersebut mungkin terlihat tidak bagus ketika ada banyak kawat gigi. Jika aturan memungkinkan untuk menghilangkan kurung kurawal maka harus ada aturan gaya yang lebih rinci dan alat yang lebih canggih. Kalau tidak, itu dapat dengan mudah mengakibatkan kode kacau dan membingungkan (tidak elegan). Oleh karena itu mencari aturan gaya tunggal yang terpisah dari panduan gaya lainnya dan alat yang digunakan kemungkinan tidak membuahkan hasil. Saya hanya akan membawa beberapa detail penting tentang aturan # 3 yang bahkan belum disebutkan dalam jawaban lain.

Detail menarik pertama adalah bahwa sebagian besar pendukung aturan itu setuju untuk melanggarnya else. Dengan kata lain mereka tidak menuntut kode yang ditinjau:

// pedantic rule #3
if ( command == Eat )
{
    eat();
}
else
{
    if ( command == Sleep )
    {
        sleep();
    }
    else
    {
        if ( command == Drink )
        {
            drink();
        }
        else
        {
            complain_about_unknown_command();
        }
    }
}

Sebaliknya, jika mereka melihatnya mereka bahkan mungkin menyarankan untuk menulisnya seperti itu:

// not fully conforming to rule #3
if ( command == Eat )
{
    eat();
}
else if ( command == Sleep )
{
    sleep();
}
else if ( command == Drink )
{
    drink();
}
else
{
   complain_about_unknown_command();
}

Itu secara teknis melanggar aturan itu karena tidak ada tanda kurung antara elsedan if. Dualitas aturan tersebut muncul ketika mencoba menerapkannya ke basis kode secara otomatis dengan alat yang tidak ada artinya. Memang, mengapa harus berdebat, biarkan saja alat untuk menerapkan gaya secara otomatis.

Detail kedua (yang juga sering dilupakan oleh pendukung aturan itu) adalah bahwa kesalahan yang mungkin terjadi tidak pernah hanya karena pelanggaran aturan # 3 itu. Sebenarnya itu hampir selalu melibatkan pelanggaran aturan # 1 juga (yang tidak ada yang membantah). Sekali lagi dari sudut pandang alat otomatis, tidak sulit untuk membuat alat yang langsung mengeluh ketika aturan # 1 dilanggar dan sebagian besar kesalahan dapat ditangkap tepat waktu.

Detail ketiga (yang sering dilupakan oleh penentang aturan itu) adalah sifat pernyataan kosong yang membingungkan yang diwakili oleh satu titik koma. Sebagian besar pengembang dengan beberapa pengalaman menjadi bingung cepat atau lambat oleh satu titik koma yang salah tempat atau dengan pernyataan kosong yang ditulis menggunakan titik koma tunggal. Dua kawat gigi keriting bukannya titik koma tunggal secara visual lebih mudah dikenali.

Saya harus mengakui bahwa tidak selalu digunakan {}untuk satu baris, tetapi ini adalah praktik yang baik.

• Katakanlah Anda menulis kode tanpa tanda kurung yang terlihat seperti ini:

  untuk (int i = 0; i <100; ++ i) untuk (int j = 0; j <100; ++ j) DoSingleStuff ();

Dan setelah beberapa waktu Anda ingin menambahkan dalam jlingkaran beberapa hal lain dan Anda hanya melakukannya dengan menyelaraskan dan lupa untuk menambahkan tanda kurung.

• Kesepakatan memori lebih cepat. Katakanlah Anda memiliki ruang lingkup besar dan membuat array besar di dalamnya (tanpa newbegitu mereka berada di tumpukan). Array tersebut dikeluarkan dari memori setelah Anda meninggalkan ruang lingkup. Tetapi ada kemungkinan bahwa Anda menggunakan array itu di satu tempat dan akan berada di tumpukan untuk sementara waktu dan menjadi semacam sampah. Karena stack memiliki ukuran terbatas dan sangat kecil, maka dimungkinkan untuk melebihi ukuran stack. Jadi dalam beberapa kasus lebih baik menulis {}untuk mencegah hal itu. CATATAN ini bukan untuk jalur tunggal tetapi untuk situasi seperti ini:

  if (...) {// SomeStuff ... {// kita tidak punya if, while, etc. // SomeOtherStuff} // SomeMoreStuff}

• Cara ketiga untuk menggunakannya mirip dengan yang kedua. Hanya saja tidak membuat stack cleaner tetapi untuk membuka beberapa fungsi. Jika Anda menggunakan mutexfungsi yang panjang biasanya lebih baik mengunci dan membuka kunci sebelum mengakses data dan setelah selesai membaca / menulis itu. CATATAN cara ini digunakan jika Anda memiliki beberapa milik Anda sendiri classatau structdengan constructordan destructoruntuk mengunci memori.

• Apa yang lebih:

  if (...) if (...) SomeStuff (); lain SomeOtherStuff (); // pergi ke yang kedua jika, tetapi alligment menunjukkan itu pada yang pertama ...

Semua Dalam Semua, saya tidak bisa mengatakan, apa cara terbaik untuk selalu menggunakan {}untuk satu baris tetapi tidak ada yang buruk untuk melakukan itu.

EDIT PENTING Jika Anda menulis kompilasi kode kurung untuk satu baris tidak melakukan apa-apa, tetapi jika kode Anda akan ditafsirkan itu memperlambat kode untuk sangat sedikit. Sangat sedikit.

Ada sejumlah cara yang memungkinkan untuk menulis pernyataan kontrol; kombinasi tertentu dari mereka dapat hidup berdampingan tanpa mengganggu keterbacaan, tetapi kombinasi lainnya akan menyebabkan masalah. Gaya

if (condition)
  statement;

akan hidup berdampingan dengan nyaman dengan beberapa cara lain menulis pernyataan kontrol, tetapi tidak begitu baik dengan yang lain. Jika pernyataan yang dikontrol multi-garis ditulis sebagai:

if (condition)
{
  statement;
  statement;
}

maka akan jelas secara visual ifpernyataan mana yang mengendalikan satu baris dan mana yang mengendalikan banyak baris. Namun, jika ifpernyataan multi-baris ditulis sebagai:

if (condition) {
  statement;
  statement;
}

maka kemungkinan seseorang mencoba untuk memperluas ifkonstruksi pernyataan tunggal tanpa menambahkan kawat gigi yang diperlukan mungkin jauh lebih tinggi.

Pernyataan baris-pernyataan-ke-berikutnya ifjuga mungkin bermasalah jika basis kode menggunakan signifikan formulir

if (condition) statement;

Preferensi saya sendiri adalah bahwa memiliki pernyataan pada jalurnya sendiri umumnya meningkatkan keterbacaan kecuali dalam kasus di mana ada banyak ifpernyataan dengan blok kontrol yang sama, misalnya

if (x1 > xmax) x1 = xmax;
if (x1 < xmin) x1 = xmin;
if (x2 > xmax) x2 = xmax;
if (x2 < xmin) x2 = xmin;
etc.

dalam hal ini saya biasanya akan mendahului dan mengikuti kelompok ifpernyataan seperti itu dengan garis kosong untuk memisahkan mereka secara visual dari kode lain. Memiliki serangkaian pernyataan yang semuanya dimulai dengan iflekukan yang sama kemudian akan memberikan indikasi visual yang jelas bahwa ada sesuatu yang tidak biasa.