อะไรทำให้“ สไตล์ดี” ใน Java? [ปิด]


9

ฉันได้ถามคำถามนี้เกี่ยวกับ Stackoverflow และก่อนที่จะถูกโห่ไล่ฉันได้รับคำแนะนำที่เป็นประโยชน์จากPéterTörökว่านี่อาจเป็นสถานที่ที่ดีกว่าในการโพสต์

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

แต่อะไรที่ทำให้ 'สไตล์ดี'? เช่นเดียวกับหลาย ๆ สิ่งฉันรู้ว่าเมื่อฉันเห็นมัน ... แต่ฉันต้องการความคิดที่ดีกว่าแค่ความรู้สึกผิดชอบชั่วดีของฉันโดยบอกว่าการออกแบบนี้ไม่ถูกต้อง

คุณคิดอย่างไรเกี่ยวกับการสร้างโค้ดที่ดีและออกแบบมาอย่างดี?

(ฉันยอมรับว่านี่เป็นเรื่องส่วนตัวเนื่องจาก 'สไตล์ดี' จะขึ้นอยู่กับงานในมือ) (นอกจากนี้ฉันควรเพิ่มว่าฉันไม่สนใจสไตล์ทีม - เช่น "เราใช้การเยื้องของ 2 ช่องว่างแทนที่จะเป็น 4" ... และฉันไม่สนใจระเบียบของโค้ด Java)

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


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

1
@ Brian ให้รหัสของคุณอธิบาย ว่า แสดงความคิดเห็นที่เกิดขึ้นจริงที่จะอธิบายว่าทำไม ในคำอื่น ๆ อย่าแสดงความคิดเห็นอย่างบ้าคลั่ง (ในกรณีทั่วไป)

4
ไบรอัน: เทคนิคนั้นไม่ถือว่าเป็นแนวปฏิบัติที่ดี แนวปฏิบัติที่ดีทั่วไปคือมีจุดมุ่งหมายเพื่อทำให้โค้ดของคุณเป็นเอกสารด้วยตนเองเท่าที่จะทำได้ (พร้อมชื่อตัวแปรที่ชัดเจนและการทำงานร่วมกัน) พร้อมความคิดเห็นเพื่ออธิบาย "สาเหตุ" และไม่ใช่ "วิธี" ความคิดเห็นที่อธิบายรายละเอียดเล็ก ๆ น้อย ๆ นั้นโดยทั่วไปถือว่าเป็นการรบกวนและมักเป็นอันตรายเนื่องจากผู้คนมีแนวโน้มที่จะรักษาความคิดเห็นน้อยกว่าโค้ด
Casey Patton

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

2
ฉันถ่อมอย่างเป็นทางการ ขออภัย @amaidment ฉันเดาว่าต้องวิจัยมาตรฐานการเข้ารหัสที่ดีเมื่อพูดถึงความคิดเห็น
Brian

คำตอบ:


17

ประเด็นสั้น ๆ บางประการ:


3
+1 อาจสำคัญที่สุด: ลดรหัสซ้ำ หากคุณถูกล่อลวงให้ตัดและวางโทเค็นมากกว่าสองสามตัวคุณจะต้องแยกฟังก์ชัน แม้ว่าฟังก์ชั่นจะเป็นรหัสบรรทัดเดียว
วินไคลน์

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

@jsternberg: +1 สำหรับการแยก / คัดลอก แต่ฉันสังเกตเห็นว่าผู้คนจำนวนมากพูดว่า "cut / paste" เมื่อพวกเขาหมายถึง "คัดลอก / วาง" ฉันไม่รู้ว่าความแตกต่างนั้นหายไปอย่างไร
Ryan Stewart

5
อย่าทำซ้ำตัวเอง อย่าทำซ้ำตัวเอง อย่าทำซ้ำตัวเอง
กำหนดค่า

1
@ ผู้สร้างคุณได้กลิ่นตลกนิดหน่อย ...

9

เพิ่มในรายการของ Ryan:

  • ปฏิบัติตามหลักการที่เป็นของแข็ง
  • ตรวจสอบให้แน่ใจว่ารหัสของคุณไม่มีความซับซ้อนตามรอบมากเกินไป
  • Test Driven Java เป็นสิ่งที่ดีเสมอ
  • หากคุณมีxFactoryFactoryชั้นเรียนคุณทำผิด :-)
  • เนื่องจากไลบรารี่โอเพ่นซอร์สในระบบนิเวศของจาวาทำให้การคิดค้นวงล้อใหม่นั้นเป็นรูปแบบที่ไม่ดี
  • ใช้เวลา Jodaสำหรับวันที่และเวลา

ฉันจะหยุดตรงนั้น


2
แต่HammerFactoryFactoryFactoryชั้นเรียนล่ะ ;-)
Wayne Molina

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

ฉันรู้ว่าฉันกำลังเหน็บแนมและอ้างอิงบทความเกี่ยวกับสาเหตุที่ -J2EE นั้นซับซ้อนเกินไปด้วย HammerFactories และ HammerFactoryFactories และฉันคิดว่า HammerFactoryFactoryFactories :)
Wayne Molina

@ Martijn - ขอบคุณสำหรับลิงค์ SOLID; ฉันไม่เคยเจอเรื่องแบบนี้มาก่อน คุณแนะนำให้ใช้ JodaTime นี่เป็นเพียงความเกลียดชัง (เหมาะสม) ของคลาส Java Calendar / Date หรือไม่ แล้ว JSR310 (ผู้สืบทอดต่อ JodaTime) คืออะไร?
แก้ไข

JSR-310 หวังว่าจะทำให้มันเป็น Java 8 (มีพวกเราหลายคนเตรียมพร้อมที่จะลองและช่วยทำให้มันเกิดขึ้นโปรดติดต่อฉันหากคุณต้องการมีส่วนร่วม) ในเวลาเฉลี่ยเวลา Joda คือ defacto std สำหรับจัดการกับวันที่และเวลาใน Java มีหลายสิ่งผิดปกติในระบบ Date and Calendar ของ Java ที่ฉันไม่รู้ด้วยซ้ำว่าจะเริ่มต้นอย่างไร ;-) นักฆ่าคือวันที่ไม่แน่นอนและไม่มีแนวคิดของการโต้ตอบแบบทันทีหรือช่วงเวลาหรือ ... ไม่ฉันจะหยุดที่นั่น :-)
Martijn Verburg

1

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

  • สิ่งที่จำเป็นต้องรู้เกี่ยวกับคลาส / เมธอด / ตัวแปรนี้ ความรู้นี้ควรอยู่ที่ไหน

  • รหัสนี้มีผลกับหน่วยความจำ / ประสิทธิภาพของแอปพลิเคชันของฉันอย่างไร (ฉันยอมรับว่า 'การเพิ่มประสิทธิภาพก่อนวัยอันควรเป็นรากฐานของความชั่วร้ายทั้งหมด' ดังนั้นฉันจึงไม่แนะนำให้ใช้เวลามากที่สุดในการปรับให้เหมาะสม

  • ชัดเจนหรือไม่ (จากรหัสและโครงสร้างโค้ด) สิ่งนี้ทำอะไร (ฉันพยายามที่จะทำตามจุดสูงสุด: "พยายามอย่าทำให้ผู้คนเข้าใจได้พยายามที่จะทำให้คนเข้าใจผิดไม่ได้")


1

อ่านคลาส String และ ArrayList เพื่อดูตัวอย่างการเขียนโปรแกรม Java ที่เหมาะสม แต่มีความรัดกุมสูงเกือบจะเป็นสไตล์ C ซึ่งไม่จำเป็นต้องดีที่สุดสำหรับการบำรุงรักษาโค้ดที่มี w / เอกสาร Java น้อยที่สุด การปฏิบัติทั่วไปที่ร้านค้าของฉันไม่มีความคิดเห็นดังนั้นฉันจึงพยายามแสดงความคิดเห็นด้วยรหัสโดยใช้ชื่อ verbose camelCase var และการใช้บรรทัดใหม่มากเกินไปในการกำหนดขอบเขตความคิดหนึ่งบรรทัดจากอีกบรรทัดหนึ่ง ฉันยังคงอภิปรายโดยใช้แท็บเพื่อแยก vars จากค่าของพวกเขา แท็บสามารถเพิ่มความสามารถในการอ่าน, IMO, แต่เมื่อทำน้อยที่สุดและเป็นอัตนัย ฉันพบว่ามันเป็นเรื่องของผู้ชม ไม่มีคำตอบที่ดีที่สุดที่นี่

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.