Mengapa pernyataan "jika lain" hampir tidak pernah dalam format tabel?

if   i>0 : return sqrt(i)  
elif i==0: return 0  
else     : return 1j * sqrt(-i)

VS

if i>0:  
   return sqrt(i)  
elif i==0:  
   return 0  
else:  
   return 1j * sqrt(-i)  

Dengan contoh-contoh di atas, saya tidak mengerti mengapa saya hampir tidak pernah melihat gaya pertama dalam basis kode. Bagi saya, Anda mengubah kode menjadi format tabular yang menunjukkan dengan jelas apa yang Anda inginkan. Kolom pertama sebenarnya dapat diabaikan. Kolom kedua mengidentifikasi kondisi dan kolom ketiga memberi Anda output yang Anda inginkan. Tampaknya, setidaknya bagi saya, mudah dan mudah dibaca. Namun saya selalu melihat situasi case / switch sederhana ini muncul dalam format indentasi tab yang diperluas. Mengapa demikian? Apakah orang menemukan format kedua lebih mudah dibaca?

Satu-satunya kasus di mana ini bisa bermasalah adalah jika kode berubah dan semakin lama. Dalam hal ini, saya pikir sangat masuk akal untuk memperbaiki kode ke dalam format yang panjang, berlekuk. Apakah semua orang melakukannya dengan cara kedua hanya karena itu selalu dilakukan? Menjadi pendukung iblis, saya kira alasan lain mungkin karena orang menemukan dua format berbeda tergantung pada kompleksitas pernyataan if / else membingungkan? Wawasan apa pun akan dihargai.

Salah satu alasannya mungkin karena Anda tidak menggunakan bahasa yang populer.

Beberapa contoh tandingan:

Haskell dengan penjaga dan pola:

sign x |  x >  0        =   1
       |  x == 0        =   0
       |  x <  0        =  -1

take  0     _           =  []
take  _     []          =  []
take  n     (x:xs)      =  x : take (n-1) xs

Erlang dengan pola:

insert(X,Set) ->
    case lists:member(X,Set) of
        true  -> Set;
        false -> [X|Set]
    end.

Emacs lisp:

(pcase (get-return-code x)
  (`success       (message "Done!"))
  (`would-block   (message "Sorry, can't do it now"))
  (`read-only     (message "The shmliblick is read-only"))
  (`access-denied (message "You do not have the needed rights"))
  (code           (message "Unknown return code %S" code)))

Secara umum saya melihat format tabel cukup populer dengan bahasa fungsional (dan pada umumnya berbasis ekspresi), sementara memecah baris paling populer di orang lain (kebanyakan berdasarkan pernyataan).

Ini lebih mudah dibaca. Beberapa alasan mengapa:

• Hampir setiap bahasa menggunakan sintaks ini (tidak semua, sebagian besar - contoh Anda tampaknya Python)
• isanae menunjukkan dalam komentar bahwa sebagian besar debuggers berbasis garis (bukan berdasarkan pernyataan)
• Itu mulai terlihat lebih buruk jika Anda harus menyematkan titik koma atau kawat gigi
• Bunyinya dari atas ke bawah lebih lancar
• Itu tampak sangat tidak dapat dibaca jika Anda memiliki apa pun selain pernyataan pengembalian sepele
  • Sintaks yang bermakna indentasi apa pun hilang ketika Anda skim kode sebagai kode kondisional tidak lagi dipisahkan secara visual (dari Dan Neely )
  • Ini akan sangat buruk jika Anda terus menambal / menambahkan item ke dalam pernyataan 1-baris jika
• Ini hanya dapat dibaca jika semua cek Anda memiliki panjang yang sama
• Ini berarti Anda tidak dapat memformat pernyataan yang rumit jika menjadi pernyataan multiline, mereka harus menjadi oneliner
• Saya jauh lebih mungkin untuk melihat bug / aliran logika ketika membaca secara vertikal baris demi baris, tidak mencoba mengurai beberapa baris bersamaan
• Otak kita membaca teks yang lebih sempit dan lebih tinggi JAUH lebih cepat daripada teks horizontal yang panjang

Begitu Anda mencoba melakukan semua ini, Anda akhirnya akan menulis ulang menjadi pernyataan multiline. Yang berarti Anda hanya membuang-buang waktu!

Orang juga pasti menambahkan sesuatu seperti:

if i>0:  
   print('foobar')
   return sqrt(i)  
elif i==0:  
   return 0  
else:  
   return 1j * sqrt(-i)  

Tidak perlu terlalu sering melakukan ini sebelum Anda memutuskan format ini jauh lebih baik daripada alternatif Anda. Ah, tapi kamu bisa inline semuanya dalam satu baris! enderland mati di dalam .

Atau ini:

if   i>0 : return sqrt(i)  
elif i==0 and bar==0: return 0  
else     : return 1j * sqrt(-i)

Yang benar-benar menjengkelkan. Tidak ada yang suka memformat hal-hal seperti ini.

Dan terakhir, Anda akan memulai perang suci masalah "berapa banyak ruang untuk tab". Apa yang merender dengan sempurna di layar Anda sebagai format tabel mungkin tidak dapat diubah sesuai dengan pengaturan saya.

Keterbacaan tidak harus bergantung pada pengaturan IDE.

Saya sangat percaya pada 'kode dibaca berkali-kali, ditulis sedikit - jadi keterbacaan sangat penting.'

Satu hal penting yang membantu saya ketika saya membaca kode orang lain adalah mengikuti pola 'normal' yang dilatih oleh mata saya. Saya dapat membaca bentuk indentasi dengan paling mudah karena saya telah melihatnya berkali-kali sehingga hampir otomatis mendaftar (dengan sedikit upaya kognitif dari saya). Itu bukan karena itu 'lebih cantik' - itu karena itu mengikuti konvensi yang saya terbiasa. Konvensi mengalahkan 'lebih baik' ...

Seiring dengan kelemahan lain yang telah disebutkan, tata letak tabular meningkatkan peluang konflik penggabungan kontrol versi yang membutuhkan intervensi manual.

Ketika satu blok kode yang diubah secara tabel perlu diluruskan kembali, sistem kontrol versi akan memperlakukan setiap baris tersebut sebagai telah dimodifikasi:

diff --git a/foo.rb b/foo.rb
index 40f7833..694d8fe 100644
--- a/foo.rb
+++ b/foo.rb
@@ -1,8 +1,8 @@
 class Foo

   def initialize(options)
-    @cached_metadata = options[:metadata]
-    @logger          = options[:logger]
+    @metadata = options[:metadata]
+    @logger   = options[:logger]
   end

 end

Sekarang anggaplah bahwa dalam waktu yang berarti, di cabang lain, seorang programmer telah menambahkan baris baru ke blok kode yang disejajarkan:

diff --git a/foo.rb b/foo.rb
index 40f7833..86648cb 100644
--- a/foo.rb
+++ b/foo.rb
@@ -3,6 +3,7 @@ class Foo
   def initialize(options)
     @cached_metadata = options[:metadata]
     @logger          = options[:logger]
+    @kittens         = options[:kittens]
   end

 end

Menggabungkan cabang itu akan gagal:

wayne@mercury:/tmp/foo$ git merge add_kittens
Auto-merging foo.rb
CONFLICT (content): Merge conflict in foo.rb
Automatic merge failed; fix conflicts and then commit the result.

Jika kode yang dimodifikasi tidak menggunakan perataan tabular, gabungan akan berhasil secara otomatis.

(Jawaban ini "dijiplak" dari artikel saya sendiri yang mengecilkan kelurusan tabel dalam kode).

Format tabel bisa sangat bagus jika semuanya selalu sesuai dengan lebar yang diberikan. Namun, jika sesuatu melebihi lebar yang diberikan, maka sering perlu untuk memiliki bagian dari tabel yang tidak dijajari dengan sisanya, atau menyesuaikan tata letak semua hal lain di meja agar sesuai dengan barang yang panjang. .

Jika file sumber diedit menggunakan program yang dirancang untuk bekerja dengan data format tabular dan dapat menangani item yang terlalu panjang dengan menggunakan ukuran font yang lebih kecil, membaginya menjadi dua baris dalam sel yang sama, dll. Maka mungkin masuk akal untuk menggunakan tabel format lebih sering, tetapi kebanyakan kompiler menginginkan file sumber yang bebas dari jenis markup yang perlu disimpan oleh editor tersebut untuk mempertahankan format. Menggunakan baris dengan jumlah indentasi yang bervariasi tetapi tidak ada tata letak lain yang tidak sebaik format tabel dalam kasus terbaik, tetapi tidak menyebabkan masalah yang hampir sama banyak dalam kasus terburuk.

Ada pernyataan 'beralih' yang menyediakan hal semacam ini untuk kasus-kasus khusus, tapi saya kira bukan itu yang Anda tanyakan.

Saya telah melihat jika pernyataan dalam format tabel, tetapi harus ada sejumlah besar persyaratan untuk membuatnya berharga. 3 jika pernyataan paling baik ditampilkan dalam format tradisional, tetapi jika Anda memiliki 20, maka jauh lebih mudah untuk menampilkannya dalam blok besar yang diformat untuk membuatnya lebih jelas.

Dan ada intinya: kejelasan. Jika membuatnya lebih mudah untuk dilihat (dan contoh pertama Anda tidak mudah untuk melihat di mana: pembatas) maka format itu sesuai dengan situasi. Kalau tidak, tetap dengan apa yang orang harapkan, karena itu selalu lebih mudah untuk dikenali.

Jika ekspresi Anda benar-benar semudah itu, kebanyakan bahasa pemrograman menawarkan?: Branching operator:

return  ( i > 0  ) ? sqrt( i)
      : ( i == 0 ) ? 0
        /* else */ : 1j * sqrt( -i )

Ini adalah format tabel pendek yang dapat dibaca. Tetapi bagian yang penting adalah: Saya melihat sekilas apa tindakan "utama" itu. Ini adalah pernyataan pengembalian! Dan nilainya ditentukan oleh kondisi tertentu.

Jika di sisi lain Anda memiliki cabang yang mengeksekusi kode yang berbeda, saya merasa jauh lebih mudah dibaca untuk indentasi blok ini. Karena sekarang ada berbagai tindakan "besar" tergantung pada pernyataan if. Dalam satu kasus kita melempar, dalam satu kasus kita masuk dan kembali atau hanya kembali. Ada aliran program yang berbeda tergantung pada logika, sehingga blok kode merangkum cabang-cabang yang berbeda dan membuatnya lebih menonjol bagi pengembang (mis. Fungsi membaca cepat untuk memahami aliran program)

if ( i > 0 )
{
    throw new InvalidInputException(...);
}
else if ( i == 0 )
{
    return 0;
}
else
{
    log( "Calculating sqrt" );
    return sqrt( -i );
}

Seperti yang sudah dikatakan enderland, Anda berasumsi bahwa Anda hanya akan memiliki satu "kembali" sebagai tindakan, dan bahwa Anda dapat menandai "kembali" itu di akhir kondisi. Saya ingin memberikan beberapa detail tambahan mengapa ini tidak akan berhasil.

Saya tidak tahu apa bahasa pilihan Anda, tapi saya sudah lama mengkode dalam bahasa C. Ada sejumlah standar pengkodean di sekitar yang bertujuan untuk menghindari beberapa kesalahan pengkodean standar dengan melarang konstruksi kode yang rentan terhadap kesalahan, baik dalam pengkodean awal atau selama pemeliharaan kemudian. Saya paling akrab dengan MISRA-C, tetapi ada yang lain, dan umumnya mereka semua memiliki aturan yang sama karena mereka menangani masalah yang sama dalam bahasa yang sama.

Satu kesalahan populer yang sering ditangani oleh standar pengkodean adalah gotcha kecil ini: -

if (x == 10)
    do_something();
    do_something_else();

Ini tidak melakukan apa yang Anda pikirkan. Sejauh menyangkut C, jika x adalah 10 maka Anda menelepon do_something(), tetapi kemudian do_something_else()dipanggil terlepas dari nilai x . Hanya tindakan yang segera mengikuti pernyataan "jika" yang bersyarat. Ini mungkin apa yang dimaksudkan oleh pembuat kode, dalam hal ini ada kemungkinan jebakan bagi pengelola; atau mungkin bukan yang dimaksud oleh pembuat kode, dalam hal ini ada bug. Ini pertanyaan wawancara populer.

Solusi dalam standar pengkodean adalah untuk mengamanatkan kawat gigi di sekitar semua tindakan bersyarat, bahkan jika mereka satu baris. Sekarang kita dapatkan

if (x == 10)
{
    do_something();
    do_something_else();
}

atau

if (x == 10)
{
    do_something();
}
do_something_else();

dan sekarang ini berfungsi dengan benar dan jelas untuk pengelola.

Anda akan melihat bahwa ini sepenuhnya tidak kompatibel dengan format gaya tabel Anda.

Beberapa bahasa lain (misalnya Python) melihat masalah ini dan memutuskan bahwa karena coders menggunakan spasi putih untuk membuat tata letak menjadi jelas, itu akan menjadi ide yang baik untuk menggunakan spasi putih alih-alih kawat gigi. Jadi dengan Python,

if x == 10:
    do_something()
    do_something_else()

membuat panggilan ke keduanya do_something()dan do_something_else()tergantung pada x == 10, sedangkan

if x == 10:
    do_something()
do_something_else()

berarti hanya do_something()kondisional pada x, dan do_something_else()selalu dipanggil.

Ini adalah konsep yang valid, dan Anda akan menemukan beberapa bahasa menggunakannya. (Saya pertama kali melihatnya di Occam2, jauh ketika.) Sekali lagi, Anda dapat dengan mudah melihat bahwa format gaya tabel Anda tidak kompatibel dengan bahasa.

Tata letak tabel dapat berguna dalam beberapa kasus terbatas, tetapi ada beberapa kali berguna jika.

Dalam kasus sederhana?: Mungkin merupakan pilihan yang lebih baik. Dalam kasus sedang, sakelar seringkali lebih cocok (jika bahasa Anda memilikinya). Dalam kasus rumit, Anda mungkin menemukan bahwa tabel panggilan lebih cocok.

Ada banyak kali ketika kode refactoring yang saya atur ulang menjadi tabular untuk membuatnya jelas. Jarang sekali saya membiarkannya seperti itu karena dalam kebanyakan kasus ada cara yang lebih baik untuk menyelesaikan masalah begitu Anda memahaminya. Kadang-kadang praktik pengkodean atau standar tata letak melarangnya, dalam hal ini komentar berguna.

Ada beberapa pertanyaan tentang ?:. Ya itu adalah operator ternary (atau yang saya suka anggap sebagai nilai jika). pada blush on pertama contoh ini sedikit rumit untuk?: (dan berlebihan?: tidak membantu keterbacaan tetapi menyakitkan), tetapi dengan beberapa pemikiran Contohnya dapat diatur ulang seperti di bawah ini, Tapi saya pikir dalam hal ini saklar adalah yang paling mudah dibaca larutan.

if i==0: return 0
return i>0?sqrt(i):(1j*sqrt(-i))

Saya tidak melihat ada yang salah dengan format tabel. Preferensi pribadi, tetapi saya akan menggunakan ternary seperti ini:

return i>0  ? sqrt(i)       :
       i==0 ? 0             :
              1j * sqrt(-i)

Tidak perlu diulang returnsetiap kali :)