Bagaimana Anda menggunakan baris kosong dalam kode Anda?


31

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 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?


6
if (i % 3 != 0) { <newline here> array[i] += 2; <newline here> }, tapi saya mengerti maksud Anda :)
Merlyn Morgan-Graham

Jenis pertanyaan yang tidak konstruktif . Hanya ada begitu banyak kali Anda dapat mengulangi hanya dua jawaban yang tersedia yaitu "ya" dan "tidak".

1
Pertanyaan yang lebih baik adalah bagaimana dan mengapa Anda menggunakan baris kosong? Saya menggunakan garis kosong dengan cara yang persis sama seperti yang Anda lakukan, dengan motivasi yang sama.
Dominique McDonnell

1
@ Mark, @takeshin: maaf, lupa "bagaimana" di kata kunci. Sudah jelas kita semua menggunakannya, saya mencoba melihat bagaimana itu digunakan oleh orang-orang di luar sana (memisahkan kelas, jika / selain itu, dll ...) tetapi tampaknya saya mendapat jawaban yang sangat umum: p
Matthieu M.

3
for (int i = 0; i < 10; i += 3) { <newline here> array[i] += 2; <newline here> }tapi saya mengerti maksud Anda :)
Berin Loritsch

Jawaban:


87

Selalu

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

Misalnya, dari Steve McConnell's Code Complete, edisi Kedua bab Tata Letak dan Gaya:

Subjek mendapat skor 20 hingga 30 persen lebih tinggi pada tes pemahaman ketika program memiliki skema lekukan dua hingga empat ruang daripada yang mereka lakukan ketika program tidak memiliki lekukan 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.


12
Saya dapat mendengar seseorang berkata "tetapi kemudian Anda harus Mengekstrak Metode!". Sebuah paragraf adalah ketika tidak ada alasan yang cukup untuk Mengekstrak Metode.
Frank Shearar

1
Sangat mudah untuk bereksperimen dan melihat apakah lebih baik memiliki spasi putih atau tidak. Ambil file sumber yang tidak diketahui untuk Anda, menghapus semua baris kosong, kemudian mencoba untuk mengikuti logika. Bahkan dengan lekukan yang tepat akan mental melelahkan karena baris kosong memberi kita kesempatan untuk melihat hal-hal dalam potongan gigitan-ukuran. Saya harus memelihara beberapa kode yang tidak menggunakan banyak ruang kosong vertikal atau lekukan, jadi menambahkan itu adalah salah satu tugas pertama saya untuk pelestarian diri.
the Tin Man

2
Saya setuju 100%. Whitespace berguna ketika digunakan untuk sengaja membagi kode menjadi potongan-potongan logis. Namun, spasi putih demi spasi putih sama buruknya dengan tanpa spasi putih. Seorang mantan kolega suka meletakkan satu atau lebih baris kosong setelah hampir setiap baris kode aktual. Aku menghabiskan jumlah konyol waktu "refactoring" yang melibatkan memukul Backspace beberapa ribu kali untuk menghapus baris kosong tidak berguna.
Mike Spross

Saya menambahkan beberapa data untuk mendukung posisi Anda. Lihat: meta.programmers.stackexchange.com/questions/1109/...
Jeff Atwood

2
Data itu tidak mengatakan apa-apa tentang garis kosong, hanya tentang lekukan ..
Blorgbeard


13

Saya lakukan tetapi saya memastikan saya mendokumentasikannya dengan meletakkan

(This line intentionally left blank.)

di telepon


1
Garis putih dengan komentar dapat menarik perhatian dari kode
JulioC

1
Itulah banyak komentar yang mengatakan "Baris ini sengaja dikosongkan" ... Tidak bisakah Anda berasumsi bahwa jika suatu baris kosong, itu disengaja atau tidak akan melewati tinjauan kode?
alternatif

43
Mungkin hanya saya, tapi saya berasumsi bahwa OP bercanda ...
JSB

7
Berapa lama Anda bekerja untuk IBM?
Guillaume

12

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 putih horisontal yang sama dapat diterapkan ke spasi putih vertikal. Seperti alat apa pun, gunakan dengan bijak.


1
Sepertinya sesuatu yang akan digunakan dalam perkuliahan tingkat perkuliahan untuk mendorong beberapa konsep. Apakah ini benar-benar digunakan dalam lingkungan profesional?
rjzii

1
@Rob: Ini digunakan dalam kode produksi sistem besar, tetapi tanpa tajuk komentar, dan memiliki badan metode yang cukup besar sehingga penyelarasan membingungkan saya, karena saya tidak bisa melihat tanda tangan metode lain dalam file itu. Ketika saya meruntuhkan tubuh metode, saya bisa melihat "alasan" untuk spasi putih.
Allon Guralnek

Itu mungkin berfungsi dalam file header atau antarmuka
Ming-Tang

Jadi orang yang menulis skema lekukan itu, ketika dia menambahkan metode baru ke kelas, dan metode tipe pengembalian lebih lama daripada jenis pengembalian yang ada, dia akan menabulasi ulang lekukan spasi putih untuk semua metode lain di kelas?
Mike Clark 6-10

@Mike, di sekolah menengah kami menggunakan buku pemrograman Java (tidak dapat mengingat judulnya) yang dengan bijak menyarankan untuk tidak menggunakan spasi horizontal seperti ini, hanya karena pada akhirnya menghabiskan banyak waktu ketika Anda harus melakukan tabulasi ulang seperti itu.
Matthew Flaschen

5

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 jangka waktu yang lama dan saya pernah mendengar pepatah "Selalu tulis kode jika orang berikutnya yang membacanya adalah Psikopat yang mengetahui lokasi Anda".


Asumsi yang Anda buat adalah bahwa dekompresi kode Anda membantu keterbacaan, dan saya tidak berpikir itu selalu diberikan.
Jason Baker

Apa kata Jason. Ketika saya kembali ke basis kode, saya ingin memiliki sebanyak mungkin LOC per layar sehingga saya dapat mencernanya dengan cepat. Jika seseorang meletakkan setengah halaman spasi putih (atau Tuhan melarang salah satu dari komentar gaya xml yang mengerikan), saya akan sangat tergoda untuk memformat ulang sementara waktu hanya untuk membacanya, lalu undobeberapa kali melakukan pekerjaan (memformat perang ini mengarah pada produktivitas, jadi saya tidak akan langsung menghapus komentar dan spasi, tetapi preferensi saya menentangnya sebagian besar).
Inaimathi

Dinding teks hampir mustahil untuk dibaca, apalagi psikologi manusia cenderung menolaknya. Saya pikir meluangkan waktu untuk mengelompokkan pernyataan yang serupa bersama-sama, pengelompokan garis kode yang memanipulasi variabel yang sama juga baik. Saya kira itu semua preferensi, tetapi saya pikir apa pun yang dilakukan dalam bisnis ini tidak boleh dilakukan dengan cepat.
Bryan Harrington

5

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


4
Saya juga sering menulis perangkat keras, lalu mencetaknya. Jauh lebih murah.
Tim Post

5
Lelucon Dos Equis?
Paperjam

@Tim Sebenarnya, ini tidak terlalu lucu: pencetakan 3D ;) (Dan ... menyenangkan, kita tidak semua penutur asli bahasa Inggris di sini :).
takeshin

1
@takeshin Saya tidak mengolok-olok siapa pun, dan saya menyinggung pencetakan 3D. Sementara ya, komentar itu dimaksudkan untuk bercanda, saya pikir Anda mungkin salah menafsirkan maksud :) Juga, fakta bahwa @Paperjam berkomentar tepat di bawah lelucon tentang pencetakan adalah ... well .. tak ternilai :)
Tim Post

Saya tidak menulis perangkat lunak tetapi membuat hardwire.
mlvljr

5

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 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

Iya nih. 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

4

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 dapat dengan 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 ...

}

3

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.


1
Komentar di bagian atas yang menjelaskan alamat apa yang diterima akan menyenangkan. Bisakah ekspresi reguler benar-benar digunakan untuk memvalidasi alamat Email?
kevin cline

3

Di dalam fungsinya? Jarang

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

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


2

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.

Ruang putih yang bagus

{
    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();
}

4
Saya menganggap contoh Bad Whitespace Anda adalah versi singkat dari apa yang harus dianggap buruk. Pada panjangnya saat ini, tampaknya tidak perlu membaginya.
Allon Guralnek

1
saya tidak melihat mengapa buruk itu buruk atau mengapa Anda menulis VS

5
Tidak ada satu pun dari komentar itu yang dibutuhkan, dan mengapa di dunia ini seseorang akan mengekstraksi connection.close() kecloseConnection(connection)
alternatif

Blok kode dengan komentar lebih baik daripada metode yang diekstraksi, asalkan bloknya pendek dan sedikit. Metode ekstraksi tidak gratis; ini memiliki biaya kode lokalitas.
Craig Gidney

Dan Anda hanya membuat item1dan item2variabel global yang berkomunikasi melalui metode? Ya!
TMN

2

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

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 oleh 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 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 sehingga mereka 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 bukan untuk mengatakan bahwa Anda tidak boleh menggunakan garis kosong. Hanya saja saya pikir kecuali jika pengelompokan yang Anda coba ciptakan tidak meningkatkan keterbacaan secara berlebihan, itu lebih berbahaya daripada baik.


2

Seorang 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.

1

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

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

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 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

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

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.


Itu terlihat C-ish, Standar C ++ Coding saya merekomendasikan untuk TIDAK mendeklarasikan objek tanpa menginisialisasi, yang menghalangi penggunaan ini: /
Matthieu M.

@Matthieu M: Oke, lalu ganti DECLARATIONS dengan INITIALIZERS. Tetapi saya tidak pernah ingin melihat INITIALIZERS di tengah blok. Jika perlu, maka itu adalah sesuatu yang membutuhkan ruang lingkup yang lebih kecil, sehingga perlu metode / fungsi pribadi.
haylem

0

Ruang putih sangat berharga.

Begini masalahnya ... kutu buku yang menulis kode rumit seperti E = MC 2 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 = MC 2 . 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 tiga seharusnya

See Dick and Jane

Masalah terpecahkan.

Intinya ... gunakan spasi.


1
Mm ... tidak satu pun dari contoh ini yang mendukung Anda. Secara pribadi, saya pikir E = MC2 lebih mudah dibaca daripada E = MC 2 (intinya adalah menggunakan spasi, kan?). Oh, dan kecuali Anda masih di sekolah menengah, saya yakin Anda bisa menemukan cara yang lebih baik untuk merujuk orang yang tidak Anda setujui daripada "kutu buku".
Jason Baker

@Jason - Poin bagus pilihan kata yang buruk. E = MC2 jauh lebih mudah dibaca, bukan itu yang ingin saya sampaikan. Ini lebih seperti yang Anda bicarakan di situs web Anda YAGNI dan SYNDI. jasonmbaker.com/tag/programming
Michael Riley - AKA Gunny

0

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

Saya setuju, saya menggunakan spasi putih dengan cara yang sama. Namun, jika saya menemukan diri saya menggunakan spasi 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

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


0

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

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).


2
IYA NIH. Saya ingin melihat seluruh fungsi Anda di satu layar. Jangan menaruh kurung kurawal di jalurnya sendiri. Untuk itulah indentasi itu.
KevBurnsJr

Inti dari brace pada barisnya sendiri adalah untuk membersihkan blok kode yang didefinisikan. Menambahkan satu baris kode setelah penyangga merusak satu-satunya alasan mengapa agama ini dipegang! Anda juga bisa meletakkannya di baris yang sama dengan 'untuk'.
Gary Willoughby

0

Iya nih. 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

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

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

Orang-orang akan berterima kasih kepada Anda kode yang bersih jika mereka harus melakukan pemeliharaan;)


0

Kami menggunakan spasi putih yang direkomendasikan oleh Microsoft StyleCop. Selain dari keterbacaan dan konsistensi saya telah menemukan bahwa (bersama 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 dimulai 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

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.

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.