지역 변수에서 첫 단어에 소문자를 사용하는 이유는 무엇입니까 (예 : employeeCount, firstName)


20

모든 변수에 대해 적절한 케이싱을 사용하기 때문에 다른 프로그래머로부터 많은 비판을받습니다. 예를 들어 일반적인 프로그래머는 employeeCount변수 이름을 사용하지만을 사용 EmployeeCount합니다. void 메소드, return 메소드, 변수, 속성 또는 상수 등 모든 것에 대해 적절한 케이싱을 사용 합니다. 심지어 Javascript 에서이 규칙을 따릅니다. 마지막은 사람들의 지미를 진정으로 약화시킵니다.

이 "비표준"케이싱 규칙을 따르지 말아야하는 일반적인 이유는 속성과 void 메서드에 대해 적절한 대소 문자를 모두 예약해야하기 때문입니다. 값을 반환하는 지역 변수와 메소드는 첫 단어가 소문자로되어 있어야합니다 int employeeCount = getEmployeeCount().

그러나 나는 왜 그런지 이해하지 못한다.

내가 이것에 의문을 가질 때, 나는 그것이 표준이라는 임의의 대답을 얻는 것처럼 보입니다 . 답이 무엇이든간에, 그것은 항상 비등합니다. 그것이 바로 그 방법입니다. 그리고 나는 그것을 질문하지 않습니다. 그냥 따라가 . 임의의 대답은 나에게 충분하지 않습니다.

Office IDE로 Excel 97 매크로를 프로그래밍 한 초기부터 로컬 변수 또는 속성인지 여부를 알려주는 케이싱 규칙이 없었습니다. 이것은 항상 매우 직관적 인 명명 규칙을 사용했기 때문입니다. 예를 들어 GetNuggetCount()어딘가로가는 방법이 모든 너겟의 수를 얻는 방법을 분명히 제안합니다. SetNuggetCount(x)너겟 수에 새로운 값을 할당 할 것을 제안합니다. NuggetCount모두 자체적으로 단순히 값을 보유하는 속성 또는 로컬 변수를 제안합니다. 마지막으로, "아하! 그것은 질문이다. 재산 또는 변수? IT는 누구인가?" "정말 중요한가요?"

그래서 여기에 tl; dr;가 있습니다 : 변수 또는 반환 방법의 첫 단어에 소문자를 사용해야하는 객관적이고 논리적이며 비 임의적 인 이유는 무엇입니까?

편집 : MainMa

대체 답변의 첫 번째 코드 샘플 코드 및 인수가 보유하고 얼마나 잘 참조 :

public void ComputeMetrics()
{
    const int MaxSnapshots = 20;

    var Snapshots = this.LiveMeasurements.IsEnabled ?
        this.GrabSnapshots(MaxSnapshots, this.cache) :
        this.LoadFromMemoryStorage();

    if (!Snapshots.Any())
    {
        this.Report(LogMessage.SnapshotsAreEmpty);
        return;
    }

    var MeasurementCount = Measurements.Count();
    this.Chart.Initialize((count + 1) * 2);

    foreach (var s in Snapshots)
    {
        this.Chart.AppendSnapshot(s);
    }
}

7
만약 그들이 대문자라면 왜 그들이 소문자가 아닌지 묻는 다른 사람이있을 것입니다.
m3th0dman

11
강력한 IDE가 이와 같은 문체 문제에 대한 개인적인 선호도를 매핑하고 소스 파일의 "실제 버전"에 대해 장면 뒤에서 사용할 수있게하는 플러그인을 가질 수 있다면 좋지 않을 것입니다. "프로젝트"스타일 의미론. 공식 파일 버전을 감사해야 할 때까지는 완전히 시각적 인 문제입니다. 그냥 꿈꾸고 ...
Sassafras_wot

59
불행히도, 실제적이고 유효한 이유는 "표준이기 때문에"입니다. 동일한 팀의 사람들이 동일한 코드 스타일 표준을 따르는 것이 비용을 지불합니다. 이유를 알 수 없다면 "표준이 왜 유용한가?"라는 또 다른 질문을해야 할 것입니다.
Andres F.

3
나는 항상 개발자가 낙타처럼 보이기 때문에 낙타 케이스에 정착했다고 가정했습니다. PascalCase보다 camelCase 자체에 대한 객관적인 이유는 없습니다 . 개인적으로 PascalCase (예 : 귀하의 예제와 같이)가 읽기 쉽고 JavaScript가 아닌 대부분의 장소에서 사용하여 camelCase와 함께 사용하므로 파티 초대장을 놓치지 않습니다.
GrandmasterB

7
표준 코딩 스타일의 장점에 대한 연구 표준이 무엇인지, 중요하지는 않습니다.
Mr.Mindor 2016 년

답변:


88

이 명명 규칙은 사람들이 변수 유형과 동일한 이름을 부여하려고 할 때 종종 사용됩니다. 예를 들면 다음과 같습니다.

Employee employee;

일부 언어는 그 대문자를 강제합니다. 같은 성가신 변수 이름을 사용하는 데이 방지는 MyEmployee, CurrentEmployee, EmployeeVar뭔가 그냥 총액에서 종류 나 변수 인 경우 등 당신은 항상 알 수 있습니다. 다음과 같은 상황에서 혼란을 방지합니다.

employee.function(); // instance method
Employee.function(); // static method

또한 영어에서는 명사가 일반적으로 대문자가 아니므로 대문자가 "적절하다"고 주장 할 수 없습니다.

그렇다면 그것은 당신의 상황과 어떤 관련이 있습니까? 분명히 자신의 코드를 읽는 데 문제가 없지만 가능한 한 일관성있게 유지하면 코드를 읽어야하는 다른 사람의 정신적 작업량을 줄일 수 있습니다. 글씨처럼 코딩에서 독자와 일치하도록 스타일을 조정하십시오.


1
속성은 대문자로 표시되기 때문에 OP에서 사용하는 언어로 문제가 여전히 존재한다는 점에 유의하십시오 this..
Arseni Mourzenko 2018 년

1
@oscilatingcretin을 PascalCase라고합니다.
Mr.Mindor 2016 년

21
Employee Employee작동하지만 나는 그것이 인간 독자에게는 더 혼란 스럽다고 주장 할 것입니다 Employee employee. 후자는 두 가지 다른 것처럼 보입니다. 첫 번째는 불필요한 반복처럼 보입니다.
Jamie F

14
@oscilatingcretin 정확히 : "독자가 기본 프레임 워크를 이해한다고 가정합니다 ..."JavaScript, Java, C #, C ++ 등을 읽고 머릿속에서 코드를 번역하고 싶습니다. "아,이 언어의 컴파일러는 x를 다룰 수 있습니다 ."라고 계속 생각할 필요는 없습니다 . 코드의 의미를 얻으려고합니다.
Jamie F

1
employee.function()(자바하는 것처럼) 언어가 객체에서 정적 메서드를 호출 할 수있는 경우 또한, 정적 방법이 될 수 있습니다. 컴파일러는 경고를하지만 그렇게 할 수 있습니다.
우우

34

없어요 그것은 대부분의 사람들이하는 일이므로 모든 사람들이하는 일이기 때문에 표준이되었습니다. 많은 관습이이 관례를 따르므로 사람들은 습관을 들었습니다.

규칙은 코드 전체의 일관성만큼 중요하지 않습니다. 모든 것이 일관된 방식으로 이름이 지정되어있는 것만으로도 내가 볼 수있는 것이 무엇인지 알 수있는 한, 첫 글자가 대문자인지 여부는 중요하지 않습니다.

나는 당신의 방식으로 작성된 코드를 발견하는 것이 부적절하다고 생각하며 그것을 좋아하지 않는다고 말할 것입니다. 그러나 그것은 스타일의 문제입니다.

이제 직장에서이 작업을 수행하는 경우 팀 스타일로 코딩하는 것이 더 좋으므로 코드가 모든 곳에서 일관되게 유지됩니다. 코드를 다른 사람과 다르게 만드는 것보다는

http://thecodelesscode.com/case/94


3
대부분의 프로그래머가 당신과 같기를 바랍니다. 많은 사람들이 내가 언급 한 케이싱 표준을 따르는 것에 대해 의심스럽고 열정적입니다.
oscilatingcretin

1
@Schieis는 프로젝트에서 다음 작업을 할 프로그래머가 중요합니다.
N4TKD 2016 년

3
@oscilatingcretin 코드가 가득한 작업을 마치면 열정적이고 독창적으로 행동하게 될 수 있습니다 var m_someVariableID = GetVariableValueId(). 특히 자동 완성 지원 없이 수행 해야하는 경우 .
Tacroy 2016 년

7
팀원 인 경우 해당 팀 표준을 따르는 것이 중요합니다. 그러나 많은 프로그래밍 언어에는 팀에 표준이없는 (또는 팀이 표준을 설정하도록 연기 한 위치) 새 프로젝트를 작성할 때 따라야하는 사실상의 표준이 있습니다. 어떤 코딩 규칙을 사용해야할지 확실하지 않은 경우 표준을 정당화 할 수 없다면 기본 언어 공급 업체 또는 포함 된 프레임 워크에서 사용하는 규칙을 따르는 것이 자신의 표준보다 선호됩니다.
Brian

2
@ Schleis 좋은 업데이트, 나는 그것이 단지 스타일의 문제라는 것에 동의하지 않지만, 컨벤션과 컨벤션은 좋은 이유로 컨벤션이되며 따라야합니다. 그것은 종교가 아니며 언젠가는 대회를 거쳐야만하지만 그럴만한 이유가 있습니다.
N4TKD

25

1. 왜 표준이 존재합니까?

결국, 모든 사람이 개인 취향에 따라 코드를 작성하고 어떤 표준이 더 나은지에 대해 이야기하는 것을 멈추는 것이 더 좋지 않을까요?

사실 한 스타일에 익숙해지면 다른 스타일을 사용하는 코드를 읽기가 더 어렵습니다. 뇌는 코드가하는 일을 이해하는 대신, 규칙이있는 경우 이해하는 데 더 많은 시간을 보냅니다.

이 두 코드 사이에서 더 읽기 쉬운 것은 무엇입니까?

public void comp_metrics ()
{
  int Count;
  List<snapshot> measurements=fromMemoryStorage();
  if (_liveMeasurements.enabled)
    measurements = GrabSnapshots(20, _cache);
    if( !measurements.Any() ) {
        this.Report(LogMessage.Measurements_Are_Empty); return;
    }

    Count = measurements.Count ();

    this.Chart.initialize(( Count + 1 )*2);

    foreach(snapshot S in measurements) {
      this.Chart.append_Snapshot ( S );
    }
}

또는:

public void ComputeMetrics()
{
    const int MaxSnapshots = 20;

    var snapshots = this.liveMeasurements.isEnabled ?
        this.GrabSnapshots(MaxSnapshots, this.cache) :
        this.LoadFromMemoryStorage();

    if (!snapshots.Any())
    {
        this.Report(LogMessage.SnapshotsAreEmpty);
        return;
    }

    var count = measurements.Count();
    this.Chart.Initialize((count + 1) * 2);

    foreach (var s in snapshots)
    {
        this.Chart.AppendSnapshot(s);
    }
}

두 코드 조각 모두 비슷하게 실행됩니다. 유일한 차이점은 첫 번째 경우 프로젝트를 수행 한 각 개발자가 자신의 스타일을 사용했다는 것입니다. 이로 인해 코드가 일관성이없고 읽을 수없고 위험 해졌습니다. 모든이 후 팀의 구성원 중 하나가 중괄호를 사용을 거부했다는 사실과 함께 들여 쓰기 크기에 대해 동의 할 수 없습니다 사실 if코드가 매우 쉬운 오류 만든이 : 그것을보고 우리는 두 번째가 있다고 생각 할 수 if있다 첫 번째 if가 참일 때만 실행되며 , 그렇지 않습니다.

두 번째 경우 모든 개발자가 동일한 표준을 따랐습니다. 그들 중 일부는 두 개의 공백 들여 쓰기를 선호했거나 작은 문자로 시작하는 방법에 익숙했기 때문에 불행했을 것입니다. 사실 코드는 여전히 이런 방식으로 훨씬 더 읽기 쉽고 다른 표준을 사용하는 경우에도 마찬가지입니다.

엄격하고 균일 한 표준을 사용하면 코드를보다 쉽게 ​​읽을 수 있습니다.

2. 내가 지금 발명 한 것보다 표준이 더 좋은 이유 무엇 입니까?

전 세계 수십만 명의 개발자가 표준을 사용하는 경우 표준에 충실하십시오. 나만의 것을 발명하지 마십시오. 더 나아지더라도 수십만 명의 개발자가 아닌 글로벌 표준으로 마이그레이션하는 것이 더 쉽습니다.

예 : 내 회사에는 데이터베이스에서 기본 및 외래 키와 인덱스의 이름을 지정하는 특정 규칙이 있습니다. 그 이름은 다음과 같습니다.

  • [FK for Application: CreatedByApplicationId],
  • [IX for SessionIPAddress: SessionId] 또는
  • [PK for RoleOfPassword: RoleId, PasswordId].

개인적으로 저는이 협약이 훌륭하고 매우 명확하다고 생각합니다. 나를 위해. 그러나 그것은 완전히 짜증납니다. 그것은 내 것이기 때문에 수천 명의 데이터베이스 관리자 중 아무도 그것을 사용하지 않았기 때문에 짜증납니다. 이것은 다음을 의미합니다.

  • 내가 DBA를 고용 할 때, 그는 지금 당장 그의 일을 시작하는 대신 새로운 협약을 배우도록 강요받을 것이다.

  • 인터넷에서 코드를 그대로 공유 할 수는 없습니다. 이상하게 보이는 이름은 내 코드를 읽는 사람들을 방해 할 것입니다.

  • 내가 직접 사용하기 위해 외부에서 코드를 가져 가면 코드를 균일하게 만들기 위해 이름을 수정해야합니다.

  • 언젠가 잘 알려진 표준을 사용하기로 결정하면 몇 백 가지 이름을 모두 수정해야합니다.

3. 그렇다면 대문자는 어떻습니까?

속성은 필드 또는 로컬 변수보다 더 넓은 범위 또는 가시성을 갖습니다. 속성은 대문자로 시작하고 필드와 변수는 작은 방향으로 시작합니다.

C #을 고려하면이 논리는 충분히 일관성이 있습니다.

Java를 고려하면 메소드는 작은 문자로 시작하며 논리를 따르지 않습니다.

따라서,이 협약이 당신보다 낫다는 확실한 증거는 없습니다. 하나는 전 세계적으로 사용되며 귀하는 그렇지 않습니다. 아무도 없습니다 더 나은 .

JavaScript에서 함수는 new앞에 문자가 필요하지 않으면 작은 문자로 시작 합니다. 다른 방법으로는 더 나을까요? 아마도. 사실, JavaScript 개발자들은 수년 동안이 표준을 사용했지만 그 반대는 아닙니다. 모든 책을 다시 작성하고 모든 개발자가 스타일을 변경하도록 강요하면 이제 약간 복잡합니다.


1
코드가 약간 다른 표준을 따르기 때문에 읽기가 쉽지 않은 부분에 대해서는 그 문제가 없었습니다. 다른 사람의 변수에 이름을 hookyDookyDoo지정하지 않으면 명명 또는 대 / 소문자 구분 규칙이 가독성을 떨어 뜨리지 않습니다. 또한 컨벤션이 dev 테이블에 특별한 것을 가져 오지 않기 때문에 컨벤션이 "더 나은"것은 아닙니다. 마지막으로, [속성에 더 큰 범위가 있습니다 ...이 방향으로 간다]는 당신의 요점을 이해하지 못합니다 . 스코프는 케이싱 규칙과 어떤 관련이 있습니까? 어떤 방향으로가요?
oscilatingcretin

23
@oscilatingcretin, 문제가 있는지없는 당신이 한 지금까지 그 문제를 가지고, 당신의 여부의 동료가 있습니다. 분명히 그들은 가지고 있거나 불평하지 않을 것입니다.
Karl Bielefeldt

1
재 : 편집 : 첫 번째 코드 예제는 잘못 구성되고 재난이 발생하기 쉬운 코드를 보여줍니다. 내 OP는 잘못 구성되고 재난이 발생하기 쉬운 코드가 아닙니다. 두 번째 예제와 정확히 동일한 코드이지만 케이싱 규칙이 다릅니다. 두 번째 코드 예제를 편집하여 케이싱 규칙을 사용하여 OP에 게시했습니다. 첫 번째 코드 예제로 바꾸십시오.
oscilatingcretin

5
@oscilatingcretin : 첫 번째 코드 예제는 잘못 구성된 코드가 아니라 모든 개발자가 자신의 스타일을 따르는 팀이 작성한 코드를 보여줍니다. 시간이 충분하면 (예 : 5 년) 너무 많은 코드베이스에서 발생합니다. 참고 : "실제로이 방법으로 코드를 훨씬 더 쉽게 읽을 수 있으며 다른 표준을 사용중인 경우에도 마찬가지입니다." ?
Arseni Mourzenko 2016 년

6
@oscilatingcretin 일관성은 읽고있는 것을 이해하는 데 필요한인지 노력을 크게 감소 시킨다는 많은 연구가 있습니다. 규칙적인 산문, 철자법, 구두점 및 문법이 까다로워지면 의식적으로인지 여부와 상관없이 누군가가 읽기가 어렵습니다. "공통 표준"(선택한 기술 스택에 대한) 준수는 전반적인 일관성을 높이고 코드가 수행하는 방식 대신 중요한 비즈니스에 집중할 수 있도록 뉴런을 자유롭게합니다. 이렇게 적혀있다.
Bevan 2016 년

10

기술적으로는 중요하지 않습니다 (또는 적어도 대부분의 언어에서는 중요하지 않습니다).

그러나 대부분의 프로그래밍 커뮤니티 (특정 언어를 중심으로하는 월드 와이드 커뮤니티, 커뮤니티의 하위 그룹, 인기있는 라이브러리 나 툴킷 주위에 형성된 그룹 또는 개별 팀 등)는 확립 된 코딩 표준을 개발했습니다. 정확한 세부 사항은 (많은 경우에, 좋은 인수가 그들을 위해 할 수 있지만) 상대적으로 중요하지, 어떤 있습니다 중요한 것은 당신이 그들에 충실한다는 것입니다.

그들이 최고이기 때문이 아니라 다른 사람들이 사용하는 것이기 때문입니다. 표준을 고수하면 코드는 라이브러리, 팀원 코드, 언어 내장을 사용하여 결국 다른 코드와 대부분 일치합니다. 일관된 이름 지정은 강력한 생산성 무기 중 하나입니다. 이는 무언가의 이름을 추측 할 때 일반적으로 올바른 추측을 의미하기 때문입니다. 그것이 file.SaveTo(), File.saveTo(), file.save_to(),FILE.save_to() ? 명명 규칙이 알려줄 것입니다.

모든 언어에 대해 개인 선호도를 갖는 것은 특히 위험합니다. 무엇보다도 모든 언어에는 고유 한 문화가 있으며 명명 규칙은 종종 호환되지 않기 때문입니다. 둘째, 네이밍에 관한 한 언어간에 미묘한 차이가 많이 있습니다.

C #에서 형식과 변수는 별도의 네임 스페이스에 있습니다. 컴파일러는 그 차이를 알기에 충분히 똑똑합니다. 그러나 C에서는 두 종류의 이름이 네임 스페이스를 공유하므로 동일한 범위 내에서 같은 이름의 유형과 변수를 가질 수 없습니다. 이 때문에 C는 유형과 변수를 구별하는 명명 규칙이 필요하지만 C #은 그렇지 않습니다.


따라서 일부 오래된 언어는 C / C # 예제와 같은 미래 언어의 표준 코딩을위한 길을 열었습니다. 변수와 객체 멤버를 사례 화하는 방법을 추적해야하기 때문에 불필요한 일이 발생하지 않고 복잡한 수준을 추가하기 때문에 가장 불행한 일입니다.
oscilatingcretin 2016 년

4
@oscilatingcretin 모든 사람이 동일한 규칙을 사용할 때 지속적인 규칙이 추가되지는 않습니다.이 규칙은 문제의 언어에 대한 정신 모델의 일부가되어 해당 언어의 사용을 용이하게합니다. 이것은 입증 가능하고 측정 가능합니다.
Mr.Mindor 2016 년

나는 당신에게 투표하려고했지만 당신은 먼저 그것이 중요하지 않다고 말한 다음 왜 그것이 중요한지 설명하는 몇 개의 문단을 작성합니다. 처음에 "문제가되지 않습니다"를 삭제하면 투표하겠습니다.
Tulains Córdova 2016 년

10

다른 사람이 이것을 말한 것에 놀랐지 만, 대문자 차이가 한 가지 이유로 놀랍게 도움이된다고 생각합니다. 변수가 지역 변수 인 경우 이름을 리팩토링하는 것과 같이 변수를 변경하면 부작용에 대해 걱정하지 않아도됩니다. 따라서 클래스 멤버와 개인 클래스 변수 및 로컬 변수를 구별하는 규칙이 마음에 듭니다.

현대 Intellisense를 사용하면이 문제가 점점 줄어들지 만 정의를 찾는 위치를 알기 위해 코드를 읽을 때 여전히 랜드 마크를 제공합니다.

그리고 방법이 하나의 화면에 맞지 않을 때 몇 년 전의 나쁜 스타일에서 이것의 상당 부분이 남아있을 수 있습니다.


내가 작업 한 많은 프로젝트가 스타일 가이드에서 이와 같은 것을 지정합니다.
anaximander 2018 년

7

이것은 특정 컨벤션이 아닌 컨벤션 문제인 것 같습니다.

모든 컨벤션에 대해 다른 사람을 위해 더 많은 작업을 추가하기 만하면됩니다. 아마도 완벽한 세상에서, 회사 전체가 평생 단일 제품으로 일하지만 실제로는 그렇지 않습니다. 사람들은 프로젝트 간, 때로는 회사 간 또는 심지어 재미를 뛰어 넘습니다. 코드가 무작위로 많을수록 작업하기가 더 어렵고 비용이 많이 듭니다. 사업 주나 이해 관계자로서 저는 프로젝트의 이익보다는 이기적으로 생각하는 개발자를 고용하고 싶지 않습니다.

이것은 전문성으로 귀결됩니다. 때로는 개인 스타일을 제쳐 놓고 대량 채택에 더 효율적인 방법을 사용해야합니다. 이를 통해 협업을 장려하고 처음에는 없어야 할 외부 장벽을 제거합니다.

실제 규칙에 따라 CapitalCamelCase는 일반적으로 클래스 이름 (또는 자바 스크립트, 생성자)을 위해 예약되어 있습니다. 대문자로 된 변수가 보이면 교육받은 추측에 따라 변수를 사용하여 인스턴스화해야합니다. 그것이 틀렸다면, 코드가 커뮤니티 표준을 따르지 않는다는 사실에 열중 할 것입니다. 대부분의 다른 언어를 사용하더라도 처음으로 다른 사람을보고 있으면 즉시 잘못 인도됩니다. 코드가 명확하고 오도하지 않기를 바랍니다.


"대문자 변수가 보이면 교육받은 추측에 따라 변수를 사용하여 인스턴스화해야한다고 지시합니다." 난 이해가 안 돼요. 대문자로 된 변수를보고 어떻게 사용하기 전에 인스턴스화해야한다고 생각합니까? 클래스 이름처럼 보이기 때문에? 그래서 당신은 차이 모르는 MyClass MyClass = nullclass MyClass { }?
oscilatingcretin 2018 년

3
예, 차이점이 있습니다. 모호성을 방지하기 위해이 규칙이 존재합니다. var car = new Car();내 마지막 줄에 따라-왜 그것을 분명히하지 않습니까?
Adrian Schneider

3
@oscilatingcretin 물론 차이가 있습니다. 그러나 인간의 뇌는 컴퓨터 파서가 필요하지 않은 시각적 단서로부터 혜택을받습니다. 그것은 당신이 규칙 / 표준의 필요성에 대해 질문하는 것처럼 보입니다 ... 이것은 당신이 원래 요청한 것과 다른 질문이라면 유효합니다.
Andres F.

2

"정확한 대소 문자는 속성과 void 메소드를 위해 예약되어야하기 때문에. 값을 반환하는 지역 변수와 메소드는 첫 단어를 소문자로 사용해야합니다."

다른 프로그래머는 지금 코드를 가져 와서 이것이 속성이며 실제로 로컬 변수이므로 작업을 더 어렵게 만듭니다.


1
내 질문을 전부 읽었습니까? 내가 말한 끝을 살펴보십시오.NuggetCount all by itself suggests a property or local variable that is simply holding a value. To that last one, one may be tempted to say, "Ah ha! That is the question. Property or variable? WHICH IS IT?" To that, I'd reply with, "Does it really matter?"
oscilatingcretin

8
예, 그렇습니다. 다음 프로그래머는 NuggetCount를 생각할 필요가 없습니다. 이름을보고 말할 수 있어야합니다. 읽는 것이 좋은 책은 "클린 코드 (Clean Code)"입니다. 스토리처럼 코드를 읽고 무슨 일이 일어나고 있는지 알 수 있어야합니다.
N4TKD 2016 년

2
@oscilatingcretin 나는 당신이 요구하는 것과 약간 다른 질문에 대답하는 사람들과 당신이보고있는 좌절은 당신이 받아 들여진 협약을 어길 때 발생할 수있는 혼란의 증거라고 생각합니다.
Mr.Mindor

7
협약에는 의미가 있습니다. 규칙에 따라 NuggetCount가 속성을 암시하면 지역 변수보다 범위가 넓다는 의미입니다. 그것은 그 범위를 결정하기 위해 더 많은 연구를해야한다는 것을 의미합니다. 결정해야 할 사항 : 변경시 부작용이 있습니까? 내가 사용하는 동안 다른 스레드에 의해 값이 변경되지 않도록 신뢰할 수 있습니까? nuggetCount는 로컬 범위를 의미하며 전체 이야기가 로컬이라고 가정 할 수 있어야합니다.
Mr.Mindor

5
트윗 담아 가기 정확하게! 나는 그들이 쓴 것이 협약을 따른다는 것을 믿었고 그와 관련된 모든 것을 지켰습니다. 나는 그들이 팀의 일원으로 일하고 있다는 것을 믿었고, 그 협약을 사용함으로써 얻을 수있는 이점을 누릴 수 있다고 생각했습니다 (nuggetCount가 무엇인지 한눈에 알기) 그렇지 않은 경우, 아마도 당신의 동료들이 한 일을 할 것입니다. , 나는 다음에 믿을 수 없어서 그들을 따라야 할 때 더 많은 시간을 낭비합니다. 이 규약을 따르지 않으면 읽을 수없고 유지 관리하기 어려운 코드가 생성됩니다. 컨벤션을하고 싶은 이유가 있습니까?
Mr.Mindor

0

다른 사람들이 명명 규칙을 내리는 것을 제외하고는 실제 이유를 밝히지 않았습니다. 팀 전체를 같은 페이지에 배치 할 수 있다면 시간을 절약 할 수 있습니다. 예를 들어 개인적으로 코딩 표준을 시작하여 모든 개인 varials와 Val이 전달한 것들에 camelCase를 사용했지만, 공개적이거나 Ref가 전달한 것들에 PascalCase를 사용했습니다.

보호 또는 출력과 같은 것을 처리 할 때 선이 약간 흐릿 해집니다.


-2

언어는 공식적인 측면과 관습적인 방식으로 생각을 구성하는 데 중요하며, 생각하는 방식을 능가합니다. 따라서 한 스타일에서 다른 스타일로 전환하는 것은 고통입니다.

소문자와 대문자 기호는 Haskell에서 의미 상 큰 차이가 있으며 스칼라에서는 약간 다르며 두 가지를 모두 사용했습니다. 내가 사용하는 다른 언어는이 두 종류의 식별자 사이에 차이가 없지만 Haskell이 식별자를 인식하는 방식으로 생각을 유지하면 다른 언어에 대한 내 마음을 파편화하는 것보다 훨씬 쉽습니다.


-2

나를 위해 그것은 기대에 온다.

대부분의 코드를 읽을 때 a lowerCase로 시작하는 것은 로컬 변수 또는 함수 (C #에서는 변수 일 수 있음)가 될 것으로 기대합니다. 지역 변수가 보이면ProperCase 보면 클래스 이름이나 속성 또는 다른 것으로 생각하여 잠시 동안 혼란 스러울 것입니다. 그로 인해 코드를 다시 읽고 성 가실 것입니다.

아마도 귀하의 경우에 일어날 일입니다.

또한 첫 글자를 보면서 변수의 역할을 알 수있어 편리하며 인스턴스 이름과 클래스 이름 사이의 충돌을 피할 수 있습니다.


-3

입력하기 쉽도록 로컬 변수에 소문자를 사용해야합니다 (속도 / 전환 키 없음). 대문자는 이름 내에서 단어를 분리하여 가독성을 높이는 데 사용됩니다. 단일 단어 로컬 변수 이름 (일반적이어야 함)이있는 코드는 빠르고 입력하기 쉽습니다. 이름의 각 새 단어에 대문자를 사용하면 다른 문자를 추가하는 밑줄을 사용하는 것보다 빠르며 공간이 적습니다.


나는 이것이 매우 좋은 대답이라고 생각하며 다운 투표를 이해하지 못합니다. OP가 요청한 사실을 기반으로 한 논리적 인 답변입니다. 당신이 투표를하지 않으면 자신을 설명하십시오. 여기 저기 누르는 Shift 키는 방대합니다. 코드에 입력하는 거의 모든 단어가 PascalCase를 시작하고 각 단어마다 다른 Shift 키를 눌러야합니다. 미니멀하고 효과적이라면 불필요한 Shift 키 누름을 제거하는 것이 합리적입니다. 논리적으로 말하자면 생산성을 높이고 싶을 때 더 적은 키를 누르는 것을 의미합니다. 왜 더 많이 누르나요?
AIon

-3

여기 OP에 동의합니다. camelCase가 잘못 보입니다. 나는 그것이 표준이라는 사실에 동의하며 우리는 동일한 표준 또는 표준을 갖는 요점을 고수해야합니다. 또한 PascalCaps는 메소드에 색상을 지정하는 IDE를 사용하지 않을 때 차별화 방법으로 메소드 등에 사용되며 자신의 변수에 대해 camelCase로 사용하는 것이 좋습니다.

그 문제를 해결하기 위해 항상 객체의 이름 앞에 객체의 이름을 붙입니다. 따라서 문자열 변수 인 경우 strMyVariable을 호출합니다. 그것이 일종의 객체라면 나는 그것을 objMyObject 등이라고 부릅니다. 그렇게하면 표준에 따라 작은 대문자로 시작하고 올바르게 보입니다.


3
이것은 이전의 11 가지 답변에서 언급되고 설명 된 내용에 비해 실질적인 내용을 제공하지 않는 것 같습니다
gnat
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.