예를 들어, 지역 및 매개 변수 변수에 대한 명명 규칙 [닫힘]


13

프로젝트 (주로 Java / JEE 프로젝트)에 적용하기 위해 선임 개발자 코딩 규칙에 대해 논의했습니다. 나는 그가 제안한 한 가지 규칙에 동의하지 않았다.

인스턴스 변수 이름은 "_"로 시작하고 로컬 변수는 "loc"이고 메서드 매개 변수는 "par"로 시작해야 변수 원점과 범위를 쉽게 식별 할 수 있습니다.

그는 단기 기억력과 가독성에 대한 논쟁을 제기했지만, 가독성이 오히려 줄어든다는 사실에 동의하지 않았다. Eclipse 형식 변수와 같은 IDE는 유형에 따라 다르며 클래스와 메소드 디자인이 좋으면 이러한 문제를 피할 수있다.

내 요점을지지하거나 반대하는 의견, 주장 또는 연구가 있습니까?


당신은 당신이 "가독성을 오히려 감소 시킨다는 사실"에 동의하지 않았다고 말합니다. 나는 당신이 틀렸다고 말하는 것이 아니라 그 주장을 뒷받침하기 위해 어떤 증거를 제공 했습니까? (이 나에게 관심의 영역이 그래서, 나는 개발자가되기 전에 대학원 심리학에서인지 공부했다.) 나는 가독성을 감소 말한다 어떤 연구를 잘 모르는 것 같아요
AdamJonR

혼란 스럽기 때문에 의미했습니다. 그러나 나는 개인적인 견해 외에 다른 증거는 없다
HH

접두사는 코드에 이미 포함되어 있고 반 정도의 환경에 표시되는 정보를 복제합니다. 우리 모두 알다시피 중복 정보가 일치하지 않을 수 있습니다. DRY는 접두사를 사용하지 않도록 지시해야합니다.
Julia Hayward

답변:


15

Wikipedia 가 주제에 대해 말한 것처럼 -Java 명명 규칙

로컬 변수, 인스턴스 변수 및 클래스 변수도 lowerCamelCase로 작성됩니다. 변수 이름은 모두 밑줄 (_) 또는 달러 기호 ($)로 시작해서는 안됩니다. 특정 코딩 규칙에 따르면 읽기 및 프로그램 이해를 향상시키기 위해 모든 인스턴스 변수 앞에 밑줄을 사용해야합니다.

코딩 표준에 대한 나의 경험에 따르면, 인스턴스 변수 이름은 "_"로 시작하는 것이 위키 백과 표준에서 말하는 것만 큼 좋지 않습니다.

변수 원점과 범위를 쉽게 식별 할 수 있다고 말했듯이 "loc"이있는 지역 변수와 "par"이있는 메소드 매개 변수 .

당으로 청소 코드 방법에 대한 사양이 짧은만큼 그들은 당신이 마음에 매핑하지 않아야한다 가독성과 변수 이름을 할 수 있어야한다, 그들은 당신의 방법을 수행하는 것이 당신의 작업과 관련이 있어야한다.

멤버 / 스코프 접두사, 더 이상 멤버 변수 앞에 m_을 붙일 필요가 없습니다. 클래스와 함수는 필요하지 않을 정도로 작아야합니다. 또한 멤버를 강조하거나 색상을 지정하여 구별되도록 편집 환경을 사용해야합니다.

public class Part {
private String m_dsc; // The textual description
void setName(String name) {
m_dsc = name;
}
}

public class Part {
String description;
void setDescription(String description) {
this.description = description;
}
}

게다가 사람들은 이름의 의미있는 부분을보기 위해 접두사 (또는 접미사)를 무시하는 법을 빨리 배웁니다. 코드를 많이 읽을수록 접두사를 적게 볼 수 있습니다. 결국 접두사는 보이지 않는 혼란과 오래된 코드의 마커가됩니다.


4

이것은 오래된 질문이지만 어쨌든 여기에 게시 할 것입니다. 나는 약 20 년 이상의 프로그래밍과 다른 사람들의 코드를 다루고 있습니다.

범위에 대한 짧은 표시로 변수 이름을 지정하면 실제로 코드를 볼 다음 사람 (또는 자신)에게 유용하다고 생각합니다.

하나는 이미 예쁜 색상의 IDE에서 코드를 보지 못합니다 (색상의 의미와 다른 IDE가 다른 색상을 표시하는 것을 기억하지 못합니다).

사실, 메소드는 너무 짧아서 수많은 변수와 수많은 코드가로드되지 않지만 짧은 코드조차도로드되지 않습니다-완전히 익숙하지 않은 코드를 볼 때 때로는 변수가 클래스 변수인지 로컬인지 알기가 어렵습니다. 변수 또는 메소드 매개 변수.

한 눈에 구별 할 수 있으면 익숙하지 않은 코드를 매우 쉽게 검토 할 수 있습니다.

이 예제를 보자 :

public <T> Page<T> moreLikeThis(MoreLikeThisQuery query, Class<T> clazz) {
    int startRecord = 0;
    ElasticsearchPersistentEntity persistentEntity = getPersistentEntityFor(clazz);
    String indexName = isNotBlank(query.getIndexName()) ? query.getIndexName() : persistentEntity.getIndexName();
    String type = isNotBlank(query.getType()) ? query.getType() : persistentEntity.getIndexType();

    Assert.notNull(indexName, "No 'indexName' defined for MoreLikeThisQuery");
    Assert.notNull(type, "No 'type' defined for MoreLikeThisQuery");
    Assert.notNull(query.getId(), "No document id defined for MoreLikeThisQuery");

    MoreLikeThisRequestBuilder requestBuilder = client.prepareMoreLikeThis(indexName, type, query.getId());

    if (query.getPageable() != null) {
        startRecord = query.getPageable().getPageNumber() * query.getPageable().getPageSize();
        requestBuilder.setSearchSize(query.getPageable().getPageSize());
    }
    requestBuilder.setSearchFrom(startRecord);

    if (isNotEmpty(query.getSearchIndices())) {
        requestBuilder.setSearchIndices(toArray(query.getSearchIndices()));
    }
    if (isNotEmpty(query.getSearchTypes())) {
        requestBuilder.setSearchTypes(toArray(query.getSearchTypes()));
    }
    if (isNotEmpty(query.getFields())) {
        requestBuilder.setField(toArray(query.getFields()));
    }
    if (isNotBlank(query.getRouting())) {
        requestBuilder.setRouting(query.getRouting());
    }
    if (query.getPercentTermsToMatch() != null) {
        requestBuilder.setPercentTermsToMatch(query.getPercentTermsToMatch());
    }
    if (query.getMinTermFreq() != null) {
        requestBuilder.setMinTermFreq(query.getMinTermFreq());
    }
    if (query.getMaxQueryTerms() != null) {
        requestBuilder.maxQueryTerms(query.getMaxQueryTerms());
    }
    if (isNotEmpty(query.getStopWords())) {
        requestBuilder.setStopWords(toArray(query.getStopWords()));
    }
    if (query.getMinDocFreq() != null) {
        requestBuilder.setMinDocFreq(query.getMinDocFreq());
    }
    if (query.getMaxDocFreq() != null) {
        requestBuilder.setMaxDocFreq(query.getMaxDocFreq());
    }
    if (query.getMinWordLen() != null) {
        requestBuilder.setMinWordLen(query.getMinWordLen());
    }
    if (query.getMaxWordLen() != null) {
        requestBuilder.setMaxWordLen(query.getMaxWordLen());
    }
    if (query.getBoostTerms() != null) {
        requestBuilder.setBoostTerms(query.getBoostTerms());
    }

    SearchResponse response = requestBuilder.execute().actionGet();
    return resultsMapper.mapResults(response, clazz, query.getPageable());
}

이제 스스로 시간을내어 코드를 살펴보십시오 (Spring-Data-elasticsearch 프로젝트에서 추출한 ElasticsearchTemplate에서 추출한 코드-사람들이 명명 규칙에 대해 말하는 내용을 Google에서 검색하도록 유도 한 코드입니다).

  • 의 코드는 무엇입니까 resultsMapper?
  • requestBuilding매개 변수는?
  • 기타...

변수 이름을 지정하는 방법에 대한 간단한 제안은 다음과 같습니다.

  • 클래스 정적 속성 (예 : 상수) : ALL_CAPS_WITH_UNDERSCORES (예 :) HOST_NAME.
  • 클래스 속성 (예 : 클래스 인스턴스 변수) : camelCase (예 :) resultsMapper.
  • 메소드 파라미터 : 접두사 a(예를 들어 aQuery, aClazz).
  • 지역 변수 : 접두사 my(예를 들어 myIndexName, myType).

위의 코드는 다음과 같습니다.

public <T> Page<T> moreLikeThis(MoreLikeThisQuery aQuery, Class<T> aClazz) {
  int myStartRecord = 0;
  ElasticsearchPersistentEntity myPersistentEntity = getPersistentEntityFor(aClazz);
  String myIndexName = isNotBlank(aQuery.getIndexName()) ? aQuery.getIndexName() : myPersistentEntity.getIndexName();
  String myType = isNotBlank(aQuery.getType()) ? aQuery.getType() : myPersistentEntity.getIndexType();

  Assert.notNull(myIndexName, "No 'indexName' defined for MoreLikeThisQuery");
  Assert.notNull(myType, "No 'type' defined for MoreLikeThisQuery");
  Assert.notNull(aQuery.getId(), "No document id defined for MoreLikeThisQuery");

  MoreLikeThisRequestBuilder myRequestBuilder = client.prepareMoreLikeThis(myIndexName, myType, aQuery.getId());

  if (aQuery.getPageable() != null) {
     myStartRecord = aQuery.getPageable().getPageNumber() * aQuery.getPageable().getPageSize();
     myRequestBuilder.setSearchSize(aQuery.getPageable().getPageSize());
  }
  myRequestBuilder.setSearchFrom(myStartRecord);

  if (isNotEmpty(aQuery.getSearchIndices())) {
     myRequestBuilder.setSearchIndices(toArray(aQuery.getSearchIndices()));
  }
  if (isNotEmpty(aQuery.getSearchTypes())) {
     myRequestBuilder.setSearchTypes(toArray(aQuery.getSearchTypes()));
  }
  if (isNotEmpty(aQuery.getFields())) {
     myRequestBuilder.setField(toArray(aQuery.getFields()));
  }
  if (isNotBlank(aQuery.getRouting())) {
     myRequestBuilder.setRouting(aQuery.getRouting());
  }
  if (aQuery.getPercentTermsToMatch() != null) {
     myRequestBuilder.setPercentTermsToMatch(aQuery.getPercentTermsToMatch());
  }
  if (aQuery.getMinTermFreq() != null) {
     myRequestBuilder.setMinTermFreq(aQuery.getMinTermFreq());
  }
  if (aQuery.getMaxQueryTerms() != null) {
     myRequestBuilder.maxQueryTerms(aQuery.getMaxQueryTerms());
  }
  if (isNotEmpty(aQuery.getStopWords())) {
     myRequestBuilder.setStopWords(toArray(aQuery.getStopWords()));
  }
  if (aQuery.getMinDocFreq() != null) {
     myRequestBuilder.setMinDocFreq(aQuery.getMinDocFreq());
  }
  if (aQuery.getMaxDocFreq() != null) {
     myRequestBuilder.setMaxDocFreq(aQuery.getMaxDocFreq());
  }
  if (aQuery.getMinWordLen() != null) {
     myRequestBuilder.setMinWordLen(aQuery.getMinWordLen());
  }
  if (aQuery.getMaxWordLen() != null) {
     myRequestBuilder.setMaxWordLen(aQuery.getMaxWordLen());
  }
  if (aQuery.getBoostTerms() != null) {
     myRequestBuilder.setBoostTerms(aQuery.getBoostTerms());
  }

  SearchResponse myResponse = myRequestBuilder.execute().actionGet();
  return resultsMapper.mapResults(myResponse, aClazz, aQuery.getPageable());

}

완벽합니까? 나는 그렇게 생각하지 않습니다. 그러나 변수에 관한 한, 위의 내용을보다 쉽게 ​​읽을 수 있습니다. 정렬 및 간격과 같은 다른 것들이 있는데, 질문과 관련이 없기 때문에이 답변에 들어 가지 않을 것이므로 읽기가 더 쉽습니다.

낙타 케이스가 마음에 들지 않습니까? 밑줄 등을 사용하되, 로컬 변수와 매개 변수를 접두사로 사용하여 클래스 인스턴스 변수와 다르게 만듭니다.

당신은 싫어 a하고 my단지 다른 프로젝트에 사용 뭔가 내에서 일관성을 유지, 잘 ...하지만 사용 무언가를 -.

규칙 # 1 : 프로젝트 내 일관성.

규칙 # 2 : 읽기 쉽게하고 독자가 배우기 전에 모든 것을 알 필요는 없습니다.


3

이것은 주로 선호의 문제이므로 '올바른'답변이 없습니다. 따라서이 질문은 실제로 닫힐 수 있습니다. 그러나 그 전에, 나는 당신에게 전적으로 동의한다고 말할 것입니다. 접두사는 내가 생각하는 한 가시성을 줄입니다. 접두사가 있어야하는 경우 헝가리어 표기법의 원래 의도 와 같이보다 유용한 것들에 사용해야하며 IDE가 어쨌든 강조 표시를 제공 할 수있는 것은 아닙니다.

인스턴스 데이터 (변수 또는 상수)에 대해서는 SentenceCase를 사용하고 매개 변수 및 로컬 변수에 대해서는 lower_case를 사용합니다. 둘 사이에는 차이가 거의 없기 때문입니다. headlessCamelCase 는 절름발이 이기 때문에 결코 사용하지 않습니다 . 단일 구성 요소 식별자는 headlessCamelCase로 의도 된 경우에도 소문자처럼 보입니다.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.