다른 팀에 있는 사람들도 알아볼 수 있는 이름을 사용하여 가독성을 최적화합니다.
대상의 목적이나 의도를 설명하는 이름을 사용하십시오.
새로운 독자가 코드를 즉시 이해할 수 있도록 하는 것이 훨씬 더 중요하므로 가로 공간 절약에 대해 걱정하지 마십시오.
프로젝트 외부의 누군가에게 알려지지 않았을 가능성이 있는 약어(특히 두문자어 및 이니셜)의 사용을 최소화하십시오.
단어 내에서 글자를 삭제하여 축약하지 마십시오. 경험에 비추어 볼 때 Wikipedia에 나열되어 있는 약어는 아마도 괜찮을 것입니다.
일반적으로 설명성은 이름의 가시성 범위에 비례해야 합니다.
예를 들어, n5줄 함수 내에서는 괜찮은 이름일 수 있지만 클래스 범위 내에서는 너무 모호할 수 있습니다.
// Good
class MyClass {
public:
int CountFooErrors(const std::vector<Foo>& foos) {
int n = 0; // Clear meaning given limited scope and context
for (const auto& foo : foos) {
...
++n;
}
return n;
}
void DoSomethingImportant() {
std::string fqdn = ...; // Well-known abbreviation for Fully Qualified Domain Name
}
private:
const int kMaxAllowedConnections = ...; // Clear meaning within context
};
// Bad
class MyClass {
public:
int CountFooErrors(const std::vector<Foo>& foos) {
int total_number_of_foo_errors = 0; // Overly verbose given limited scope and context
for (int foo_index = 0; foo_index < foos.size(); ++foo_index) { // Use idiomatic `i`
...
++total_number_of_foo_errors;
}
return total_number_of_foo_errors;
}
void DoSomethingImportant() {
int cstmr_id = ...; // Deletes internal letters
}
private:
const int kNum = ...; // Unclear meaning within broad scope
};
for문에서의 반복 변수의 경우 i, 템플릿 매개 변수의 경우 T와 같이 일반적으로 알려진 특정 약어는 괜찮습니다.
camel Case나 Pascal Case의 경우, 약어는 대문자로 표시하는 것을 선호합니다.
e.g. StartRpc() 보다는 StartRPC().
_) 또는 대시(-)를 포함할 수 있습니다
따라야 할 일관된 로컬 패턴이 없으면 _를 선호합니다..cc로 끝나야 하고 헤더 파일은 .h로 끝나야 합니다. (self-contained headers 참조)./usr/include와 같이 에 이미 있는 파일 이름을 사용하지 마십시오
예를 들어db.h.logs.h 대신 http_server_logs.h를 사용합니다.