Đặt tên: Bạn có nên hy sinh sự ngắn gọn cho rõ ràng?

Ví dụ, các hàm sau lặp qua một mảng chứa tên và lỗi của trường đầu vào. Nó thực hiện điều này bằng cách kiểm tra tên của trường xác thực và sau đó đẩy thông tin lỗi đến mảng trường không hợp lệ.

Có tốt hơn để được ngắn gọn và viết này:

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 })
  }
},

Hay cụ thể hơn như thế này?

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 })
  }
},

Nếu sự ngắn gọn có thể được hy sinh cho rõ ràng, nó nên. Nhưng nếu tính dài dòng có thể được hy sinh cho rõ ràng, thậm chí tốt hơn.

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 })
  }
},

Khi một biến chỉ sống miễn là một dòng thì nó thực sự có thể rất ngắn. FoundInvalidFieldđược sử dụng trong ba dòng và là trọng tâm của công việc này. Nó xứng đáng với một cái tên giải thích.

Như mọi khi, bối cảnh là vua.

Tôi thực sự ủng hộ ví dụ mã đầu tiên của bạn.

Rõ ràng những gì mã làm chỉ bằng cách đọc nó. Bằng cách giữ các tên biến càng nhỏ càng tốt, bạn làm cho mã dễ đọc hơn. Tên biến mô tả nhiều hơn sẽ chỉ cần thiết nếu các hàm của bạn dài hơn, các biến của bạn có số lượng nhiều hơn và / hoặc (các) biến được sử dụng trong phạm vi mã lớn hơn.

Đó là vì bạn đã giữ các chức năng của mình ngắn gọn mà bạn cũng có thể giữ các tên biến của mình ngắn gọn. Tất cả những thứ khác bằng nhau, ít mã hơn luôn luôn tốt hơn.

Tôi nghĩ rằng tôi đồng ý với chú Bob về việc thích sự rõ ràng mà không phải chịu sự dài dòng quá mức . Trong các ví dụ bạn trình bày, tôi sẽ nói rằng ý định của người thứ hai rõ ràng hơn mà không phát sinh sự dài dòng quá mức . Ngoài ra, sẽ dễ dàng hơn để tìm đoạn trích cụ thể đó khi tìm kiếm mặc dù cơ sở mã cho invalidFieldhơn value.

Chà, tôi đang trích dẫn Clean Code ở đây (bỏ qua nếu bạn chán ngấy với lời rao giảng của chú Bob (mà tôi thì không):

Sử dụng tên tiết lộ ý định

Thật dễ dàng để nói rằng tên nên tiết lộ ý định. Điều chúng tôi muốn gây ấn tượng với bạn là chúng tôi nghiêm túc trong việc này. Chọn tên tốt mất thời gian nhưng tiết kiệm nhiều hơn nó. Vì vậy, hãy cẩn thận với tên của bạn và thay đổi chúng khi bạn tìm thấy những cái tốt hơn. Mọi người đọc mã của bạn (bao gồm cả bạn) sẽ hạnh phúc hơn nếu bạn làm như vậy.

Tránh thông tin sai lệch

Các lập trình viên phải tránh để lại những manh mối sai lệch che khuất ý nghĩa của mã. Chúng ta nên tránh những từ có nghĩa cố định khác với từ của chúng ta

Tạo sự khác biệt có ý nghĩa

Các lập trình viên tự tạo ra các vấn đề khi họ viết mã chỉ để đáp ứng trình biên dịch hoặc trình thông dịch.

Sử dụng tên có thể tìm kiếm

Sử dụng các tên sẽ giúp bạn thực hiện grep -iIR whateveryouaresearching . (không phải là Mã sạch, ở đây CC chỉ nói về các biến chữ cái đơn).

Tránh ánh xạ tâm thần

Người đọc không cần phải dịch tên của bạn sang tên khác mà họ đã biết. Vấn đề này thường phát sinh từ một lựa chọn sử dụng cả thuật ngữ miền vấn đề cũng như thuật ngữ miền giải pháp.

Sử dụng tên miền có vấn đề

Khi không có lập trình viên-eese khác cho những gì bạn đang làm, hãy sử dụng tên từ miền vấn đề. Ít nhất là lập trình viên duy trì mã của bạn có thể hỏi một chuyên gia tên miền về ý nghĩa của nó.

Tôi luôn luôn chọn để được mô tả nhiều hơn trong những ngày này - hoàn thành mã IDE có nghĩa là bạn sẽ không phải viết tên biến mô tả để tôi không thể thấy nhược điểm.

Quay lại thời tiền sử, bạn đã bị hạn chế tên biến và sử dụng tên biến có ý nghĩa thực sự có thể phải chịu một chi phí có thể đo được (ví dụ: trong BBC BASIC sử dụng biến tĩnh số nguyên A%, v.v ... rẻ hơn nhiều so với sử dụng số nguyên có ý nghĩa - và trong hệ thống có 1 MHz bộ xử lý, lưu một vài chu kỳ xung nhịp trong một vòng lặp thực sự quan trọng)

Biến thể thứ hai trông khiến tôi hoang mang. Khi tôi chỉ nhìn vào chữ ký, tôi tự hỏi liệu lĩnh vực này đã được gọi là ong không hợp lệ? Hoặc nó sẽ được xác nhận đầu tiên (như nó được gọi validatingField), để tìm hiểu xem nó có thực sự không hợp lệ không? Vì vậy, đây không chỉ là thông tin dư thừa ở đây, thông tin bổ sung dường như có phần sai lệch. Loại "rõ ràng" này không rõ ràng hơn, nó ngược lại.

Thật ra, khi tôi thấy chức năng đầu tiên của bạn, nó cũng khiến tôi hoang mang. Tôi đã tự hỏi tại sao chức năng của bạn chỉ lấy một trường, nhưng sau đó không sử dụng nó và tìm kiếm một cái khác trong invalidFields? Tìm kiếm một lĩnh vực dường như có ý nghĩa hơn nhiều khi chỉ có một tên trường được đưa ra, như thế này:

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 })
  }
}

Tuy nhiên, tôi đoán Bob Martin có thể sẽ tiến thêm một bước và làm cho mã dài dòng hơn - để rõ ràng hơn - theo một hướng khác. Một cấu trúc lại điển hình dọc theo dòng của cuốn sách "Mã sạch" có thể sẽ trông như thế này:

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

với ba chức năng bổ sung

  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)
  }

Thật đáng tranh luận nếu nó được đền đáp để đi xa đến mức đó với nguyên tắc trách nhiệm duy nhất. Nó thực sự có một số ưu và nhược điểm. Quan điểm cá nhân của tôi là mã gốc "đủ sạch" cho hầu hết mã sản xuất, nhưng mã được tái cấu trúc thì tốt hơn.

Khi tôi biết rằng tôi phải thêm một cái gì đó vào biến thể đầu tiên để nó ngày càng phát triển hơn, tôi sẽ chia nó thành các hàm nhỏ hơn trước, vì vậy mã sẽ không bắt đầu trở thành một mớ hỗn độn.

Không có câu trả lời đúng trong việc đặt tên. Nhiều người khi được cung cấp cùng một nhóm tác vụ chính xác sẽ đặt tên cho các hàm và biến kết quả rất khác nhau. Tất nhiên bạn muốn những người khác đọc mã của bạn hiểu, nhưng lâu hơn không phải lúc nào cũng có nghĩa là một cái gì đó rõ ràng hơn. Nếu mã của bạn dày hơn thì nó cần phải như vậy thì nó sẽ mất nhiều thời gian hơn để hiểu ngay cả mọi dòng chức năng của bạn đều rõ ràng và mô tả như có thể.

Cá nhân, tôi thích ví dụ đầu tiên hơn. Nó thẳng và đến mức ngay cả với các biến không có tên mô tả như trong ví dụ thứ hai. Thành thật mà nói, các tên biến trong ví dụ thứ hai không rõ ràng hơn theo ý kiến ​​của tôi và việc giữ cho hàm ngắn gọn giúp bạn dễ hiểu chức năng hơn.

Vào cuối ngày, điều tốt hơn sẽ tùy thuộc vào bạn và bất cứ ai bạn làm việc cùng. Rốt cuộc, đó là người sẽ đọc nó và duy trì nó.