คุณควรเสียสละการอ่านรหัสด้วยรหัสที่มีประสิทธิภาพหรือไม่ [ปิด]

36

คุณควรเสียสละการอ่านรหัสด้วยรหัสที่มีประสิทธิภาพหรือไม่

เช่น 3 บรรทัดของรหัสเป็น 1 บรรทัด

ฉันอ่านในCode Craftโดย Pete Goodliffe ว่าการอ่านเป็นกุญแจสำคัญ

ความคิดของคุณ?

13

ทำไมคุณคิดว่าโค้ดที่มีจำนวนบรรทัดน้อยกว่าจึงมีประสิทธิภาพมากกว่า นี่เป็นกรณีที่ไม่ค่อยมีภาษาที่ทันสมัยแม้ว่าอาจใช้กับล่ามพื้นฐาน 8 บิต

— David Thornley

69

ไม่สามารถอ่านหรือวัดประสิทธิภาพเป็นเส้น

ในบางกรณีฉันจะเสียสละความสามารถในการอ่านสำหรับความเร็ว แต่น้อยมาก รหัสแบบฝังที่ใช้เครื่องจักรความเร็วสูงเป็นกรณีหนึ่ง สำหรับซอฟต์แวร์ส่วนใหญ่การอ่านมีความสำคัญมากกว่า

— Jim C

1

คำตอบที่เกี่ยวข้อง: programmers.stackexchange.com/questions/39047/…

— Nicole

ฉันมักจะชอบอ่านง่ายจนกว่าประสิทธิภาพจะกลายเป็นปัญหา จากนั้นฉันก็จะเริ่มกังวลเกี่ยวกับมัน

— Pete

62

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

โปรแกรมจะต้องถูกเขียนขึ้นเพื่อให้ผู้คนอ่านและมีเพียงเครื่องที่จะทำงาน

-Abelson & Sussman โครงสร้างและการตีความโปรแกรมคอมพิวเตอร์

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

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

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

3

+1 มีผลตอบแทนลดลง แต่ฉันก็พบว่าโปรแกรมสั้น ๆ โดยทั่วไปจะอ่านง่ายกว่าโปรแกรมที่มีความยาว

— Michael K

23

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

— Vatine

1

ฉันเห็นด้วยกับ Vatine เคยย้อนกลับไปและพยายามคิดสิ่งที่คุณเคยคิดว่า "ชัดเจนที่สุด" เมื่อก่อน

— Wonko the Sane

+ 1 สำหรับ SICP หนังสือยอดเยี่ยม

— Jason Yeo

30

บางครั้งใช่.

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

สำหรับตัวอย่างหลังดูที่บทความFast Inverse Square Rootบน Wikipedia

โดยทั่วไปฉันคิดว่ามันจะดีกว่าที่จะทำให้บางสิ่งบางอย่างที่สามารถอ่านได้ก่อนและกังวลเกี่ยวกับประสิทธิภาพการทำงานหลังจากให้ข้อควรระวังสามัญสำนึกเช่นไม่เลือกอัลกอริทึม O (n ^ 2) มากกว่า O (n) การอ่านอย่างเสียสละเพื่อประโยชน์ของความกะทัดรัดเพียงอย่างเดียวคือในใจของฉันเข้าใจผิด

— อดัมเลียร์
แหล่งที่มา

4

ฉันคิดว่าอาจมีความแตกต่างระหว่าง "โค้ดที่อ่านได้" และ "รู้อัลกอริทึม" ฉันเดารหัสใด ๆ ถ้าคุณไม่ทราบว่าอัลกอริทึมจะยากมากที่จะอ่านและเข้าใจ ตัวอย่างเช่นในกรณี FISR ที่กล่าวถึงรหัสธรรมดาจริง ๆ แล้วค่อนข้างอ่านได้ แต่อัลกอริทึมไม่ได้รับการบันทึกไว้ หากคุณรู้ว่าอัลกอริทึม FISR คุณสามารถเขียนโค้ดได้มากขึ้นเท่าใด คำถามที่เกี่ยวข้องอย่างใกล้ชิดอาจจะ: เมื่อจะเลือกอัลกอริทึมแฟนซี?

— Maglob

@ Maglob ฉันหมายถึงเฉพาะการใช้ 0x5f3759df โดยไม่คำนึงถึงประสิทธิภาพคุณสามารถใช้การใช้อัลกอริทึม ISR โดยใช้การแบ่งปกติซึ่งน่าจะอ่านได้ง่ายกว่าสำหรับบุคคลที่ไม่คุ้นเคยกับการใช้งานคอมพิวเตอร์

— อดัมเลียร์

3

นี่อาจจะแสดงว่า "บางครั้งมันก็ถูกต้องเพื่อแทนที่อัลกอริธึมไร้เดียงสาที่แสดงในความคิดเห็น 5 บรรทัดและรหัส 20 บรรทัดด้วยอัลกอริทึมที่ซับซ้อนที่แสดงในความคิดเห็น 15 บรรทัดและรหัส 5 บรรทัด"

— Peter Taylor

1

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

— Cercerilla

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

— Matthieu M.

22

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

ไม่ได้บอกว่าการเขียนจะต้องอ่านไม่ได้แน่นอน

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

22

ฉันยกมาก่อนและฉันจะพูดอีกครั้ง

ทำให้ถูกต้อง
ทำให้ชัดเจน
ทำให้รัดกุม
ทำให้เร็วขึ้น

เพื่อให้.

Wes Dyer

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

2

+1 ฉันเลื่อนลงอย่างรวดเร็วเพื่อให้แน่ใจว่ามีการเสนอราคานี้ ตอนนี้ฉันไม่ต้องตอบ :-)

— RationalGeek

9

คุณควรเสียสละความสามารถในการอ่านโค้ดด้วยประสิทธิภาพของรหัสหรือไม่

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

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

มีอยู่ในใจของฉันไม่มีข้อแก้ตัวที่จะไม่แสดงความคิดเห็นขั้นพื้นฐานบางอย่าง เห็นได้ชัดว่าif ( x == 0 ) /* check if x is 0 */ไร้ประโยชน์โดยสิ้นเชิง คุณไม่ควรเพิ่มเสียงที่ไม่จำเป็นให้กับรหัส แต่สิ่งนี้:

; this is a fast implementation of gcd
; in C, call as int gcd(int a, int b)
; args go in rdi, rsi, rcx, r8, r9
gcd:
    push rdp
    ; ...

มีประโยชน์มากเลยทีเดียว

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

6

คุณควรเสียสละความสามารถในการอ่านโค้ดด้วยประสิทธิภาพของรหัสหรือไม่

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

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

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

4

ไม่มีใครชนะรหัสกอล์ฟ

เช่น 3 บรรทัดของรหัสเป็น 1 บรรทัด

ความคิดที่แย่มาก

ค่าใช้จ่ายในการเล่นรหัสกอล์ฟ - สูงมาก

ค่าใช้จ่ายในการบำรุงรักษาโปรแกรมที่อ่านไม่ได้ - ทางดาราศาสตร์

ค่าของโค้ดที่ย่อเล็กสุดนี้ - ศูนย์ มันยังใช้งานได้ แต่ไม่ทำงาน "ดีกว่า"

เลือกอย่างมีประสิทธิภาพ

ค่าใช้จ่ายในการเลือกอัลกอริทึมที่ถูกต้องและโครงสร้างข้อมูล - ปานกลาง

ค่าใช้จ่ายในการรักษาอัลกอริธึมที่เหมาะสมและโครงสร้างข้อมูล - ต่ำ

ค่าของอัลกอริทึมที่เหมาะสมและโครงสร้างข้อมูล - สูง การใช้ทรัพยากรอยู่ในระดับต่ำ

โง่ ("การเพิ่มประสิทธิภาพขนาดเล็ก") มีประสิทธิภาพ

ค่าใช้จ่ายในการเล่นโดยใช้การปรับขนาดเล็ก - สูง

ค่าใช้จ่ายในการบำรุงรักษาโค้ดที่ไม่สามารถอ่านได้และปรับให้เหมาะสมกับไมโคร - สูงมาก

มูลค่าของการเพิ่มประสิทธิภาพแบบไมโคร - แตกต่างกันไป เมื่อมีค่าที่ไม่เป็นศูนย์ที่นี่ค่าใช้จ่ายยังคงมีค่าเกิน

— S.Lott
แหล่งที่มา

2

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

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

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

2

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

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

2

ฉันไม่ยอมรับอาร์กิวเมนต์ "อ่านง่ายกว่าประสิทธิภาพ" ฉันจะให้คำตอบกับสปินที่ต่างออกไป

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

ตกลง. ดังนั้นเพียงแค่จินตนาการชั้นที่สองระหว่างฉันคลิกสองครั้งที่คอมพิวเตอร์ของฉันและจริง ๆ แล้วมันพูดผ่านไดรเวอร์ไปยังซีดีรอม ทีนี้ลองนึกภาพว่าทุกชั้น ... เร็วขึ้น ...

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

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

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

"ตกลงดังนั้นแค่เสี้ยววินาทีแล้วก็นึกภาพเลเยอร์ทั้งหมดระหว่างฉันดับเบิลคลิกที่คอมพิวเตอร์ของฉันและมันก็พูดผ่านไดรเวอร์ไปยังซีดีรอมตอนนี้จินตนาการว่าเลเยอร์ทั้งหมด ... เร็วกว่า ... " ทันทีสำหรับฉันด้วย DVD 2 แผ่น ไดรฟ์

— Rangoric

หนึ่งคำ: อัปเกรด

— jmort253

2

คนที่ทำงานกับฉันที่นี่ก็เป็นตัวอย่าง ...

— Maltrap

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

— Jonathan Neufeld

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

— Jonathan Neufeld

2

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

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

— Desolate Planet
แหล่งที่มา

1

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

ด้วยเหตุนี้ฉันพบว่าการอ่านมีความสำคัญมาก แน่นอนตามที่ระบุไว้หลายครั้งเพียงเพราะรหัสไม่สามารถอ่านได้หมายความว่ามันช้าลง

ตัวอย่างที่ดีคือชื่อตัวแปร: $a

คืออะไร$a?? นี่เป็นบริบทที่คุณไม่สามารถตอบได้ แต่คุณเคยพบปัญหานี้ในรหัสจริงหรือไม่? ทีนี้สมมติมีคนเขียน$file_handleตอนนี้คืออะไร ชัดเจนแม้จะอยู่นอกบริบท ความยาวของชื่อตัวแปรสร้างความแตกต่างเล็กน้อยกับคอมพิวเตอร์

ฉันคิดว่ามีสามัญสำนึกที่จะมีที่นี่

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

* สิ่งนี้ขึ้นอยู่กับอุตสาหกรรมและสิ่งอื่น ๆ ฉันกำลังดูสิ่งนี้จากมุมมองของนักพัฒนาซอฟต์แวร์ธุรกิจ (Business Information Systems)

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

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

ดังนั้นในทางปฏิบัติฉันคิดว่าคุณมีแนวโน้มที่จะทำร้ายตัวเองหรือผู้อื่น ...

— แฟรงค์โวลต์
แหล่งที่มา

1

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

x++; // Add one to x

ค่อนข้างแสดงความคิดเห็นสำหรับคุณผู้อ่านใน 6 เดือนหรือ 12 เดือนหรือบางเวลานานพอสมควร ใช้มาตรฐานการเข้ารหัสและปฏิบัติตาม

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

+1 สำหรับ "เชื่อถือตัวแปลของคุณเพื่อให้ทำงานได้" นั่นคือความคิดเห็น Skype ใหม่ของฉัน

— jmort253

0

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

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

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

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

-1

ความสามารถในการอ่านเป็นข้อแก้ตัวสำหรับโปรแกรมเมอร์ที่ไร้ความสามารถและขี้เกียจ (อันที่จริงแล้วใช้สำหรับ "ความเรียบง่าย" เมื่อใช้เป็นอาร์กิวเมนต์เพื่อปกป้องอัลกอริทึม / การออกแบบเส็งเคร็ง)!

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

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

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

— บางคน
แหล่งที่มา

-2

ถ้าการลดความสามารถในการอ่านช่วยให้โค้ดทำงานได้อย่างมีประสิทธิภาพ / เพิ่มประสิทธิภาพ (เช่นในswfobjectและ js อื่น ๆ ) มันเป็นเหตุผลที่ทำให้การเขียนโค้ดที่มีรูปแบบที่ดีและอ่านได้ชัดเจนและแปลงให้เป็น

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