문제

C# 배경에서 나오는 변수 및 메소드 이름에 대한 명명 규칙은 일반적으로 Camelcase 또는 Pascal Case입니다.

// C# example
string thisIsMyVariable = "a"
public void ThisIsMyMethod()

파이썬에서는 위의 것을 보았지만 밑줄도 사용되는 것을 보았습니다.

# python example
this_is_my_variable = 'a'
def this_is_my_function():

Python에 더 바람직하고 결정적인 코딩 스타일이 있습니까?

도움이 되었습니까?

해결책

파이썬을 참조하십시오 PEP 8.

기능 이름은 소문자 여야하며, 단어가 가독성을 향상시키기 위해 필요에 따라 단어를 밑줄로 분리해야합니다.

혼합 가방은 이미 우세한 스타일 인 상황에서만 허용됩니다.

변수...

기능 명명 규칙을 사용하십시오 : 가독성을 향상시키기 위해 필요에 따라 밑줄로 구분 된 단어가있는 소문자.

개인적으로 나는 또한 선호하기 때문에 이것에서 벗어난다 mixedCase ~ 위에 lower_case 내 프로젝트를 위해.

다른 팁

Google Python 스타일 가이드 다음 컨벤션이 있습니다.

module_name, package_name, classname, method_name, ExceptionName, function_name, global_constant_name, global_var_name, instance_var_name, function_parameter_name, local_var_name

유사한 명명 체계가 a에 적용되어야합니다 CLASS_CONSTANT_NAME

David Goodger ( "Pythonista와 같은 코드"로 여기)는 다음과 같이 PEP 8 권장 사항을 설명합니다.

  • joined_lower 함수, 방법, 속성, 변수

  • joined_lower 또는 ALL_CAPS 상수

  • StudlyCaps 수업을 위해

  • camelCase 기존의 협약에만 적합합니다

로서 파이썬 코드에 대한 스타일 가이드 인정,

Python 도서관의 이름 지정 규칙은 약간 엉망이므로 절대 일관성을 얻지 못할 것입니다.

이것은 단지 Python 's를 의미합니다 표준 라이브러리. 그들이 얻을 수 없다면 저것 일관되게 모두 파이썬 코드가 있습니까?

그것으로부터, 그리고 여기에서 토론하면, 나는 그것이 ~ 아니다 Python으로 넘을 때 변수 및 기능에 대한 EG Java 또는 C#(명확하고 잘 정립 된) 명명 규칙을 계속 사용하는 경우 끔찍한 죄. 물론 코드베이스 / 프로젝트 / 팀의 우세한 스타일을 지키는 것이 가장 좋습니다. 파이썬 스타일 가이드가 지적한 것처럼 내적 일관성 가장 중요합니다.

저를 이단으로 무시하십시오. :-) OP와 같이, 나는 "Pythonista"가 아니며 아직 어쨌든 아닙니다.

거기 있습니다 PEP 8, 다른 답변이 보여 주듯이, Pep 8은 표준 라이브러리의 스타일 가이드 일 뿐이며, 그것은 그 안에 복음으로만 취합니다. 다른 코드에 대한 PEP 8의 가장 빈번한 편차 중 하나는 변수 명명, 특히 방법에 대한 변수입니다. 혼합 케이스를 사용하는 코드의 볼륨을 고려할 때 단일 우세한 스타일은 없습니다. 엄격한 인구 조사를 만들려면 아마도 Mixedcase가있는 PEP 8의 버전으로 끝날 것입니다. PEP 8과의 다른 편차는 거의 없습니다.

언급했듯이 Pep 8은 사용하겠다고 말합니다 lower_case_with_underscores 변수, 방법 및 함수의 경우.

나는 사용하는 것을 선호한다 lower_case_with_underscores 변수 및 mixedCase 방법과 기능의 경우 코드를보다 명시적이고 읽을 수있게합니다. 따라서 파이썬의 선 "명시 적은 암시 적보다 낫다"및 "가독성 계수"

개인적으로 나는 수업, 혼합 케이스 방법 및 기능에 Camelcase를 사용하려고 노력합니다. 변수는 일반적으로 밑줄이 분리됩니다 (기억할 수있는 경우). 이런 식으로 나는 내가 똑같이 보이는 모든 것이 아니라 내가 정확히 무엇을 부르는지 한눈에 알 수 있습니다.

대부분의 Python 사람들은 밑줄을 선호하지만 지금도 5 년이 넘게 Python을 사용하고 있지만 여전히 마음에 들지 않습니다. 그들은 단지 나에게 못 생겼다. 그러나 아마도 내 머리에있는 모든 자바 일 것이다.

나는 클래스의 이름이 지정되는 방식에 더 잘 맞기 때문에 Camelcase를 더 좋아합니다. SomeClass.doSomething() ~보다 SomeClass.do_something(). Python의 Global Module Index를 둘러 보면 두 가지를 찾을 수 있습니다. 두 가지를 찾을 수 있습니다. 이는 엄격한 코딩 규칙을 가진 Sun과 같은 한 회사가 개발 한 것이 아니라 초과 근무를하는 다양한 소스의 라이브러리 모음이기 때문입니다. . 나는 결론은 다음과 같습니다. 당신이 좋아하는 것을 더 잘 사용하십시오. 그것은 단지 개인적인 취향에 관한 문제 일뿐입니다.

@johnteslade가 대답 한 것입니다. Google의 파이썬 스타일 가이드 깔끔한 권장 사항이 있습니다.

피해야 할 이름

  • 카운터 또는 반복자를 제외한 단일 문자 이름
  • 패키지/모듈 이름의 대시 (-)
  • \__double_leading_and_trailing_underscore__ names (Python에 의해 예약)

이름 지정 컨벤션

  • "내부"는 모듈 내부 또는 클래스 내에서 보호 또는 개인을 의미합니다.
  • 단일 밑줄 (_)을 선제하면 모듈 변수 및 함수를 보호하는 데 약간의 지원이 있습니다 (가져 오기 *에는 포함되지 않음). 인스턴스 변수 또는 메소드에 이중 밑줄 (__)을 선물하면 변수 또는 메소드를 클래스에 비공개로 만드는 데 효과적으로 사용됩니다 (이름 망글 링 사용).
  • 관련 클래스와 최상위 기능을 모듈에 함께 배치하십시오. Java와 달리 모듈 당 하나의 클래스로 자신을 제한 할 필요가 없습니다.
  • 사용 CapWords 클래스 이름을 위해서는 lower_with_under.py 모듈 이름의 경우. 이름이 많은 기존 모듈이 있지만 CapWords.py, 이것은 모듈이 클래스의 이름을 따서 명명 될 때 혼란 스럽기 때문에 이제 낙담합니다. ( "잠깐만 - 글을 썼나요? import StringIO 또는 from StringIO import StringIO?")

Guido의 권장 사항에서 파생 된 지침 enter image description here

이것에 대한 논문이 있습니다. http://www.cs.kent.edu/~jmaletic/papers/icpc2010-camelcaseunderscoreclouds.pdf

tl; dr Snake_case는 Camelcase보다 더 읽기 쉽다고 말합니다. 그렇기 때문에 현대 언어가 할 수있는 곳마다 뱀을 사용하거나 사용해야합니다.

코딩 스타일은 일반적으로 조직의 내부 정책/컨벤션 표준의 일부이지만 일반적으로 All_lower_case_underscore_separator 스타일 (Snake_case라고도 함)은 Python에서 가장 일반적이라고 생각합니다.

일반적으로 하나는 언어 표준 라이브러리에 사용 된 규칙을 따릅니다.

라이센스 : CC-BY-SA ~와 함께 속성
제휴하지 않습니다 StackOverflow
scroll top