it-swarm-id.com

Bagaimana Anda menggunakan baris kosong dalam kode Anda?

Ada beberapa komentar tentang ruang putih yang sudah dalam diskusi tentang penempatan kurung kurawal.

Saya sendiri cenderung menaburkan kode saya dengan garis-garis kosong dalam upaya untuk memisahkan hal-hal yang berjalan bersama dalam kelompok "logis" dan mudah-mudahan membuatnya lebih mudah bagi orang berikutnya untuk membaca kode yang baru saja saya buat.

Bahkan, saya akan mengatakan saya menyusun kode saya seperti saya menulis: Saya membuat paragraf, tidak lebih dari beberapa baris (pasti lebih pendek dari 10), dan mencoba membuat setiap paragraf mandiri.

Sebagai contoh:

  • di kelas, saya akan mengelompokkan metode yang berjalan bersama, sambil memisahkannya dengan garis kosong dari grup berikutnya.
  • jika saya perlu menulis komentar saya biasanya akan meletakkan baris kosong sebelum komentar
  • dalam suatu metode, saya membuat satu paragraf per langkah dari proses

Semua dalam semua, saya jarang memiliki lebih dari 4/5 baris berkerumun, yang berarti kode yang sangat jarang.

Saya tidak menganggap semua ruang putih ini sia-sia karena saya benar-benar menggunakannya untuk menyusun kode (karena saya menggunakan indentasi sebenarnya), dan karena itu saya merasa layak dengan layar yang dibutuhkan.

Sebagai contoh:

for (int i = 0; i < 10; ++i)
{
    if (i % 3 == 0) continue;

    array[i] += 2;
}

Saya menganggap bahwa kedua pernyataan tersebut memiliki tujuan yang jelas dan karenanya perlu dipisahkan untuk membuatnya jelas.

Jadi, bagaimana Anda benar-benar menggunakan (atau tidak) baris kosong dalam kode?

31
Matthieu M.

Selalu

Spasi sangat penting untuk membersihkan kode yang dapat dibaca. Baris kosong (atau dua) membantu secara visual memisahkan blok kode logis.

Misalnya, dari Kode Lengkap, Edisi Kedua Steve McConnell bab tentang Tata Letak dan Gaya:

Subjek mendapat skor 20 hingga 30 persen lebih tinggi pada tes pemahaman ketika program memiliki skema indentasi dua hingga empat ruang daripada yang mereka lakukan ketika program tidak memiliki indentasi sama sekali. Studi yang sama menemukan bahwa penting untuk tidak terlalu menekankan atau terlalu menekankan struktur logis program. Skor pemahaman terendah dicapai pada program yang tidak menjorok sama sekali. Yang terendah kedua dicapai pada program yang menggunakan indentasi enam-ruang. Studi ini menyimpulkan bahwa indentasi dua-ke-empat-ruang adalah optimal. Menariknya, banyak subjek dalam percobaan merasa bahwa indentasi enam-ruang lebih mudah digunakan daripada indentasi yang lebih kecil, meskipun skor mereka lebih rendah. Itu mungkin karena enam lekukan ruang terlihat menyenangkan. Tetapi terlepas dari seberapa cantik tampilannya, lekukan enam-ruang ternyata kurang dapat dibaca. Ini adalah contoh tabrakan antara daya tarik dan keterbacaan estetika.

87
Josh K

Ya untuk kejelasan.

Seperti yang saya lakukan dalam jawaban ini.

21
user2567

Saya lakukan tetapi saya memastikan saya mendokumentasikannya dengan meletakkan

(This line intentionally left blank.)

di telepon

13
Don

Ya, tapi saya tidak menyalahgunakannya.

Saya telah melihat kode di mana setiap baris kode di dalam metode dipisahkan oleh baris kosong, dan dua baris kosong digunakan di mana pemisahan logis terjadi. Itu hanya membuatnya lebih mudah dibaca menurut pendapat saya. Saya juga melihat spasi putih digunakan untuk membuat keberpihakan gila, seperti ini:

//Prot.   Return type                    Name                 Arg1        Arg2
//=====   ============================== ==================== =========== ========

private   int                            AMethodWithALongName(string s,   object o)
{
    ...
}

private   IDictionary<MyLongObject, int> SomethingCrazy      (string s)
{
    ...
}

protected void                           Foo                 (string str, object o)
{
    ...
}

Penyalahgunaan spasi horisontal yang sama dapat diterapkan ke spasi putih vertikal. Seperti alat apa pun, gunakan dengan bijak.

12
Allon Guralnek

Saya semua membuat kode sejelas mungkin, dan spasi putih sering merupakan alat yang berguna dalam upaya itu. Tapi jangan lupa refactoring:

  • di kelas, saya akan mengelompokkan metode yang berjalan bersama, sambil memisahkannya dengan garis kosong dari grup berikutnya.

Karena Anda memiliki beberapa anggota terkait, mereka adalah kandidat untuk kelas baru.

  • jika saya perlu menulis komentar saya biasanya akan meletakkan baris kosong sebelum komentar

Setiap kali kode tidak cukup jelas untuk menginginkan komentar, saya bertanya apakah saya bisa menolak untuk membuat kode cukup jelas sehingga tidak perlu komentar.

  • dalam suatu metode, saya membuat satu paragraf per langkah dari proses

Mengapa tidak membuat satu metode untuk setiap "paragraf"?

Jika Anda berakhir dengan banyak metode di kelas Anda, lihat catatan saya di atas tentang mengekstraksi kelas baru.

5
Jay Bazuzi

Iya. Itu membuatnya lebih mudah untuk memindai file secara visual. Di antara hal-hal lain, hal itu membuatnya lebih jelas dengan baris mana komentar berjalan.

Some code here
// Which line does this comment go with?
More code here

// It's pretty clear which line this comment goes with
More code here

Still more code here
5
Nathan Long

Saya banyak dikritik karena menulis kode saya dengan cara ini. Saya tidak mengerti mengapa ada orang yang tidak mau melakukannya dengan cara ini.

Keterbacaan itu sangat penting ketika Anda kembali ke proyek setelah periode waktu yang lama dan saya pernah mendengar pepatah "Selalu tulis kode jika orang berikutnya yang membacanya adalah Psikopat yang mengetahui lokasi Anda".

5

Saya tidak selalu menulis perangkat lunak, tetapi ketika saya melakukannya, saya menggunakan baris kosong untuk kejelasan.

5
Trinidad

Saya menggunakan garis kosong hemat dan konsisten, dan konsisten lebih penting daripada hemat. Namun:

  • Jika setiap baris kode dipisahkan dari yang berikutnya dengan baris kosong, ada terlalu banyak baris kosong.
  • Jika tidak ada sajak atau alasan yang mudah dilihat di mana garis-garis kosong ditempatkan, maka itu adalah pengalih perhatian dan biasanya terlalu banyak.
  • Jika suatu fungsi sangat besar sehingga membutuhkan banyak baris kosong, itu terlalu besar.
  • Jika satu blok kode membutuhkan lebih dari satu baris kosong sebelum atau sesudahnya, ada sesuatu yang sangat tersesat.
  • Jika Anda memiliki lebih dari dua baris kosong antara fungsi, Anda mungkin memiliki terlalu banyak baris kosong.

Sebagian besar tidak kontroversial; mungkin berikut ini. Saya perhatikan bahwa notasi K&R dengan kawat gigi terbuka di ujung jalur sering kali diikuti oleh garis kosong. Saya pribadi tidak suka kawat gigi di ujung garis dan mencampurnya dengan garis kosong setelah kawat gigi membuat omong kosong notasi (IMNSHO). Letakkan brace terbuka di baris berikutnya, dengan sendirinya, dan Anda memiliki sebagian besar baris kosong (dan, IMNSHO, kode lebih mudah dibaca). Jika Anda harus menggunakan penjepit K&R di ujung garis, jangan sia-siakan penghematan ruang vertikal dengan garis-garis kosong yang tidak ada.

// I don't like this
if (something == anotherthing) {
    print ...
    update ...
}

// I much prefer this
if (something == anotherthing)
{
    print ...
    update ...
}

// I loathe this - not least for its inconsistent spacing
if (something == anotherthing) {

    print ...
    update ...
}

// I loathe this too, for its absurd waste of vertical space
if (something == anotherthing) {

    print ...
    update ...

}
4

Tulis apa yang paling mudah dibaca dan paling tidak mengejutkan.

function validEmail($addr) {
    $regex = "/.../";   
    return preg_match($regex, $addr);
}

Fungsi ini tidak memerlukan 12 baris komentar dokumen.

Bahkan, tidak perlu ada komentar.

Atau garis kosong.

Mereka akan mengurangi esensinya.

3
KevBurnsJr

Di dalam fungsinya? Jarang

Jika saya memiliki blok berbeda yang jelas itu adalah refactoring ke fungsi baru. Jika beberapa kasus tidak sepadan.

Bagi saya kosongkan baris di dalam fungsi adalah salah satu "praktik terbaik" yang paling salah.

3
Maniero

Pada suatu waktu, saya akan memercikkan garis kosong secara bebas di seluruh kode saya. Saat ini, saya cenderung lebih hemat. Saya pikir ini adalah bagian dari apa yang dibicarakan Steve Yegge di sini :

Semoga adegan yang saya lukis sejauh ini membantu Anda memahami mengapa kadang-kadang Anda melihat kode dan Anda langsung membencinya. Jika Anda seorang n00b, Anda akan melihat kode yang berpengalaman dan mengatakan itu kode yang tidak dapat ditembus, omong kosong yang ditulis oleh seseorang yang tidak pernah mempelajari esensi dari rekayasa perangkat lunak modern. Jika Anda seorang veteran, Anda akan melihat kode n00b dan mengatakan itu terlalu banyak berkomentar, bulu hiasan yang bisa ditulis seorang pekerja magang dalam satu malam minum-minum.

Titik lengketnya adalah toleransi kompresi. Ketika Anda menulis kode melalui karier Anda, terutama jika kode itu mencakup bahasa dan domain masalah yang sangat berbeda, toleransi Anda terhadap kompresi kode meningkat. Tidak ada bedanya dengan perkembangan dari membaca buku anak-anak dengan teks raksasa menjadi novel yang semakin kompleks dengan teks yang lebih kecil dan kata-kata yang lebih besar.

...

Seorang programmer dengan toleransi tinggi untuk kompresi sebenarnya terhalang oleh banyak cerita. Mengapa? Karena untuk memahami basis kode Anda harus dapat mengemas sebanyak mungkin ke dalam kepala Anda. Jika ini adalah algoritma yang rumit, seorang programmer veteran ingin melihat semuanya di layar, yang berarti mengurangi jumlah baris kosong dan komentar inline - terutama komentar yang hanya mengulangi apa yang dilakukan kode. Ini persis kebalikan dari apa yang diinginkan seorang programmer n00b. n00bs ingin fokus pada satu pernyataan atau ekspresi pada satu waktu, memindahkan semua kode di sekitarnya agar tidak dapat berkonsentrasi, dan menangis dengan suara keras.

Saya pada dasarnya setuju dengannya. Jauh lebih baik untuk mengompres kode sehingga Anda bisa mendapatkan sebanyak mungkin di satu layar daripada terlalu banyak ruang. Itu tidak berarti bahwa Anda seharusnya tidak pernah menggunakan baris kosong. Hanya saja saya pikir kecuali jika pengelompokan yang Anda coba ciptakan tidak meningkatkan keterbacaan secara berlebihan, itu lebih berbahaya daripada baik.

2
Jason Baker

A Profesor Emeritus Memberi Dua Nasihat Besar

  1. Spasi adalah Gratis
  2. Jangan gunakan staples yang mencuat kembali melalui bagian depan kertas, atau aku akan mengecewakanmu.
2
Wonko the Sane

Sering

Gunakan untuk blok kode logis yang diproses sama. Setelah Anda menambahkan komentar untuk menunjukkan bahwa Anda melakukan langkah yang berbeda - saatnya untuk Mengekstrak Metode.

Good Whitespace

{
    int x = computeX();
    x += ADJUSTMENT_FACTOR_X;

    int y = computeY();
    y += ADJUSTMENT_FACTORY_Y;

    setPosition(x, y);
}

Ruang Putih Buruk

{
    //Open a connection
    String serverAddress = lookupAddress();
    Connection connection = openConnection(serverAddress);
    connection.login(user, password);


    //Go get stuff from the server
    item1 = connection.get(1);
    item2 = connection.get(2);

    //Close connection
    connection.close();

    //log data
    log(item1);
    log(item2);

    //Update client
    gui.updateView(item1, item2);        
}    

vs.

{
    Connection connection = openConnection();
    updateData(connection);
    closeConnection(connection);
    logUpdate();
    updateGui();
}

vs.

{
     updateDataFromServer();
     logUpdate();
     updateGui();
}
2
Steve Jackson

Saya tidak hanya menggunakan spasi putih, saya menggunakan kawat gigi untuk kejelasan.

Kawat gigi yang saya gunakan untuk mengatakan ini berpotensi berfungsi.

code
{
    code
    code
    code
    code
}
{
    code
    code=code
    code
    code

    code()
    code()
}
2
user2528

Saya suka memikirkan ruang putih dengan cara yang sama seperti paragraphing. Anda mengelompokkan garis yang berkontribusi pada satu gagasan.

Jika Anda memulai ide baru atau sisi baru dari ide yang sama, Anda memulai paragraf baru - seperti ini.

Dalam kode imperatif, saya mengelompokkan tugas-tugas yang melakukan satu tugas yang kohesif; dalam kode deklaratif, saya mengelompokkan kode-kode yang menggambarkan satu pernyataan yang kohesif dari suatu gagasan.

Anda jelas tidak kesulitan melakukan hal itu dalam bahasa Inggris (beberapa orang sangat buruk dengan paragraphing), jadi dengan sedikit latihan, menerapkan keterampilan yang sama pada kode seharusnya tidak perlu sama sekali.

1
Rei Miyasaka

Garis kosong adalah suatu keharusan menurut saya. Saya menggunakannya untuk memisahkan blok kode logis yang berbeda. Membuat kode dapat dibaca. Kode yang dapat dibaca adalah kode yang baik;)

Sepotong kode ideal saya adalah setiap blok logika dipisahkan oleh baris kosong dan komentar di atas setiap blok yang memiliki logika utama.

Tentu saja, jika orang berlebihan melakukannya dengan menambahkan beberapa baris kosong di mana-mana, saya merasa sangat menjengkelkan :(

1
Karun AB

Saya hanya menggunakan spasi putih dalam fungsi/metode untuk memisahkan deklarasi dan kode.

Jika Anda merasa perlu memiliki beberapa baris untuk memisahkan sub-blok kode yang menerapkan beberapa logika, maka mereka harus menggunakan fungsi/metode pribadi lain. Terserah kompiler Anda untuk tidak membuat overhead yang terlalu besar.

biasanya, dalam peusdo-code:

def function(arg1, argn, ...)
    INITIALIZERS

    CODE
    BLOCK_START
        INITIALIZERS

        CODE
    BLOCK_END
    CODE
end

Jika saya melihat spasi putih yang tidak berguna, saya biasanya merasa ngeri.

1
haylem

Aturan praktis saya adalah ini:

  1. Jika saya kesulitan membaca kode yang saya tulis kemarin, saya mungkin perlu mengekstrak satu atau tiga metode.

  2. Jika definisi kelas saya terlalu panjang untuk dibaca dengan mudah, saya mungkin perlu mengekstrak modul/antarmuka/objek.

  3. Definisi metode: tambahkan baris

  4. Modul/Definisi kelas: tambahkan dua baris

1
philosodad

Iya. Agar mudah dibaca. Kadang-kadang saya bahkan memasukkan baris kosong dalam kode yang tidak saya tulis. Saya merasa lebih mudah untuk memahami kode ketika mereka memiliki pengelompokan logis melalui baris kosong - seperti Anda dapat "membaca cepat" melaluinya.

0
javacruiser

Kita harus menggunakan baris kosong di antara kode kunci seperti yang kita lakukan ketika kita menulis surat.

Misalnya, di antara fungsi, atau di dalam fungsi saat kami menyelesaikan ...

Orang akan berterima kasih pada Anda kode yang bersih jika mereka harus melakukan pemeliharaan;)

0
user7242

Kami menggunakan spasi putih yang direkomendasikan oleh Microsoft StyleCop. Selain keterbacaan dan konsistensi saya telah menemukan bahwa (bersama-sama dengan ukuran kelas kecil) kode yang ditata dengan benar membuatnya lebih mudah untuk mengelola penggabungan ketika berbagai orang dalam tim kebetulan bekerja di area yang sama.

Saya tidak yakin apakah itu hanya imajinasi saya, tetapi alat yang berbeda tampaknya melakukan pekerjaan yang lebih baik untuk mengenali di mana kode yang setara mulai dan selesai ketika menggabungkan ketika ditata dengan rapi. Kode yang ditata dengan baik adalah sukacita untuk digabung. Ok, itu bohong - tapi setidaknya rasa sakit itu disimpan ke tingkat yang dapat dikelola.

0
FinnNk

Ruang putih sangat berharga.

Ini masalahnya ... kutu buku yang menulis kode rumit seperti E = MC2 hebat dalam memamerkan keterampilan pemrograman mereka.

Sekarang mari kita melompat ke depan enam bulan, dan ini jam 2 pagi di pagi hari dan sistem yang belum dilihat dalam enam bulan telah rusak pada baris E = MC2. Ini hampir mustahil untuk di-debug ... semua orang ketakutan.

Misalkan kodenya lebih mirip ini ...

See Dick
See Jane
See Dick and Jan

Jika 2:00 pagi dan kode rusak. Pandangan sekilas akan menunjukkan kepada Anda bahwa saluran ketiga seharusnya

See Dick and Jane

Masalah terpecahkan.

Intinya ... gunakan spasi.

Jangan pernah baris kosong, tidak di seluruh file. Itu tidak berarti tidak ada jeda dalam kode:

 code;
 //
 morecode;

Baris kosong adalah untuk membuka bagian dari kode untuk dikerjakan, Anda memiliki beberapa hotkey di editor Anda untuk membawa Anda ke baris kosong sebelumnya/berikutnya.

0
Mark

Seperti yang telah dinyatakan oleh banyak orang lainnya, baris kosong memudahkan pembacaan kode. Namun, ada beberapa bahasa yang menerapkan standar ini. Salah satu yang bisa saya pikirkan dari atas kepala saya (bukan tentang garis kosong tetapi indentasi yang tepat) adalah Python.

0
Skudd

Saya setuju, saya menggunakan spasi putih dengan cara yang sama. Namun, jika saya menemukan diri saya menggunakan spasi putih untuk memecah metode menjadi terlalu banyak bagian, itu pertanda saya mungkin perlu untuk memperbaiki kode itu menjadi beberapa metode. Terlalu banyak bagian logis dalam suatu metode mungkin menandakan bahwa metode tersebut akan lebih sulit untuk diuji.

0
user7187

Saya menggunakannya untuk memisahkan kode menjadi unit logis. Saya telah melihat sangat sedikit contoh kode yang tidak menggunakan baris kosong, tentu saja kekecewaan dikecualikan.

0
kirk.burleson

Jawaban Psikopat adalah yang terbaik, tetapi saya akan menggantinya dengan mengasumsikan bahwa orang berikutnya adalah idiot, dan mereka akan menganggap diri Anda benar, dan Anda ingin membuktikan bahwa mereka salah.

Sama pentingnya dengan keterbacaan adalah penggunaan komentar. Saya membuka setiap fungsi atau subrutin dengan blok komentar, menjelaskan dalam teks yang jelas, apa itu, apa fungsinya, apa argumennya, dan apa hasil yang diharapkan (termasuk daftar kondisi kesalahan). Maka tidak ada pertanyaan tentang apa yang dimaksudkan dan/atau dirancang untuk dilakukan. Apa yang dicapainya mungkin berbeda-beda, tapi itu jauh di jalurnya.

Saya pikir terlalu banyak coders menganggap bahwa itu akan mereka, diri mereka sendiri yang akan melakukan "perbaikan" pada kode, atau hanya tidak peduli.

0
Peter

Garis kosong itu penting. Namun, membuang seluruh baris kosong pada brace pembuka mengurangi jumlah kode yang dapat Anda lihat di layar penuh. Seharusnya:

for (int i; i < 10; ++i)
{  if (i % 3 == 0) continue;

   array[i] += 2;
}

(Jangan mulai saya menempatkan brace '{' pada baris yang sama dengan 'untuk' ... itu meshuggah).

0
user7195