이름 지정 : 명확성을 위해 간략 성을 희생해야합니까?

예를 들어 다음 함수는 입력 필드의 이름과 오류가 포함 된 배열을 반복합니다. 유효성 검사 필드의 이름을 확인한 다음 오류 정보를 유효하지 않은 필드 배열로 푸시하면됩니다.

간단하고 작성하는 것이 낫습니다.

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세 줄로 사용되며이 작업의 초점입니다. 설명이 필요합니다.

언제나 그렇듯이 문맥은 왕입니다.

실제로 첫 번째 코드 예제를 선호합니다.

코드를 읽는 것만으로 코드의 기능을 분명히 알 수 있습니다. 변수 이름을 가능한 작게 유지하면 코드를보다 쉽게 ​​읽을 수 있습니다. 함수가 더 길고 변수가 더 많거나 변수가 더 큰 코드 범위에서 사용 된 경우에만 더 설명적인 변수 이름이 필요합니다.

변수 이름을 짧게 유지할 수 있도록 함수를 간략하게 유지했기 때문입니다. 다른 모든 것들은 같고 코드는 적을수록 좋습니다.

나는 과감한 표현을하지 않고 선명도 를 선호하는 Bob 아저씨와 동의한다고 생각 합니다 . 당신이 보여주는 예에서, 나는 두 번째 의도가 지나치게 자세하지 않고 더 명확하다고 말할 것 입니다. 또한에 대한 코드베이스 불구하고 검색 할 때 특정 조각을 쉽게 찾을 것 invalidField보다 value.

글쎄, 여기에 Clean Code를 인용하고 있습니다.

의도적 인 공개 이름 사용

이름이 의도를 드러내야한다는 것은 쉬운 일입니다. 우리가 당신에게 감명을주고 싶은 것은 우리가 이것에 대해 진지하다는 것입니다. 좋은 이름을 선택하면 시간이 걸리지 만 시간이 많이 걸립니다. 따라서 이름을 잘 관리하고 더 나은 이름을 찾으면 이름을 변경하십시오. 귀하의 코드를 읽는 모든 사람 (귀하를 포함하여)이 더 행복 할 것입니다.

변형을 피하십시오

프로그래머는 코드의 의미를 모호하게하는 잘못된 단서를 남기지 않아야합니다. 우리는 확고한 의미가 우리와 다른 단어를 피해야합니다

의미있는 구별

프로그래머는 컴파일러 나 인터프리터를 만족시키기 위해 코드를 작성할 때 스스로 문제를 일으 킵니다.

검색 가능한 이름 사용

당신이 어떻게 도움이 이름을 사용합니다 grep -iIR whateveryouaresearching . (여기가 아닌 클린 코드를 CC는 단일 문자 변수에 대해 이야기).

정신 매핑 방지

독자는 자신의 이름을 이미 알고있는 다른 이름으로 정신적으로 번역 할 필요가 없습니다. 이 문제는 일반적으로 문제 도메인 용어 나 솔루션 도메인 용어를 사용하지 않기 위해 선택됩니다.

문제 도메인 이름 사용

당신이하고있는 것에 대해“프로그래머-이즈”가 없다면, 문제 도메인의 이름을 사용하십시오. 최소한 코드를 관리하는 프로그래머는 도메인 전문가에게 그 의미를 물어볼 수 있습니다.

나는 요즘 항상 더 설명하기를 선택했습니다. IDE 코드 완성은 설명 변수 이름을 작성할 필요가 없으므로 단점을 볼 수 없습니다.

예전에는 변수 이름 제한이 있었으며 의미있는 변수 이름을 사용하면 실제로 측정 가능한 비용이 발생할 수 있습니다 (예 : 정수 정적 변수 A % 등을 사용하는 BBC BASIC에서는 의미있는 정수를 사용하는 것보다 훨씬 저렴했습니다-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 })
  }
}

그러나 Bob Martin은 한 걸음 더 나아가 코드를 더 명확하게하기 위해 다른 방향으로 더 장황하게 만들 것입니다. "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)
  }

단일 책임 원칙으로 멀리 나아가는 것이 돈을 지불한다면 논쟁의 여지가 있습니다. 실제로 몇 가지 장단점이 있습니다. 필자의 개인적 관점은 원래 코드가 대부분의 프로덕션 코드에 대해 "충분히 깨끗하다"고 리팩토링 된 코드가 더 낫다는 것입니다.

내가 첫 번째 변형에 무언가를 추가해야 점점 더 커질 것이라는 것을 알았을 때 미리 작은 함수로 나누면 코드가 엉망이되지 않습니다.

명명에는 일반적으로 정답이 없습니다. 똑같은 작업 세트가 주어지면 많은 사람들이 결과 함수와 변수의 이름을 매우 다르게 지정할 것입니다. 물론 코드를 읽는 다른 사람들이 이해하기를 원하지만 더 길다고해서 항상 무언가가 더 명확하지는 않습니다. 코드가 밀도가 높으면 함수의 모든 라인이 가능한 한 명확하고 설명적임을 이해하는 데 더 많은 시간이 걸립니다.

개인적으로, 나는 첫 번째 예를 더 좋아합니다. 변수가 두 번째 예에서와 같이 설명적인 이름을 갖지 않아도 똑바로 나타납니다. 솔직히 두 번째 예제의 변수 이름은 첫 번째 변수보다 명확하지 않으며 함수를 간략하게 유지하면 함수 자체를 쉽게 이해할 수 있습니다.

하루가 끝날 때, 더 나은 것이 당신과 함께 일하는 사람에게 달려 있습니다. 결국, 그것은 그것을 읽고 유지하는 사람입니다.