การตั้งชื่อ: คุณควรสังเวยบทสรุปเพื่อความชัดเจนหรือไม่

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

ดีกว่าที่จะเป็นบทสรุปและเขียนนี้:

addInvalidField (field, message) {
  const foundField = this.invalidFields.find(value => {
    return value.name === field.name
  })
  const errors = foundField.errors
  if (!errors.some(error => error.name === message)) {
    errors.push({ name: message, message })
  }
},

หรือเฉพาะเจาะจงมากขึ้นเช่นนี้?

addInvalidField (validatingField, message) {
  const foundField = this.invalidFields.find(invalidField => {
    return validatingField.name === invalidField.name
  })
  if (!foundField.errors.some(foundFieldError => foundFieldError.name === message)) {
    fouldField.errors.push({ name: message, message })
  }
},

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

addInvalidField (field, message) {
  const foundInvalidField = this.invalidFields.find(x => x.name === field.name)
  if (!foundInvalidField.errors.some(x => x.name === message)) {
    foundInvalidField.errors.push({ name: message, message })
  }
},

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

บริบทเช่นเคยเป็นราชา

ฉันชอบตัวอย่างรหัสแรกของคุณ

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

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

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

ทีนี้ฉันกำลังอ้างถึง Clean Code ที่นี่ (ข้ามมันไปถ้าคุณเบื่อกับการเทศนาของลุงบ็อบ (ซึ่งฉันไม่ได้):

ใช้ชื่อที่เปิดเผยความตั้งใจ

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

หลีกเลี่ยงการบิดเบือนข้อมูล

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

สร้างความแตกต่างที่มีความหมาย

โปรแกรมเมอร์สร้างปัญหาด้วยตนเองเมื่อพวกเขาเขียนโค้ดเพียงอย่างเดียวเพื่อทำให้คอมไพเลอร์หรือล่าม

ใช้ชื่อที่ค้นหาได้

ใช้ชื่อที่จะช่วยคุณทำgrep -iIR whateveryouaresearching . (ไม่ใช่ Clean Code ที่นี่ CC พูดถึงตัวแปรตัวอักษรเดียวเท่านั้น)

หลีกเลี่ยงการทำแผนที่จิต

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

ใช้ชื่อโดเมนปัญหา

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

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

ย้อนกลับไปก่อนประวัติศาสตร์คุณมีข้อ จำกัด ชื่อตัวแปรและการใช้ชื่อตัวแปรที่มีความหมายอาจทำให้เกิดต้นทุนที่วัดได้ (เช่นใน BBC BASIC โดยใช้ตัวแปรคงที่จำนวนเต็ม A% ฯลฯ มีราคาถูกกว่าการใช้จำนวนเต็มที่มีความหมาย - และในระบบที่ 1MHz หน่วยประมวลผลโดยบันทึกวงจรนาฬิกาสองสามรอบในลูปที่สำคัญจริงๆ)

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

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

addInvalidField (fieldname, message) {
  const foundField = this.invalidFields.find(value => {
    return value.name === fieldname
  })
  const errors = foundField.errors
  if (!errors.some(error => error.name === message)) {
    errors.push({ name: message, message })
  }
}

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

addInvalidField (fieldname, message) {
  const foundField = findInvalidField(fieldName)
  addMessageForInvalidField(foundField,message)
}

ด้วยสามฟังก์ชั่นเพิ่มเติม

  findInvalidField(fieldname){
    return this.invalidFields.find(value => { return value.name === fieldname })
  }

  addMessageForInvalidField(field,message){
    const errors = field.errors
    if (!doesErrorsContain(message)) {
      errors.push({ name: message, message })
    }
  }

  doesErrorsContain(message){
     return errors.some(error => error.name === message)
  }

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

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

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

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

ในตอนท้ายของวันที่ดีกว่าจะขึ้นอยู่กับคุณและทุกคนที่คุณทำงานด้วย ท้ายที่สุดนั่นคือผู้ที่จะอ่านและดูแลมัน