명명 규칙 : camelCase vs underscore_case? 그것에 대해 어떻게 생각하세요? [닫은]

나는 약 2 년 동안 underscore_case를 사용하고 있으며 최근 새 작업으로 인해 camelCase로 전환했습니다. 주로 코드를 읽기 쉽기 때문에).

이제 직장의 모든 사람들이 camelCase를 사용하므로 코드가 더 우아해 보입니다.

camelCase 또는 underscore_case에 대해 어떻게 생각하십니까

추신 영어 실례합니다

편집하다

일부 업데이트 먼저 :

• 사용 된 플랫폼은 PHP입니다 (그러나 엄격한 PHP 플랫폼 관련 답변을 기대하지는 않습니다. 누구든지 사용하기에 가장 좋은 생각을 공유 할 수 있습니다.

• 나는 팀에서 다른 사람과 마찬가지로 camelCase를 사용합니다 (대부분의 사람들이 권장하는 것처럼)

• camelCase를 권장하는 Zend Framework를 사용합니다.

몇 가지 예 (PHP 관련) :

• Codeigniter 프레임 워크는 underscore_case를 권장하며 솔직히 코드를 읽기가 더 쉽습니다.

• ZF는 camelCase를 추천하며 ZF 코드가 이해하기 힘들다고 생각하는 유일한 사람은 아닙니다.

그래서 내 질문은 다음과 같이 표현됩니다.

이름 지정 규칙을 권장하지 않는 Foo 플랫폼이 있고 팀 리더가 선택하는 것을 선택하는 경우를 생각해 봅시다. 당신은 그 팀장입니다. 왜 camelCase를 선택합니까?

ps 지금까지 프롬프트 응답에 대해 모두에게 감사합니다

사용하는 언어에 어느 정도 의존한다는 것에 동의합니다. 기호 이름이 언어의 내장 라이브러리 및 스톡 라이브러리와 동일한 형식을 따르는 경우 코드가 더 깔끔해 보입니다.

그러나 선택의 여지가있는 한 간단한 이유 때문에 낙타 경우보다 밑줄을 선호합니다. 그 스타일을보다 쉽게 ​​읽을 수 있습니다. 다음은 예입니다. 더 읽기 쉬운 것은 무엇입니까? 이:

aRatherLongSymbolName

아니면 이거:

a_rather_long_symbol_name

밑줄 버전을 훨씬 쉽게 읽을 수 있습니다. 내 뇌는 경계가 반대의 경우 다른 상형 문자와 유사 상형 문자 또는 숫자 (사이에 특히 곳, 낙타 경우 소문자 / 대문자 경계를 감지 할 수있는 것보다 훨씬 더 쉽게 밑줄을 무시할 수 I/l, O/0, t/I, 등). 예를 들어,이 부울 변수는 이글루가 적절한 계획 권한으로 구축되었는지 여부를 나타내는 값을 저장합니다 (의심 할 여지없이 우리 모두에게 일반적인 사용 사례).

isIllicitIgloo

이 버전을 훨씬 쉽게 읽을 수 있습니다.

is_illicit_igloo

읽기 어려운 심볼 이름보다 더 나쁜 것은 아마도 읽기 어려운 심볼 이름입니다. 좋은 기호 이름은 자체 문서화로,이를 통해 한 눈에 읽고 그 의미를 이해할 수 있어야합니다. (우리는 모두 침대에서 즐거움을 위해 코드 출력물을 읽었을 것이라고 확신하지만 때로는 서둘러 빠져 들기도합니다.) 종종 낙타 문자 기호 이름을 사용하여 잘못 읽을 수 있고 잘못된 느낌을 얻습니다. 기호의 의미론.

플랫폼에서 채택한 명명 규칙을 사용해야한다고 생각합니다. C # 코드에서 underscore_case가 이상하게 보일 것입니다. Ruby의 camelCase =)

솔직히 팀의 모든 사람이 동일한 체계를 사용하는 한 실제로 중요하지 않습니다. 장기적으로는 코드의 가독성이 중요하지만 모든 사람이 동일한 명명 규칙을 준수하는 것이 중요하지만, 둘 중 하나가 자연 스러울 가능성이 높습니다.

John Isaacks의 답변은 다음과 같습니다.

"정직하게 코드를 읽기가 더 쉽다"의견 또는 사실?

나는 약간의 연구를하기로 결정했고이 논문을 발견 했다 . 과학은이 주제에 대해 무엇을 말해야합니까?

1. 낙타 케이싱은 밑줄보다 정확성이 높습니다. (홀수는 51.5 % 더 높습니다)
2. 낙타의 경우 평균 0.42 초가 걸렸으며 이는 13.5 % 더 깁니다.
3. 교육은 스타일이 정확성에 미치는 영향에 통계적으로 유의미한 영향을 미치지 않습니다.
4. 더 많은 훈련을 받은 사람들 은 낙타 케이스 스타일의 식별자를 더 빨리 사용 했습니다.
5. 한 스타일의 훈련은 다른 스타일 의 찾기 시간 에 부정적인 영향을 미칩니다 .

에서 내 블로그 게시물 주제에 나는 과학 논문을 검토하고 다음과 같은 결론을합니다.

낙타 사례 (2) 의 속도 저하 만 프로그래밍과 관련이 있으며, 최신 IDE와 대부분 의 낙타 케이스 사용자로 인해 다른 점은 무시합니다. 토론 (투표와 함께)은 블로그 게시물에서 찾을 수 있습니다.

이 기사가 어떻게 사람들의 의견을 바꿀 수 있는지 궁금합니다. :)

똑똑한 사람을 복사

프로그래밍 언어의 경우 언어 개발자의 스타일을 복사하십시오.

예를 들어 K & R에서와 같이 C를 정확하게 코딩합니다.

그런 다음 누군가 지루한 코딩 스타일 대화를 시작하려고 할 때 "Dennis Ritche와 함께 대화를 나눈 다음 자신의 말을 알려주세요"라고 말할 수 있습니다.

일반적으로 낙타 케이스를 선호합니다. 그러나 그것은 내 경력의 대부분이기 때문에 스타일 가이드가 일반적으로 camelCase를 권장하는 언어와 환경에서 일하고 있습니다. (자바, ECMAScript, C ++). PHP 사용자는 반대의 선호를 가지고있을 것입니다.

즉, threeOrFourWords를 넘어서거나 XmlForExample과 같은 초기화를 사용하면 읽기가 중단됩니다.

이것이 이맥스가 우리에게 안경 모드를 제공하는 이유입니다.

낙타

이것은 항상 가독성보다 'type-ability'를 선택하는 몇 안되는 장소 중 하나입니다. CamelCase는 타이핑하기가 더 쉽고 내 손가락이 더 좋아지면 약간의 가독성이 향상됩니다.

물론 프로젝트가 다른 표준으로 기존 코드베이스를 기반으로하지 않는다고 가정합니다.

흥미로운 질문입니다. 나는 여러 번 생각했습니다. 그러나 확실한 대답은 없다고 생각합니다.

"문화적"관습에 따라 좋은 선택입니다. 이 경우 "문화"는 팀 / 회사에서 설정된 규칙을 의미하며 기본적으로 언어 / 플랫폼 규칙도 수행합니다. 다른 사람들이 코드를 쉽게 읽고 사용하도록 도와 주며 코드를 이해하는 데 추가 노력과 시간이 필요하지 않습니다.

때로는 받아 들여진 표기법을 어기는 것이 흥미 롭습니다. 작은 프로젝트 (파이썬) 중 하나는 underscored_names유틸리티 함수 / "보호 된"메소드에, Java 스타일 methodNames은 메소드에 사용했습니다. 우리 팀은 그것에 만족했습니다 :)

프로그래밍 언어에 따라 다릅니다.

헝가리어 표기법을 사용할지 여부와 같은 보트 에서이 사례를 사용하는 것이 좋습니다.

• 파이썬 : underscore_case, 헝가리 표기법 없음
• C ++ : camelCase, 헝가리 표기법

양자 모두!

내가 CakePHP의 발전을 많이 할, 내가 하나를 사용 CamelCase하거나 $underscored_vars다음과 같은 방식으로 (심지어 CakePHP의 프로젝트 외부)에서 :

1. filenames — /lowercased_underscored.php일반적이지만 언급 할 가치가 있습니다.
2. 수업 — class CamelCase extends ParentObject. 를 사용할 때 CamelCase초기 문자는 소문자가 아닙니다. 나는 찾아 camelCase보고 정말 이상한.
3. 변수 —$are_variables_underscored === TRUE;
4. 인스턴스를 보유하는 변수 —$CamelCase = new CamelCase();
5. 배열 키 —$collection['underscored_keys'];
6. 상수 — 모든 사람들이 상수가되어야한다는 데 동의 할 수 있다고 생각합니다 ALL_CAPS_AND_UNDERSCORED.
7. 방법 —$CamelCase->foo_method_underscored();
8. 정적 메서드 -CamelCase::just_like_regular_methods();

나는 개인적으로 underscore_case그것을 더 읽기 쉽기 때문에 선호 하지만 기존 코드베이스와의 일관성이 훨씬 더 중요하다는 다른 응답자와 동의합니다.

그러나 나는 "언어와 그 라이브러리의 규칙을 따르십시오"라고 말하는 사람들에 대한 반례가 있습니다.

과거에는 Windows를 사용하여 C 코드를 작성 underscore_case하고 PascalCaseWin32 함수를 호출했습니다 .

if (one_of_our_conditions_is_true())
{
    call_one_of_our_functions();
    CallSystemFunction();
}

함수 이름과 Microsoft 함수 이름의 시각적 차이는 코드가 "시스템 랜드"로 갈 때 명확하게 보여 주었으므로 방해가 아니라 도움이되었습니다.

또한 편집기의 구문 강조 규칙을 다른 색상으로 표시하도록 변경하여 익숙하지 않은 코드 섹션 (또는 내 자신의 섹션)을 이해할 때 시각적 인 힌트를 얻을 수있었습니다.

나는 Dylan의 평범한 대쉬를 좋아하고 타이핑하기 쉽고 읽기 쉽습니다.

처럼

result-code := write-buffer(file-stream, some-string)

그러나 나는이 언어가 상당히 모호하기 때문에 일종의 주제가 아닌 것 같습니다 ... :(

나는 대학에서 낙타 케이스를 사용하도록 배웠다. 지난 몇 년 동안 몇 가지 다른 규칙을 사용했지만 다른 것보다 낙타 케이스를 선호합니다. 낙타 케이스가 읽고 이해하기 가장 쉬운 곳에서 읽은 것을 기억합니다.

대부분의 사람들이 언급했듯이-기존 표준을 사용하십시오. 새 프로젝트 인 경우 사용할 언어 및 프레임 워크의 표준을 사용하십시오.

혼란스러워하지 마십시오. 이것은 가독성 (주관적)에 관한 것이 아니라 일관되고 전문적인 것입니다. 수많은 '표준'이 진행되는 코드베이스에서 일한 사람이라면 누구나 이해할 것입니다.

때로는 혼합을 사용합니다 : module_FunctionName. 내 모듈의 모든 (정적이 아닌) 기능은 모듈 약어로 시작합니다.

예를 들어 I2C 버스에서 버퍼의 내용을 전송하는 기능은 다음과 같습니다.

i2c_BufferSend()

대안 i2c_buffer_send은 접두사와 함수 이름을 충분히 크게 구분하지 않습니다. i2cBufferSend접두사를 너무 많이 섞습니다 (이 모듈에는 꽤 많은 I2C 기능이 있습니다).

i2c_Buffer_send 그러나 대안이 될 수 있습니다.

내 대답은 당신이 당신의 프로젝트 (언어, SW 아키텍처 등)에 가장 적합한 것에 적응하고 이러한 스타일을 혼합하는 것이 유용 할 수 있음을 지적하고 싶었습니다.

myGeneralOpinionIsThatNamesAreMuchHarderToReadInCamelCase. I_respect_the_fact_that_some_could_think_otherwise_but_I_do_not_really_understand_why.

개인적으로 나는 camelCase를 선호하지만 일부 글꼴에서는 밑줄을 더 쉽게 읽을 수 있다고 생각합니다.

변수 집합을 구별하기 위해 접두사를 사용해야하는 경우 네임 스페이스 나 개체 또는 해당 정보를 보유 할 수있는 언어를 사용해야합니다.

myName   = 7
bobsName = 8   // :(

me.name  = 7
bob.name = 8   // :D

마찬가지로 유형을 구별해야하는 경우이를 허용하는 언어를 사용하지 않는 이유는 무엇입니까?

var intThingy = 7; // :(

int thingy = 7;    // :)

일단 당신이 그것을 똑바로하고 이름을 메타 데이터로 사용하는 것이 아니라면 여분의 키 누르기를 선호하는지 여부에 관계없이 긴 이름이 충분하지 않을 것입니다.

처음에 나는 dafmetal에 동의합니다. 다른 프로그래밍 스타일을 혼합하지 않는 것이 가장 중요합니다. 하나의 동일한 파일에서이 작업을 수행하는 것이 IMHO를 수행 할 수있는 최악의 상황입니다. 다른 파일들 사이에서 산만하지만 치명적이지는 않습니다.

다음으로해야 할 일은 작성중인 언어에 널리 사용되는 규칙의 이름을 지정하는 것입니다. instnace에 대한 C ++ 코드는 분명히 Python의 코드와 다르게 보일 것입니다 (PEP8은 여기서 좋은 안내서입니다)

상수에 UPPER_CASE를 사용하는 경우 (물론 특정 언어에만 적용됨) 로컬 변수 이름에 this_style을 사용할 수 있지만, 인스턴스 / 멤버에 camelCase를 사용하는 경우 다른 이름 지정 규칙을 사용하여 다른 것을 참조 할 수 있습니다. 변수. 이 같은 일이있을 때이 작업은 필요하지 않을 수 self또는 this그러나합니다.

최신 정보

Foo 마녀가 어떤 이름 지정 규칙을 권장하지 않으며 하나를 선택하는 것이 팀장의 선택 인 경우를 생각해 봅시다. 당신은 그 팀장입니다. 왜 camelCase를 선택하겠습니까?

실제로는 다른 것보다 이점이 없습니다. 이 문제는 매우 주관적이며 일단 동의하면 차이가 없습니다. 이 작은 것들에 대한 종교적인 전쟁이 항상 있습니다. 그러나 일단 당신이 어느 것에 적응하면, 토론은 전적으로 불필요한 것 같습니다.

매우 비슷한 문제에 대해 Alex Martelli를 인용하면 :

물론 루비에서는 각 블록의 끝에 들여 쓰기가 아닌 바보 같은 "끝"을 입력하는 것에 지치지 않지만 파이썬이 필요로하는 똑같이 바보 같은 ':'를 입력하지 않아도됩니다. 각 블록 의 시작 이므로 거의 씻습니다 :-). '@foo'와 'self.foo'와 같은 다른 구문 차이 또는 Ruby vs Python에서 대소 문자의 중요성은 실제로 나에게 거의 관련이 없습니다.

다른 사람들은 의심 할 여지없이 그러한 문제에 기초하여 프로그래밍 언어를 선택하고 가장 인기있는 논쟁을 일으킨다. 그러나 그것은 파킨슨의 법칙 중 하나의 사례 일 뿐이다 ( 문제에 대한 토론의 양은 문제에 반비례한다) 실제 중요성 ).

출처

당신이 팀장이라면, 당신은 단지 하나와 함께 가십시오. 하나는 다른 것에 비해 이점이 없으므로 주사위를 던지거나 더 좋아하는 것을 선택할 수 있습니다.

나는 몇 년 전에 영어를 모국어로 사용하지 않는 프로그래머는 낙타의 경우를 이해하기 쉽게 밑줄을 찾는 경향이 있지만 참조를 찾을 수 없으며 그것이 사실인지 전혀 모른다.

Java, Python, C ++과 같이 사용한 프로그래밍 언어의 경우 명확한 형식을 채택했습니다.

• ClassNamesArePascalCase
• methodNamesAreCamalCase
• variable_names_are_underscore
• CONSTANT_VARIABLES_ARE_CAPITAL_VARIABLES

이를 통해 내가 다루고있는 것을 즉시 식별 할 수 있습니다. 나는 자신을 위해 유지하는 것이 유용하다는 것을 알았으며 다른 사람이 코드를 읽는 것은 쉽게 따라야합니다. 나는 다른 사람들이 언급 한 바와 같이 일관성이 가장 중요하다고 생각합니다. 따라서 형식의 유형을 명확하게 구분하면서 형식을 유지 관리하기에 충분히 간단합니다. interface_Names_Are_Like_This 및 Abstract_Classes_Are_Like_This를 가능한 확장으로 상상할 수 있지만 따라 가기가 더 복잡하고 구별하기에 유용하지 않을 수 있습니다.

또한 PascalCase에서 HTMLParser 또는 HTMLparser 대신 HtmlParser와 같은 HTML 파서와 같이 이름이 엄격한 것이 유용하다는 것을 알았습니다. 엄격한 규칙을 기억하는 것이 더 쉽고 단어 경계를 명확하게 유지하기 때문에 (불행히도 HTML이나 SQL과 같은 철자가 틀린 부분이 필요합니다). camelCase와 마찬가지로 HTMLParserMethod 또는 HTMLparserMethod 대신 htmlParserMethod가 사용됩니다.

업데이트 :

이후 개인 변수를 포함하도록 이러한 규칙을 확장하는 데 사용되었습니다. -_private_variable_names_are_prefixed_with_an_underscore-_PRIVATE_CONSTANT_VARIABLES_ARE_PREFIXED_WITH_AN_UNDERSCORE

Java에서 이는 개인 필드가 로컬 변수와 다른 네임 스페이스에 정의되어 있음을 의미하므로 this.on 개인 필드를 건너 뛸 수 있습니다. 접두사 " m"로 표시된 다른 형식 도 변수 이름에 camelCase를 사용합니다. 이것은 또한 내게는 클래스에 의해 내부적으로 액세스 (그리고 제작되어야 필드 사이에 구분을 할 수 있습니다 슈퍼 클래스의 밖이 일어나고 때 분명 object._field_x눈에 띄는).

그것이 나에게 달려 있다면 프로그래머로서 우리는 IfItIsInCamelCase 또는 in_underscore_space 또는 in_SomeOtherStyle 기호를 읽을 수 있고 그것이 의미하는 바를 이해할 수 있기 때문에 특정 스타일의 사용을 강요하거나 암시하지 않을 것입니다. 기호를 파싱하는 데 약간의 시간을 소비하는 것은 큰 사물의 계획에서 큰 오버 헤드가 아닙니다.

이제 컨벤션의 주요 주장은 함수 / 변수 이름의 형식이 무엇인지 미리 알 필요가 없으며 조회 할 필요가 없다는 것입니다. LoadXMLFile, loadXMLFile, LoadXmlFile, load_xml_file입니까? 이제 "인텔리 센스 스타일 자동 완성을 지원하는 IDE를 구하십시오!" (항상 가능하지는 않습니다).

결국 컴파일러 / 인터프리터가 실제로 신경 쓰지 않기 때문에 어떤 스타일을 사용하는지는 중요하지 않습니다. 중요한 것은 이름이 유용하다는 것입니다.

NumberOfPrisonersReleasedByAccident
manufacturer_name
distance_EarthToMoon

세 가지 다른 스타일이지만 각 스타일이하는 일을 정확히 알고 있습니다.

어리석은 것처럼 보일 수 있지만 밑줄이 얇고 여러 줄 텍스트로 숨겨져 있기 때문에 밑줄을 좋아하지 않습니다. 또한 일부 (많은) 텍스트 편집기 및 / 또는 개발자 환경에서 토큰 이름을 두 번 클릭하여 강조 표시하여 복사하거나 끌어 놓을 때 시스템은 전체 토큰을 강조 표시하지 않으며 한 부분 만 강조 표시합니다 인접한 밑줄 사이의 토큰. 그것은 나를 미치게한다.

나는 이클립스 내 개발의 대부분을 바보 이유 (자바를 들어, PHP와 자바 스크립트)에 대한 낙타 표기법을 선호하는 경향이, 나는 때 Ctrl+ ←나 Ctrl+ →단어를 통해, 실제로는 낙타 표기법 경계에서 멈 춥니 다.

즉 myIntVariable, Ctrl+ ← →'를 통해 Eclipse를 사용하면 3 단어로 처리됩니다 .

나는 그것이 이상한 기묘하다는 것을 알고 있지만, 낙타 케이스 이름으로 중간 단어를 편집하는 것을 선호합니다.