ทำไมคำว่า“ if elif else” แทบไม่เคยอยู่ในรูปแบบตารางเลย?

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)  

จากตัวอย่างข้างต้นฉันไม่เข้าใจว่าทำไมฉันถึงไม่เคยเห็นสไตล์แรกในฐานรหัส สำหรับฉันคุณเปลี่ยนรหัสเป็นรูปแบบตารางที่แสดงสิ่งที่คุณต้องการอย่างชัดเจน คอลัมน์แรกสามารถถูกละเว้นได้อย่างแท้จริง คอลัมน์ที่สองระบุเงื่อนไขและคอลัมน์ที่สามให้ผลลัพธ์ที่คุณต้องการ อย่างน้อยก็ตรงไปตรงมาและอ่านง่าย แต่ฉันก็มักจะเห็นสถานการณ์กรณี / สวิตช์แบบง่าย ๆ นี้ออกมาในรูปแบบที่เพิ่มการเยื้องของแท็บ ทำไมถึงเป็นอย่างนั้น? ผู้คนพบรูปแบบที่สองที่สามารถอ่านได้มากขึ้นหรือไม่

กรณีเดียวที่ปัญหานี้อาจเกิดขึ้นได้ก็ต่อเมื่อรหัสเปลี่ยนไป ในกรณีนี้ฉันคิดว่ามันเหมาะสมอย่างยิ่งที่จะทำการปรับรหัสให้อยู่ในรูปแบบที่ยาวและเยื้อง ทุกคนทำวิธีที่สองเพียงเพราะวิธีที่เคยทำมาเสมอหรือไม่ การเป็นผู้สนับสนุนของปีศาจฉันคิดว่าอีกเหตุผลหนึ่งอาจเป็นเพราะผู้คนพบสองรูปแบบที่แตกต่างกันขึ้นอยู่กับความซับซ้อนของคำสั่ง if / else ที่ทำให้สับสน? ความเข้าใจใด ๆ ที่จะได้รับการชื่นชม

เหตุผลหนึ่งอาจเป็นเพราะคุณไม่ได้ใช้ภาษาที่เป็นที่นิยม

ตัวอย่างเคาน์เตอร์สองสาม:

Haskell พร้อมการ์ดและลวดลาย:

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

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

Erlang ด้วยรูปแบบ:

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

โดยทั่วไปฉันเห็นว่ารูปแบบตารางค่อนข้างเป็นที่นิยมในภาษาที่ใช้งานได้ (และโดยทั่วไปจะเป็นนิพจน์ทั่วไป) ในขณะที่การแบ่งบรรทัดนั้นเป็นที่นิยมมากที่สุดในคนอื่น ๆ

มันอ่านง่ายขึ้น เหตุผลสองสามประการ:

• เกือบทุกภาษาใช้ไวยากรณ์นี้ (ไม่ใช่ทั้งหมดส่วนใหญ่ - ตัวอย่างของคุณดูเหมือนจะเป็น Python)
• isanae ชี้ให้เห็นในความคิดเห็นที่ debuggers ส่วนใหญ่เป็นบรรทัด (ไม่ใช่คำสั่งตาม)
• มันเริ่มดูน่าเกลียดมากขึ้นถ้าคุณต้องใส่เครื่องหมายอัฒภาคหรือวงเล็บปีกกา
• มันอ่านจากบนลงล่างได้อย่างราบรื่นมากขึ้น
• ดูเหมือนว่าอ่านไม่ได้อย่างน่ากลัวถ้าคุณมีสิ่งอื่นนอกเหนือจากแถลงการณ์ผลตอบแทนเล็กน้อย
  • ไวยากรณ์ที่มีความหมายเยื้องใด ๆ จะหายไปเมื่อคุณอ่านสกิมโค้ดเนื่องจากโค้ดที่มีเงื่อนไขจะไม่ถูกแยกด้วยสายตา (จากDan Neely )
  • สิ่งนี้จะไม่ดีเป็นพิเศษหากคุณยังคงแก้ไข / เพิ่มรายการลงใน 1 บรรทัดหากมีคำสั่ง
• สามารถอ่านได้ก็ต่อเมื่อเช็คทั้งหมดของคุณมีความยาวเท่ากัน
• หมายความว่าคุณไม่สามารถจัดรูปแบบที่ซับซ้อนได้ถ้าข้อความเป็นข้อความหลายข้อความพวกเขาจะต้องเป็นผู้แจ้งเตือน
• ฉันมีแนวโน้มที่จะสังเกตเห็นข้อบกพร่อง / ลอจิกเมื่ออ่านแนวตั้งทีละบรรทัดไม่พยายามแยกคำหลายบรรทัดด้วยกัน
• สมองของเราอ่านข้อความที่แคบและสูงกว่าเร็วกว่าข้อความแนวนอน

นาทีที่คุณพยายามทำสิ่งนี้คุณจะต้องเขียนมันใหม่ลงในคำสั่งหลายบรรทัด ซึ่งหมายความว่าคุณเพิ่งเสียเวลา!

นอกจากนี้ผู้คนเพิ่มสิ่งที่ชอบ:

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

การทำสิ่งนี้ไม่บ่อยนักก่อนที่คุณจะตัดสินใจว่ารูปแบบนี้ดีกว่าตัวเลือกของคุณมาก อ้า แต่คุณสามารถอินไลน์ได้ทั้งหมดในบรรทัดเดียว! enderland ตายในภายใน

หรือสิ่งนี้:

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

ซึ่งมันน่ารำคาญจริงๆ ไม่มีใครชอบการจัดรูปแบบสิ่งนี้

และสุดท้ายคุณจะเริ่มสงครามศักดิ์สิทธิ์ของปัญหา "จำนวนแท็บสำหรับแท็บ" สิ่งที่แสดงอย่างสมบูรณ์แบบบนหน้าจอของคุณในฐานะรูปแบบตารางอาจไม่สามารถแสดงผลได้ตามการตั้งค่า

การอ่านไม่ควรขึ้นอยู่กับการตั้งค่า IDE อย่างไรก็ตาม

ฉันเป็นผู้เชื่อมั่นใน 'โค้ดอ่านหลายครั้งเขียนไม่กี่ - ดังนั้นการอ่านเป็นสิ่งสำคัญมาก'

สิ่งสำคัญที่ช่วยฉันเมื่อฉันอ่านรหัสของคนอื่นก็คือตามรูปแบบ 'ปกติ' ที่ดวงตาของฉันได้รับการฝึกฝนให้รู้จัก ฉันสามารถอ่านรูปแบบการเยื้องได้ง่ายที่สุดเพราะฉันเห็นมาหลายครั้งแล้วว่าการลงทะเบียนเกือบจะอัตโนมัติ (ด้วยความพยายามทางปัญญาเล็กน้อยในส่วนของฉัน) ไม่ใช่เพราะมัน 'สวยกว่า' - เป็นเพราะมันเป็นไปตามอนุสัญญาที่ฉันคุ้นเคย การประชุม 'ดีกว่า' ...

นอกเหนือจากข้อเสียอื่น ๆ ที่กล่าวถึงแล้วเค้าโครงแบบตารางจะเพิ่มโอกาสของความขัดแย้งในการควบคุมเวอร์ชันที่ต้องการการแทรกแซงด้วยตนเอง

เมื่อบล็อกของโค้ดที่มีการจัดเรียงแบบ tabularly จำเป็นต้องถูกจัดแนวใหม่ระบบควบคุมเวอร์ชันจะปฏิบัติต่อแต่ละบรรทัดเหล่านั้นตามที่ได้ถูกแก้ไข:

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

ตอนนี้สมมติว่าในเวลาเฉลี่ยในสาขาอื่นโปรแกรมเมอร์ได้เพิ่มบรรทัดใหม่ในบล็อกของรหัสที่จัดตำแหน่ง:

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

การรวมสาขานั้นจะล้มเหลว:

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.

หากรหัสที่กำลังแก้ไขไม่ได้ใช้การจัดตำแหน่งแบบตารางการผสานจะสำเร็จโดยอัตโนมัติ

(คำตอบนี้คือ "คัดลอกผลงาน" จากบทความของฉันเองที่ทำให้การจัดแนวแบบตารางไม่เป็นระเบียบในโค้ด)

รูปแบบตารางสามารถทำได้ดีมากหากสิ่งต่าง ๆ อยู่ในความกว้างที่กำหนดไว้เสมอ หากมีบางสิ่งที่เกินความกว้างที่กำหนดมันก็มักจะจำเป็นต้องมีส่วนหนึ่งของตารางที่ไม่เรียงกับส่วนที่เหลือหรือปรับรูปแบบของทุกอย่างในตารางให้พอดีกับรายการที่มีความยาว .

หากไฟล์ต้นฉบับถูกแก้ไขโดยใช้โปรแกรมที่ออกแบบมาเพื่อทำงานกับข้อมูลรูปแบบตารางและสามารถจัดการกับรายการที่ยาวเกินไปโดยใช้ขนาดตัวอักษรขนาดเล็กให้แยกไฟล์เหล่านั้นออกเป็นสองบรรทัดภายในเซลล์เดียวกันและอื่น ๆ รูปแบบบ่อยขึ้น แต่คอมไพเลอร์ส่วนใหญ่ต้องการไฟล์ต้นฉบับที่ไม่มีมาร์กอัปชนิดที่ผู้แก้ไขดังกล่าวจะต้องจัดเก็บเพื่อรักษารูปแบบ การใช้บรรทัดที่มีจำนวนตัวแปรเยื้อง แต่ไม่มีเลย์เอาต์อื่น ๆ ไม่ดีเท่ากับการจัดรูปแบบตารางในกรณีที่ดีที่สุด แต่ก็ไม่ได้ทำให้เกิดปัญหาเกือบเท่าในกรณีที่เลวร้ายที่สุด

มีคำสั่ง 'สวิตช์' ที่ให้สิ่งประเภทนี้สำหรับกรณีพิเศษ แต่ฉันคิดว่านั่นไม่ใช่สิ่งที่คุณกำลังถาม

ฉันเคยเห็นว่าข้อความในรูปแบบตาราง แต่จะต้องมีเงื่อนไขจำนวนมากเพื่อให้คุ้มค่า 3 ถ้าข้อความแสดงได้ดีที่สุดในรูปแบบดั้งเดิม แต่ถ้าคุณมี 20 แสดงว่าง่ายกว่ามากในบล็อกขนาดใหญ่ที่จัดรูปแบบเพื่อให้ชัดเจนยิ่งขึ้น

และมีประเด็น: ความชัดเจน หากทำให้ง่ายต่อการมองเห็น (และตัวอย่างแรกของคุณไม่ใช่เรื่องง่ายที่จะดูว่าตัวคั่นคืออะไร) จากนั้นจัดรูปแบบให้เหมาะกับสถานการณ์ มิฉะนั้นยึดติดกับสิ่งที่ผู้คนคาดหวังเพราะง่ายต่อการจดจำ

หากการแสดงออกของคุณเป็นเรื่องง่ายภาษาการเขียนโปรแกรมส่วนใหญ่มีตัวดำเนินการย่อย:

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

นี่เป็นรูปแบบตารางแบบย่อที่สามารถอ่านได้ แต่ส่วนสำคัญคือ: ฉันเห็นภาพรวมของการกระทำ "สำคัญ" นี่คือข้อความสั่งคืนสินค้า! และค่าจะตัดสินใจโดยเงื่อนไขบางอย่าง

หากในอีกทางหนึ่งคุณมีสาขาที่รันโค้ดต่างกันฉันคิดว่ามันสามารถอ่านได้มากขึ้นเพื่อเยื้องบล็อกเหล่านี้ เพราะตอนนี้มีการกระทำ "หลัก" ที่แตกต่างกันขึ้นอยู่กับคำสั่ง if ในกรณีที่เราโยนในกรณีหนึ่งที่เราเข้าสู่ระบบและกลับมาหรือเพียงแค่กลับ มีการไหลเวียนของโปรแกรมที่แตกต่างกันขึ้นอยู่กับตรรกะดังนั้นบล็อคโค้ดทำให้แค็ปซูลแตกต่างกันและทำให้พวกเขาโดดเด่นมากขึ้นสำหรับนักพัฒนา (เช่นฟังก์ชั่นการอ่านความเร็วเพื่อจับโฟลว์ของโปรแกรม)

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

ตามที่ enderland ได้พูดไปแล้วคุณกำลังสมมติว่าคุณมี "ผลตอบแทน" หนึ่งครั้งเป็นการกระทำและคุณสามารถติดแท็ก "คืนค่า" นั้นไปยังจุดสิ้นสุดของเงื่อนไข ฉันต้องการให้รายละเอียดเพิ่มเติมว่าทำไมสิ่งนี้จึงไม่ประสบความสำเร็จ

ฉันไม่รู้ว่าภาษาที่คุณชอบคืออะไร แต่ฉันเขียนโค้ดเป็นภาษา C มานานแล้ว มีมาตรฐานการเข้ารหัสจำนวนมากที่มีจุดมุ่งหมายเพื่อหลีกเลี่ยงข้อผิดพลาดการเข้ารหัสมาตรฐานโดยไม่อนุญาตการสร้างรหัสที่มีแนวโน้มที่จะเกิดข้อผิดพลาดไม่ว่าจะเป็นการเข้ารหัสเริ่มต้นหรือในระหว่างการบำรุงรักษาในภายหลัง ฉันคุ้นเคยกับ MISRA-C มากที่สุด แต่ก็มีคนอื่น ๆ และโดยทั่วไปพวกเขาก็มีกฎที่คล้ายกันเพราะพวกเขาพูดถึงปัญหาเดียวกันในภาษาเดียวกัน

ข้อผิดพลาดที่นิยมอย่างหนึ่งซึ่งมาตรฐานการเข้ารหัสมักจะกล่าวถึงคือ gotcha ตัวเล็ก ๆ นี้: -

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

สิ่งนี้ไม่ได้ทำในสิ่งที่คุณคิด เท่าที่ C เป็นห่วงถ้า x 10 แล้วคุณเรียกdo_something()แต่แล้วdo_something_else()ได้รับการเรียกโดยไม่คำนึงถึงความคุ้มค่าของ x เฉพาะการกระทำที่ตามหลังคำสั่ง "ถ้า" เป็นเงื่อนไขเท่านั้น นี่อาจเป็นสิ่งที่ coder ตั้งใจซึ่งในกรณีนี้อาจมีกับดักสำหรับผู้ดูแล หรืออาจไม่ใช่สิ่งที่ coder ตั้งใจซึ่งในกรณีที่มีข้อผิดพลาด มันเป็นคำถามสัมภาษณ์ที่ได้รับความนิยม

วิธีแก้ปัญหาในมาตรฐานการเข้ารหัสคือการใช้เครื่องหมายปีกการอบการกระทำแบบมีเงื่อนไขทั้งหมดแม้ว่าจะเป็นแบบบรรทัดเดียวก็ตาม เราได้รับแล้ว

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

หรือ

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

และตอนนี้มันทำงานได้อย่างถูกต้องและชัดเจนสำหรับผู้ดูแล

คุณจะสังเกตเห็นว่าสิ่งนี้ขัดกับรูปแบบตารางของคุณทั้งหมด

ภาษาอื่นบางภาษา (เช่น Python) ดูที่ปัญหานี้และตัดสินใจว่าเนื่องจากตัวแปลงสัญญาณกำลังใช้ช่องว่างเพื่อทำให้รูปแบบชัดเจนจึงควรใช้ช่องว่างแทนวงเล็บปีกกา ดังนั้นใน Python

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

ทำให้การเรียกทั้งสองdo_something()และdo_something_else()มีเงื่อนไขใน x == 10 ในขณะที่

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

หมายความว่าdo_something()เป็นเงื่อนไขบน x และdo_something_else()ถูกเรียกเสมอ

เป็นแนวคิดที่ถูกต้องและคุณจะพบว่ามีบางภาษาที่ใช้งานได้ (ฉันเห็นเป็นครั้งแรกใน Occam2 เมื่อไม่นานมานี้) อีกครั้งคุณสามารถเห็นได้อย่างง่ายดายว่ารูปแบบตารางของคุณไม่สอดคล้องกับภาษา

เค้าโครงแบบตารางจะมีประโยชน์ในบางกรณีที่ จำกัด แต่มีบางครั้งก็มีประโยชน์หาก

ในกรณีง่าย ๆ : อาจเป็นตัวเลือกที่ดีกว่า ในกรณีปานกลางสวิตช์มักจะเหมาะสมกว่า (หากภาษาของคุณมี) ในกรณีที่ซับซ้อนคุณอาจพบว่าตารางการโทรนั้นเหมาะสมกว่า

มีหลายครั้งที่รหัสการรีแฟคเตอร์ที่ฉันจัดเรียงใหม่นั้นเป็นแบบตารางเพื่อให้ชัดเจนว่าเป็นพ่อ เป็นกรณีที่ฉันไม่ได้ทิ้งไว้อย่างนั้นในกรณีส่วนใหญ่มีวิธีที่ดีกว่าในการแก้ปัญหาเมื่อคุณเข้าใจ ในบางครั้งการฝึกฝนการเข้ารหัสหรือมาตรฐานเค้าโครงจะห้ามไม่ให้แสดงความคิดเห็นซึ่งเป็นประโยชน์

?:มีคำถามเกี่ยวกับการเป็น ใช่มันเป็นผู้ประกอบการที่สาม (หรือฉันชอบที่จะคิดว่ามันคุ้มค่าถ้า) ในบลัชออนครั้งแรกตัวอย่างนี้มีความซับซ้อนเล็กน้อยสำหรับ?: (และมากเกินไป?: ไม่ได้ช่วยให้อ่านง่าย แต่ก็เจ็บ) แต่ด้วยความคิดบางอย่างตัวอย่างที่สามารถจัดเรียงใหม่ได้ด้านล่าง แต่ฉันคิดว่าในกรณีนี้สวิตช์ วิธีการแก้.

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

ฉันไม่เห็นอะไรผิดปกติกับรูปแบบตาราง ความชอบส่วนตัว แต่ฉันจะใช้ไตรภาคแบบนี้:

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

ไม่จำเป็นต้องทำซ้ำreturnทุกครั้ง :)