มีประโยชน์อะไรบ้างที่ทำให้มัวเมากับการสร้างโค้ด“ ดูสวย”

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

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

ฉันแค่เป็นโรค OCD โดยสิ้นเชิงหรือมีประโยชน์ซ่อนอยู่ในนี้บ้างไหม

ใช้ตัวจัดรูปแบบอัตโนมัติ หากคุณใช้เวลาในการแก้ไขโค้ดด้วยตนเองจริง ๆ ฉันยินดีที่จะเดาว่าคุณไม่ได้รับการท้าทาย / เบื่อมากเพราะไม่มีเหตุผลใด ๆ Ctrl + K, Cntrl + D ใน VS จะจัดรูปแบบเอกสารทั้งหมด คุณสามารถใช้บางอย่างเช่น Style Cop ถ้าคุณต้องการบางสิ่งบางอย่างหนาขึ้น

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

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

ไม่มีสิ่งใดที่ซ่อนรหัสสวยอ่านง่ายและบำรุงรักษาง่าย

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

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

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

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

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

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

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

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

- ไม่มีการถูกครอบงำด้วยการทำให้ดูรหัสสวยหายไปจุด

นี่คือภูมิปัญญาบางส่วนที่ฉันพบว่ามีประโยชน์:

ถามว่าทำไม Code ต้องเป็นระเบียบ

คุณอาจจะหรืออาจจะไม่ต้องเสียเวลากับคำนิยามของคุณ

ทฤษฎีการจัดรูปแบบพื้นฐานบอกว่าเลย์เอาต์ที่ดีแสดงให้เห็นถึงโครงสร้างเชิงตรรกะของโปรแกรม การทำให้โค้ดดูสวยมีค่าอะไร แต่ก็คุ้มค่าน้อยกว่าการแสดงโครงสร้างของรหัส [pg 732, Code Complete 2nd Edition, Steve McConnell]

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

มันจะทำการเปลี่ยนแปลงได้ยากขึ้นและจะทำให้เกิดข้อขัดแย้งในการรวมที่ไม่จำเป็นหากสมาชิกในทีมคนอื่นกำลังแก้ไขไฟล์ หากคุณต้องทำการจัดรูปแบบการเปลี่ยนแปลงให้ตรวจสอบว่าสมาชิกทีมคนอื่นไม่ทำงานกับไฟล์นั้น [ถอดความ, หน้า 93, การควบคุมเวอร์ชันในทางปฏิบัติโดยใช้การโค่นล้ม, รุ่นที่ 2]

มาร์ตินฟาวเลอร์พูดถึง 'สวมหมวกสองใบ' และสลับระหว่างพวกเขาตลอดทั้งวัน หมวกหนึ่งใบสำหรับเพิ่มคุณสมบัติหมวกหนึ่งใบสำหรับการปรับโครงสร้างใหม่

1. คุณลองเพิ่มฟีเจอร์ใหม่ (Feature Hat)
2. คุณตรวจสอบรหัสที่มีอยู่เพื่อทำความเข้าใจจัดระเบียบตามที่คุณไป (เปลี่ยนหมวก)
3. ยอมรับการเปลี่ยนแปลง
4. เพิ่มคุณสมบัติ (คุณสมบัติหมวก) และอื่น ๆ ....

[ถอดความหน้า 57ish, Refactoring, Martin Fowler]

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

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

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

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

มันช่วยได้นิดหน่อย แต่ก็ไม่คุ้มที่จะเสียเวลาไปกับมัน ตรวจสอบให้แน่ใจว่าการปรับปรุงของคุณเพิ่มการกำหนดขอบเขตตัวแปร, RAII, คัดลอกกลุ่ม / วางโค้ด ฯลฯ หากคุณทำทั้งหมดนั้นจะกลายเป็น 1,000x ง่ายขึ้นเมื่อคุณต้องเข้าใจว่าโค้ดทำอะไรหลังจากหนึ่งปีหรือมากกว่านั้น

คุณควรสร้างโค้ดที่สะอาด แต่ไม่ควรใช้เวลาหลายชั่วโมง

สำหรับ C นั้นมีโปรแกรม gnu-gnu-indent gnu-indentใน eclipse อย่างน้อยมี codeformatter สำหรับ Java และฉันเดาว่ามีเครื่องมือสำหรับภาษาอื่น ๆ ส่วนใหญ่ด้วย ควรคลิกสองสามครั้งเพื่อเยื้องไฟล์อย่างถูกต้องและไม่กี่นาทีหากคุณต้องการละเมิดกฎสำหรับวัตถุประสงค์เฉพาะ - เช่นเดียวกับที่ทำกับงบสั้น ๆ

 switch (foo) {
      case a:  foo (a);             break; 
      case b:  foob ();             break;
      case c:  /* intent. empty */
      case d:  foocd ();            break; 
      default: allPrettyAligned (); break; 
 }

ซึ่งยากที่จะระบุ

หากคุณคิดว่าบางสิ่งบางอย่างดูสะอาดตาโดย skimming มันแสดงว่าคุณกำลังจดจ่ออยู่กับสิ่งที่ผิวเผิน

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

http://www.joelonsoftware.com/articles/Wrong.html

โดยเฉพาะรายการนี้:

ตกลงจนถึงตอนนี้ฉันได้กล่าวถึงความสำเร็จสามระดับในฐานะโปรแกรมเมอร์:

1. คุณไม่รู้จักสะอาดจากมลทิน

2. คุณมีความคิดผิวเผินเกี่ยวกับความสะอาดซึ่งส่วนใหญ่อยู่ในระดับที่สอดคล้องกับข้อกำหนดของการเข้ารหัส

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

แม้ว่าจะมีระดับที่สูงขึ้นซึ่งเป็นสิ่งที่ฉันต้องการพูดถึง:

4. คุณตั้งใจออกแบบรหัสของคุณในลักษณะที่จมูกของคุณไม่สะอาดทำให้รหัสของคุณมีแนวโน้มที่จะถูกต้องมากขึ้น

นี่คือศิลปะที่แท้จริง: การสร้างรหัสที่มีประสิทธิภาพโดยการประดิษฐ์ข้อตกลงที่ทำให้เกิดข้อผิดพลาดที่เด่นชัดบนหน้าจอ

"ชั่วโมง"? ฉันจะบอกว่าคำตอบของคุณคือ "และ" ไม่ใช่ "หรือ": ใช่คุณเป็น OCD แต่มีประโยชน์บางอย่าง

อาจ.

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

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

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

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

อย่างไรก็ตามฉันจะต้องระมัดระวังไม่ให้ฟอร์แมตโค้ดของคุณเพื่อประโยชน์ของเพื่อนร่วมงานหรือนักพัฒนาในอนาคต น่ารักสำหรับคุณอาจไม่สวยสำหรับฉัน :)

คุณรับรู้ปัญหา (พฤติกรรมบีบบังคับ) และอาการ (การจัดรูปแบบครอบงำ)

แล้วสาเหตุและการรักษาล่ะ

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

บางครั้งอาการเหล่านี้เป็นสัญญาณว่าถึงเวลาที่ต้องทำการเปลี่ยนแปลงหรือย้ายตัวหนา

หนังสือของ Yourdon มีคำแนะนำที่เป็นประโยชน์มากมายและสำหรับหลาย ๆ องค์กรหนังสือของ Yourdon ก็กำลังบรรยายอย่างแท้จริง

http://dev.co.ua/docs/Edward%20Yourdon%20-%20Death%20March.pdf

คุณดูลึกซึ้งและฉันคิดว่าคุณอาจรู้คำตอบ

ตอนนี้ให้สิทธิ์ตัวเองในการดำเนินการกับมัน

ศักดิ์สิทธิ์วัว!
คนที่คุณไม่เคยได้ยินการเยื้อง?

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

ermm - แต่ใช้งานได้เฉพาะบน C และบางตัว แต่ไม่ใช่ C ++ ทั้งหมด (wtf ทำไม GNU ถึงไม่อัพเกรดมัน)