파이썬 블로그와 발명

팀 피터스에 의해 파이썬의 선은 파이썬 언어의 디자인을위한 20 지침입니다. 파이썬 코드가 반드시 이러한 지침을 따를 필요는 없지만 명심하는 것이 좋습니다. 파이썬의 선은 부활절 달걀입니다,또는 숨겨진 농담,당신이 실행하는 경우 나타나는import this:

>>> import thisThe Zen of Python, by Tim PetersBeautiful is better than ugly.Explicit is better than implicit.Simple is better than complex.Complex is better than complicated.Flat is better than nested.Sparse is better than dense.Readability counts.Special cases aren't special enough to break the rules.Although practicality beats purity.Errors should never pass silently.Unless explicitly silenced.In the face of ambiguity, refuse the temptation to guess.There should be one-- and preferably only one --obvious way to do it.Although that way may not be obvious at first unless you're Dutch.Now is better than never.Although never is often better than *right* now.If the implementation is hard to explain, it's a bad idea.If the implementation is easy to explain, it may be a good idea.Namespaces are one honking great idea -- let's do more of those!

참고:신비하게도 지침 중 19 개만 기록됩니다. 귀도 반 로섬은 소문에 누락 된 20 경구는”일부 기괴한 팀 피터스에서 농담 말했다.”

결국,이 지침은 주장하거나 반대 할 수있는 의견입니다. 도덕적 코드의 모든 좋은 세트와 마찬가지로,그들은 때때로 가장 유연성을 제공하기 위해 자신을 모순. 이 격언에 대한 내 자신의 해석은 다음과 같습니다:

아름다운 것이 못생긴 것보다 낫습니다.

프로그래머는 종종 가독성에 대한 걱정없이 코드를 빠르게 작성합니다. 코드를 읽을 필요는 없지만 파이썬 언어 자체의 코드는 생각하고 일관성이 있어야하며 사용하는 것이 즐겁습니다. 물론 모든 스크립트가 아름다울 필요는 없으며 아름다움은 주관적이지만 파이썬의 인기 중 많은 부분이 작업하기 쉬운 결과입니다.

명시 적 암시보다 낫다.

“이 격언은 자명하다.”그것은 어떤 격언에 대해서도 끔찍한 설명이 될 것이다. 마찬가지로 코드가 장황하고 명시적인 것이 좋습니다. 완전히 이해하기 위해 친숙해야 하는 모호한 언어 기능 뒤에 코드 기능을 숨기지 않아야 합니다.

단순한 것이 복잡한 것보다 낫다. 복잡한 것이 복잡한 것보다 낫다.

이 두 격언은 단순하거나 복잡한 기술을 사용하여 무엇이든 만들 수 있음을 상기시켜줍니다. 새집을 짓는 것과 같은 간단한 문제로 간단한 해결책이 더 좋습니다. 반면에 디젤 열차 엔진을 만드는 것은 복잡한 기술이 필요한 복잡한 문제입니다. 기술적으로 버드 하우스 기술을 사용하여 디젤 기차 엔진을 만들 수 있다고하더라도,당신은 아마 이상적인 솔루션되지 않을 것 버드 하우스 부품의 복잡한 루브 골드버그 배열로 끝날 것입니다. 복잡성보다는 단순성을 선호하지만 단순성의 한계를 알고 있어야합니다.

평면이 중첩 된 것보다 낫습니다.

프로그래머는 범주,다른 하위 하위 범주를 포함하는 하위 범주를 포함 특히 범주로 일을 구성하는 사랑. 이러한 계층 구조는 종종 관료주의를 추가 할 때 조직을 너무 많이 추가하지 않습니다. 여러 하위 모듈 또는 하위 클래스로 분할하는 대신 하나의 최상위 레이어 모듈 또는 클래스에 코드를 두는 것이 좋습니다. import spam.eggs.bacon.ham.foo.bar와 같은 코드가 필요한 패키지와 모듈을 만들면 코드가 너무 복잡해집니다.

스파 스는 밀도가 높은 것보다 낫습니다.

프로그래머는 종종 다음과 같은 한 줄과 같이 가능한 한 적은 코드로 많은 기능을 밀어 넣는 것을 좋아합니다: print('\n'.join("%i bytes = %i bits which has %i possible values." % (j, j*8, 256**j-1) for j in (1 . While code like this may impress their friends, it'll infuriate their coworkers who have to try to understand it. Code that is spread out over multiple lines is often easier to read than dense one-liners.

가독성이 중요합니다.

strcmp()는 1970 년대부터 프로그래밍해 온 사람과”문자열 비교”기능을 의미할 수 있지만,현대의 컴퓨터는 전체 함수 이름을 쓸 수 있는 충분한 메모리를 가지고 있다. 당신의 이름에서 모음을 떨어 뜨리거나 지나치게 간결한 코드를 작성하지 마십시오. 코드는 작성된 것보다 더 자주 읽히므로 명시적이고 읽을 수있는 코드는 간결하고 문서화되지 않은 코드보다 더 중요합니다.

특별한 경우는 규칙을 어길만큼 특별하지 않습니다. 실용성이 순결을 능가하지만.

집합으로 오는 이 두 격언은 서로 모순된다. 프로그래밍은 프로그래머가 코드에서 노력해야하는”모범 사례”로 가득합니다. 빠른 해킹에 대한 이러한 관행을 둘러싸는 것은 유혹적 일 수 있지만 일관성이없고 읽을 수없는 코드의 쥐 둥지로 이어질 수 있습니다. 그러나 규칙을 준수하기 위해 뒤로 구부리면 매우 추상적이며 읽을 수없는 코드가 발생할 수 있습니다. 모든 코드를 객체 지향 패러다임에 맞추려는 자바 프로그래밍 언어의 시도는 종종 가장 작은 프로그램조차도 많은 상용구 코드를 생성합니다. 이 두 격언 사이의 경계를 걷는 것은 경험을 통해 더 쉬워집니다. 그리고 시간에,당신은 규칙을 배울뿐만 아니라,그들을 깰 때 배울 수 있습니다.

오류는 자동으로 전달해서는 안됩니다. 명시 적으로 침묵하지 않는 한.

프로그래머가 종종 오류 메시지를 무시한다고해서 프로그램이 오류 메시지를 내보내는 것을 중지해야한다는 것을 의미하지는 않습니다. 자동 오류는 함수가 예외를 발생시키는 대신 오류 코드 또는None을 반환 할 때 발생할 수 있습니다. 이 두 가지 격언은 오류를 침묵시키고 프로그램을 계속 실행하는 것보다 프로그램이fail fast하고 충돌하는 것이 더 낫다는 것을 알려줍니다. 나중에 필연적으로 발생하는 버그는 원래 원인에서 멀리 제거되므로 디버깅하기가 더 어려울 것입니다. 당신은 항상 명시 적으로 프로그램의 원인이 오류를 무시하도록 선택할 수 있지만,당신이 그렇게 할 수있는 의식적인 선택을하고 있는지 확인하십시오.

모호함에 직면하여 추측하려는 유혹을 거부하십시오.

컴퓨터는 인간을 미신으로 만들었다:우리의 컴퓨터에 있는 악마를 쫓아내기 위하여 우리는 그(것)들을 끄고 그 후에 켜기의 신성한 의식을 실행한다. 아마도 이것은 신비한 문제를 해결할 것입니다. 그러나 컴퓨터는 마법이 아닙니다. 코드가 작동하지 않으면 이유가 있으며 조심스럽고 비판적 사고만으로 해결할 수 있습니다. 무언가가 작동할것을 보일 까지 맹목적으로 해결책을 시도하는 유혹을 사절하십시요;수시로 너는 단순하게 문제를 복면하고 오히려 그것을 해결했다.

단 하나,바람직하게는 단 하나의 명백한 방법이 있어야합니다.

이것은 펄 프로그래밍 언어의 모토에 대한 현측이다,”그것을 할 수있는 하나 이상의 방법이있다!”그것은 같은 일을 코드를 작성하는 서너 가지 방법을 갖는 것은 양날의 검 것으로 나타났다:당신은 당신이 코드를 작성하는 방법에 유연성을 가지고 있지만,지금 당신은 그것을 읽기 위해 작성되었을 수있는 모든 가능한 방법을 배울 수있다. 이러한 유연성은 프로그래밍 언어를 배우는 데 필요한 3 배 또는 4 배의 노력을 기울일 가치가 없습니다.

비록 당신이 네덜란드어하지 않는 한 그 방법은 처음에는 분명하지 않을 수 있습니다.

이 줄은 농담입니다. 구이도 반 로섬,파이썬의 창조자와 비단뱀(삶에 대한 자비로운 독재자),네덜란드어입니다. 그러나이 격언조차도 파이썬이 문자열 서식을 지정하는 세 가지 다른 방법을 통합하는 것을 막지는 못했습니다.

지금은 결코보다 낫다. 지금*오른쪽*보다 종종 더 나은 적이 있지만.

이 두 가지 격언은 무한 루프에 걸려 있거나 걸려있는 코드가 그렇지 않은 코드보다 분명히 더 나쁘다는 것을 말해줍니다.그러나 프로그램이 너무 일찍 완료되는 것보다 프로그램이 완료 될 때까지 기다리는 것이 거의 확실합니다.

구현을 설명하기 어렵다면 나쁜 생각입니다. 구현이 쉽게 설명 할 수 있다면 좋은 아이디어 일 수 있습니다.

파이썬은 프로그램이 더 빨리 실행되도록 컴퓨터를 수용하기보다는 프로그래머의 작업을 더 쉽게 하기 위해 노력한다. 그리고 프로그램은 그것을 쓴 프로그래머뿐만 아니라 코드를 유지하는 다른 프로그래머들도 이해할 수 있어야합니다. 이 두 가지 격언은”고성능”코드가 프로그래머가 이해하고 디버깅하는 것이 불가능할 정도로 복잡하다면 나쁜 코드라는 것을 상기시켜줍니다. 그러나 슬프게도,프로그램의 코드를 다른 사람에게 쉽게 설명 할 수 있다고해서 그것이 나쁜 코드가 아니라는 것을 의미하지는 않습니다. 프로그래밍은 어렵다.

네임 스페이스는 하나의 경적을 울리는 좋은 생각입니다.

네임스페이스(및 전역 및 로컬 범위)는 한 모듈의 이름 또는 범위가 다른 모듈의 이름과 충돌하지 않도록 하기 위한 핵심입니다. 네임스페이스는 이름 충돌을 방지하고 불필요한 분류를 추가하지 않기 위해서만 만들어야 합니다.

프로그래밍에 대한 모든 의견과 마찬가지로,여기에 작성한 의견은 귀하의 상황에 반대하거나 단순히 관련이없는 것일 수 있습니다. 코드를 작성하는 방법에 대해 논쟁하는 것은 당신이 생각하는 것만 큼 생산적이지 않습니다. (프로그래밍 의견으로 가득 찬 전체 책을 쓰지 않는 한.)