ฉันจะจัดทำรหัสสำหรับการตรวจสอบเวลาน้อยที่สุดได้อย่างไร [ปิด]


22

ฉันต้องการเอกสารรหัสของฉันเพื่อให้มีความจำเป็นขั้นต่ำสำหรับการอ่านและเรียกดูรหัสอีกครั้งในภายหลัง

ฉันรู้ว่ามีเอกสารประเภทต่าง ๆ (ในซอร์สโค้ดและภายนอก, แผนภาพลำดับและอื่น ๆ )

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


42
วิธีที่ดีที่สุดสำหรับการใช้เวลาในการอ่านรหัสให้น้อยลงในภายหลังคือการเขียนรหัสที่ชัดเจนและเข้าใจได้ง่ายขึ้น
Mael


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

@Laiv ในมุมมองของนักพัฒนาของรหัสของตัวเองและรหัสนักพัฒนาอื่น ๆ
Hamed_gibago

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

คำตอบ:


16

ฉันต้องยอมรับว่าฉันไม่เห็นด้วยกับสิ่งที่คำตอบอื่น ๆ แนะนำดังนั้นฉันจะโยนสองเซ็นต์ของฉัน

ความคิดเห็น

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

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

การแสดงความคิดเห็นงานของคุณควรแม่นยำและน้อยที่สุด แต่ในความคิดของฉันควรนำเสนอแน่นอน อย่างน้อยความคิดเห็นสำหรับรหัส 15 บรรทัดทุกบรรทัด ตัวอย่างเช่นด้านบนของบล็อกในรหัสเพิ่มบรรทัดเกี่ยวกับสิ่งที่คุณกำลังทำ:

def login(username: str, password: str, create_session: bool = True):

    # Filter the user we need from the database
    hash = md5(password)
    users = db.table("users", db_entities.USER)
    results = [x for x in users.query(lambda c: c.get("username") == username and c.get("password_hash") == hash)]


    if len(results) == 0:
        return None, None
    else:
        # Create a login session record in the database.
        if create_session:
            sessions = db.table("sessions", db_entities.SESSION)
            ses = sessions.new()
            ses.set("username", username) \
                .set("expiery", 31536000 + time.time())
            sessions.update(ses)
            return results[0], ses
        else:
            return results[0], None

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

หากฉันเจอโค้ดที่มีความคิดเห็นฉันจะเตรียมตัวสำหรับสิ่งที่แย่ที่สุด: โค้ดน่าจะแย่และความจริงแล้วความคิดเห็นนั้นก็น่าจะแย่เช่นกัน

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

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

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

# Logging into Gmail when the module is imported
_client = login()
def get_client():
    global _client
    return _client

ตัวอย่างคำอธิบาย: "ไม่น่ากลัว Sherlock จะ_client = login()เข้าสู่บริการอีเมลหรือไม่ OMG!"

การชี้แจงเพิ่มเติม: login()วิธีการไม่มีความสัมพันธ์กับlogin()วิธีการจากตัวอย่างข้างต้น

แต่ความคิดเห็นที่ตรงกับมาตรฐานอธิบายว่าทำไมและไม่ใช่วิธีการและตอบคำถามที่ถูกต้องมีประโยชน์มาก ( มาก )

ความคิดเห็นแบบอินไลน์

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

ตัวอย่างเช่นความคิดเห็นแบบอินไลน์ที่ไม่ดี:

outer = MIMEText(details["message"]) # Constructing a new MIMEText object
outer["To"] = details["to"] # Setting message recipient
outer["From"] = "xAI No-Reply" # Setting message sender
outer["Subject"] = details["subject"] # Setting message subject
outer.preamble = "You will not see this in a MIME-aware mail reader.\n" # I don't know what I'm doing here, I copied this from SO.
msg = outer.as_string() # Getting the string of the message
_client = details["client"] # Assigning the client
_client.sendmail(SENDER, details["to"], msg) # Sending the mail

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

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

# Constructing the email object with the values 
# we received from the parameter of send_mail(details)
outer = MIMEText(details["message"])
outer["To"] = details["to"]
outer["From"] = "xAI No-Reply"
outer["Subject"] = details["subject"]
outer.preamble = "You will not see this in a MIME-aware mail reader.\n"
msg = outer.as_string()

# Sending the mail using the global client (obtained using login())
_client = details["client"]
_client.sendmail(SENDER, details["to"], msg)

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

เอกสารประกอบการใช้งาน

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

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

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


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

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

2
ตัวอย่างที่สองนั้นน่ารัก
การแข่งขัน Lightness กับ Monica

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

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

55

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

ด้วยการพูดว่า:

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

19
นี่เป็นตัวชี้วัดที่ดีสำหรับเอกสาร (ลิงก์บังคับ)
Neil

4
สิ่งนี้ควรอยู่ในรายการด้วย: อธิบายในโค้ดว่าทำไมคุณถึงทำสิ่งที่คุณทำ
t3chb0t


4
numberOfItemsFoundค่อนข้าง verbose แม้ว่า; verbose เกินไปก็เป็นปัญหา
Matthieu M.

6
@ MatthieuM. ไม่ค่อยมี "verbose มากเกินไป" ปัญหาเกี่ยวกับชื่อในรหัส สั้นเกินไปหรือเป็นความลับเป็นปัญหาที่พบบ่อยมากแม้ว่า
David Arno

25

ปฏิบัติต่อรหัสของคุณเป็นเอกสาร

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

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

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

อ่านโค้ดได้ดีขึ้น

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

ความเห็นเป็นกลิ่นรหัส

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

ระวังเอกสาร API ที่สร้างอัตโนมัติ

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

การทดสอบก็เป็นเอกสารเช่นกัน

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

วาดภาพถ้ามันช่วย

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

มีเอกสารมุมมอง "1000ft"

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


14
ฉันเห็นด้วยกับทุกประเด็นของคุณยกเว้นความคิดเห็นที่มีสถานที่ของพวกเขา ในขณะที่ฉันเห็นด้วยไม่มีจุดในความคิดเห็นเช่นadd 1 to iความคิดเห็นควรอธิบายว่าทำไมรหัสทำในสิ่งที่มันทำ ตัวอย่างเช่นรหัสสามารถใช้ความคิดเห็นที่ชอบ:if (!something.Exists()) {...} // something exists only when (explanation of the broader scenario)
Jonathan

16
เราทุกคนเห็น// increment x x++;ความคิดเห็นที่ยุติธรรมของเราที่ไม่มีประโยชน์ แต่เป็นการผิดที่จะโยนลูกออกไปพร้อมกับอาบน้ำและประกาศว่าความคิดเห็นไม่ดีอยู่เสมอ // this case should never happen because xyz throw exception "unreachable"ตัวอย่างเช่นความเห็นของแบบฟอร์ม
angrydust

7
รายการที่ดีมาก แต่ชอบ @Jonathan ฉันไม่เห็นด้วยกับความคิดเห็น บางครั้งคุณต้องบัญชีข้อบกพร่องในกรอบงานของบุคคลที่สามว่า ในขณะที่สิ่งนี้สามารถ refactored ในฟังก์ชั่นของตัวเองมันก็ยังดีที่จะออกเล็กน้อยของคำอธิบายว่าทำไมการแก้ปัญหา (bugnumber หรือ bugname / คำอธิบายของข้อผิดพลาด) จำเป็น
magu_

16
@DavidArno แต่คุณไม่สามารถทำเช่นนั้นได้สำหรับความคิดเห็นที่อธิบายว่าทำไมบางสิ่งบางอย่างไม่ได้ทำ กด//XXX: Not using straight-forward method Foo here because ...ไลค์ ความคิดเห็นดังกล่าวมีค่าอย่างมาก แต่ไม่สามารถถ่ายทอดด้วยรหัสได้ด้วยเหตุผลที่ชัดเจน
cmaster

7
ผมชอบมันอย่างมากแม้: ทุกความคิดเห็นคือความล้มเหลวที่จะแสดงตัวเองได้ดีในรหัส ตัวอย่างเช่นฉันมีความคิดเห็น 4 บรรทัดในวิธีการหนึ่งโดยอธิบายวิธีแก้ปัญหาสำหรับข้อบกพร่องของบุคคลที่สาม ฉันล้มเหลวที่จะแสดงได้ดีในรหัสที่ดังนั้นจึงเป็นเรื่องในความคิดเห็น ผมว่ามันปรับปรุงให้สามารถอ่านได้ยากเพราะผมสงสัยใครจะสนุกกับการเลื่อนในแนวนอนเพื่ออ่านมากเป็นเวลานานและมากชื่อวิธีพรรณนา "ความคิดเห็นเป็นกลิ่นรหัส" - ใช่ แต่เราต้องจำไว้ว่าไม่ใช่ทุกสิ่งที่มีกลิ่นนั้นคือ sh * t
R. Schmitz

5

ระบุจดหมายปะหน้า

หากคุณไม่ได้อยู่ในโดเมนด้านเทคนิคคำถามส่วนใหญ่เกี่ยวกับรหัสจะไม่เกี่ยวกับ 'อย่างไร' แต่เกี่ยวกับ 'ทำไม' หรือ 'อะไร'

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

แม้ว่าผู้คนจะมีความรู้ด้านเทคนิคจดหมายแนะนำควรให้คำแนะนำว่าพวกเขาควรมองหาบางสิ่ง

ง่ายมากจุด minimalistic:

  1. บทนำทำไมรหัสนี้ (ฐาน) จึงมีอยู่
  2. โค้ดย่อยทำหน้าที่อะไร
  3. รหัสอยู่ที่ไหน (เช่นชื่อสคริปต์)

ตัวอย่าง

  1. ชุดของสคริปต์นี้ใช้กับ StackOverflow และเพิ่มคำตอบให้กับ Dennis Jaheruddin
  2. สคริปต์นี้มีหน้าที่แยกวิเคราะห์ HTML และวิเคราะห์ว่าเป็นผู้ใช้ที่เหมาะสมหรือไม่
  3. พบสคริปต์ได้ที่: ScrapeAndVote / RecognizeDennis.scr

1

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

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

นี่เป็นเรื่องง่ายที่จะตรวจสอบเพราะการเปลี่ยนแปลงทางกลล้วนสามารถมองข้ามไปได้อย่างรวดเร็วแล้วออกไปให้พ้นทาง

ในทำนองเดียวกันถ้าคุณฟอร์แมตรหัสนั่นควรจะเป็นการกระทำที่แยกต่างหาก


1

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

  1. ประการแรกเขียนโค้ดสะอาด "เอกสาร" อื่น ๆ จะดูแลตัวเองหลังจากนั้น Clean code เป็นชุดของหลักการทั้งหมดในการเรียนรู้ในสถานที่แรก: คลาสเดียวความรับผิดชอบวิธีการสั้น ๆ ที่ทำสิ่งหนึ่งชื่อตัวแปรและวิธีการที่ดีชื่อคลาส / ประเภทที่ดีกว่าโดยมุ่งเน้นที่คำอุปมาอุปมัย (เช่นเรียก MultiButtSupporter โซดา), การทดสอบหน่วยเพื่อระบุความต้องการ, แห้ง, ของแข็ง, กระบวนทัศน์ที่สอดคล้องกันและอื่น ๆ
  2. รหัสเผยให้เห็นวิธีการทำงานของรหัส; ความคิดเห็นเปิดเผยว่าทำไมรหัสทำงาน ตัวอย่างเช่นอธิบาย +1 ด้วย "ป้องกันการผิดพลาดโดย 1 ข้อผิดพลาด" หรือสูตรที่ซับซ้อนบางอย่างที่ "ได้รับมาในตำราหรือเว็บเพจนี้"
  3. สิ่งที่คุณได้ทำกับความคิดเห็นจุดที่ 1 ข้างต้นอาจบรรลุได้ว่าในรหัสที่สะอาด ดูความคิดเห็นว่าเป็นความล้มเหลว / ความชั่วร้ายที่จำเป็นหรือแม้กระทั่งโกหกว่าเมื่อเวลาผ่านไปพวกเขาจะไม่ซิงค์กับโค้ดเนื่องจากทั้งคู่ได้รับการแก้ไข ความคิดเห็นไม่ควรชดเชยโค้ดที่เขียนไม่ดีเพราะเหตุใดความคิดเห็นจึงถูกเขียนด้วยความสามารถหรือความสนใจมากกว่าโค้ดนั้น

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


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

@JirkaHanika อาจจะเป็นตัวอย่างที่ไม่ดีก็ได้ สำหรับ 3 สิ่งที่ฉันหมายถึงคือ "แต่ละคนอาจ" มากกว่า "อาจจะแต่ละคน"; ดังนั้นไม่ฉันไม่คิดว่ารหัสเพียงอย่างเดียวสามารถอธิบายสิ่งต่าง ๆ ได้ (ดีคุณสามารถลอง gaussianFromThisTextbookNamesApproximation เป็นชื่อตัวแปร แต่นั่นเป็นความคิดที่ไม่ดี!)
JG
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.