เป็นไปได้ไหมที่จะใช้รหัสขนาดยาวที่แสดงการคำนวณได้ง่ายขึ้น?

9

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

รหัสที่อ่านยากเช่นนี้ถือว่าเป็นรหัสที่ไม่ดีหรือไม่? ในทำนองเดียวกันถ้าฉันเขียนโค้ดสำหรับอัลกอริธึมที่ซับซ้อนส่งผลให้โค้ดที่อ่านยากถูกห่อด้วยวิธีการตั้งชื่ออย่างชัดเจนรหัสนั้นเป็นโค้ดที่ไม่ดีหรือไม่

readability

— Michael Tsang
แหล่งที่มา

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

— Zalomon

ORM ของคุณรองรับการดูหรือไม่ คุณสามารถแยกกลุ่ม () เข้าร่วมในมุมมองแล้วเลือกมุมมอง แม้ว่าจะไม่ได้ใช้มุมมองในที่อื่น แต่สามารถแยกคำแถลง SQL ขนาดใหญ่ออกมาได้

— Caleth

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

— SpaceTrucker

17

คุณเขียน

รหัสที่อ่านยากเช่นนี้ถือว่าเป็นรหัสที่ไม่ดี

ดังนั้นคุณตกลงอย่างแน่นอนว่ามันเป็นรหัสที่ยากต่อการอ่านและถ้ามันยากที่จะอ่านมันเป็นเรื่องยากที่จะรักษาและพัฒนา - ดังนั้นฉันคิดว่าคุณคิดว่าโค้ดนั้นแย่มากโดยใช้มาตรการของคุณเอง อย่างไรก็ตามบางครั้งก็ไม่ชัดเจนว่าจะปรับปรุงคำสั่ง SQL 50 บรรทัดอย่างไร refactorings "วิธีการแยก" ที่ง่ายไม่ทำงานและคุณอาจไม่มีเงื่อนงำที่จะเริ่มต้นในการทำให้โค้ดอ่านง่ายขึ้น สำหรับกรณีเหล่านี้คุณยังสามารถลองทำอย่างใดอย่างหนึ่งต่อไปนี้

แสดงรหัสคนอื่นที่มีประสบการณ์มากกว่าคุณในการล้างรหัส หากคุณไม่มีใครในองค์กรคุณสามารถถามได้ลองcodereview.stackexchange
ลอง google เพื่อหาปัญหาที่เฉพาะเจาะจง สำหรับตัวอย่างของคุณสิ่งต่าง ๆ เช่น "การล้างคำสั่ง sql ยาว" อาจเป็นการเริ่มต้นที่ดี คุณจะประหลาดใจกับจำนวนบทความที่คุณพบเกี่ยวกับหัวข้อนั้นและแม้ว่าคุณจะไม่สามารถหาสูตรการสอนสำหรับกรณีของคุณคุณอาจได้รับแนวคิดใหม่ ๆ
แทนที่จะขอเหตุผลสำหรับสิ่งที่คุณทำไม่ได้ให้จดจ่อกับสิ่งที่คุณสามารถทำได้เพื่อล้างรหัสอย่างน้อยนิดเช่นการเพิ่มตัวแบ่งบรรทัดที่เหมาะสมการเยื้องที่เหมาะสมเพิ่มความคิดเห็นที่อธิบายบางอย่างให้ตัวแปรที่ดีกว่า ชื่อ. ในระหว่างกระบวนการนี้ไม่น่าเป็นไปได้ที่จะบังคับให้คุณอ่านรายละเอียดของรหัสใหม่อีกครั้งคุณจะพบวิธีที่จะทำให้รหัสเป็นหน่วยย่อยอีกครั้ง
การปฏิบัติ, การปฏิบัติ, การปฏิบัติ "Clean coding" ไม่ใช่สิ่งที่คุณเรียนรู้ในหนึ่งวันมันง่ายขึ้นด้วยประสบการณ์ที่มากขึ้น บางทีคุณอาจไม่พบทางออกสำหรับปัญหาของคุณในวันนี้ แต่เมื่อคุณกลับมาที่รหัสในอีกไม่กี่เดือนมันจะดูแตกต่างไปจากคุณ

— หมอบราวน์
แหล่งที่มา

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

— Walfrat

@ Walrat: ความตั้งใจของฉันคือการให้แนวทางทั่วไปเกี่ยวกับกระบวนการไม่ใช่เฉพาะสำหรับ "รหัส 50 บรรทัดของ SQL" และไม่ได้เป็นทางออก "นอกกรอบ" ด้วยวิธีการที่เป็นไปได้ทั้งหมด

— Doc Brown

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

— Walfrat

4

อ่านยากไม่เลว - ยากที่จะอ่านยากโดยไม่จำเป็น

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

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

— gnasher729
แหล่งที่มา

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

— Kyle A

1

ออมเพื่อสร้างรายงาน? อย่างจริงจัง? เรียนรู้ SQL บางตัว ภาษาที่ใช้ในขั้นตอนนี้น่ากลัวมาก

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

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

— จอห์นวู
แหล่งที่มา

2

ความจริงแล้วคุณไม่ชอบ ORM นั้นไม่เกี่ยวข้องกับคำถามเลย

— Doc Brown

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

— John Wu

0

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

หากคุณต้องทำมากในแบบสอบถามเดียวลองแยกมันข้ามเส้นที่มีความคิดเห็นฝังตัว:

query(join(map(condition1, condition2), blah, blah, something(bah, blah, blah)))

กลายเป็น:

// Why are we doing such an awful single query rather than a sequence of selects?
query( // Description of query
  join( // Why are you doing a join here
    map( // Why a map
      condition1, // What is this
      condition2  // And this
   ), // End Map
   blah, // What, Why?
   blah, // What, Why?
   something( // What does this do?
      bah, // What, Why?
      blah, // What, Why?
      blah // What, Why?
      ) // End Something
   ) // End Join
) // End Query

— สตีฟบาร์นส์
แหล่งที่มา

ฉันไม่แน่ใจเกี่ยวกับตัวอย่างของคุณ ความคิดเห็นควรอธิบายว่าทำไมรหัสจึงเป็นเช่นนั้น สิ่งที่ควรจะแสดงโดยตัวระบุ ...

— ทิโมธียอมจำนน

@ TimothyTruckle ฉันยอมรับว่าตัวระบุควรระบุสิ่งที่พวกเขาชัดเจน แต่ทั้งหมดมักจะไม่ชัดเจนในรหัสปกติ - ในกรณีที่ชื่อเขตข้อมูลบันทึกมักจะขาดความชัดเจนเนื่องจากข้อ จำกัด ทางประวัติศาสตร์ที่ฉันเจอกรณีเป็นชื่อเขต มีความยาวไม่เกิน 5 ตัวอักษรซึ่งทั้งหมดต้องเป็นตัวอักษรตัวพิมพ์ใหญ่ ASCII และไม่สามารถเปลี่ยนแปลงได้เนื่องจากข้อกำหนดด้านความเข้ากันได้เช่นด้วยเครื่องมือรายงาน MDS ที่ชื่นชอบ

— Steve Barnes

0

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

และคุณประเมินโค้ดที่ระดับของแอปพลิเคชันไม่ใช่ระดับของแต่ละวิธี / บรรทัดของโค้ด ดังนั้นถ้าคุณมีวิธีการที่ซับซ้อน แต่มันมีชื่อชัดเจนฉันไม่คิดว่าคุณมีรหัส "ไม่ดี" ตราบใดที่วิธีนั้นมีความเหนียวแน่น

การตั้งชื่อเป็นอาวุธที่ยิ่งใหญ่ที่สุดที่คุณมีในการสร้างรหัสให้เข้าใจได้ - ตั้งชื่อวิธีการของคุณที่ช่วยให้ผู้คนที่อ่านรหัสของคุณสามารถข้ามร่างได้หากพวกเขาต้องการ ตั้งชื่อตัวแปรของคุณเป็นต้นในแบบที่หมายความว่าผู้อ่านสามารถเห็นสิ่งที่พวกเขาเป็นตัวแทนโดยไม่ต้องอ่านคำสั่งที่ได้รับมอบหมาย

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

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

— เนวิลล์คุยต์
แหล่งที่มา