Python pep-8이 들여쓰기를 위해 탭 위에 공백을 두는 것을 강력히 권장하는 이유는 무엇입니까?
스택 오버플로와 PEP 8에서 권장 사항은 Python 프로그램에서 들여쓰기에만 공간을 사용하는 것입니다.저는 지속적인 압흔의 필요성을 이해할 수 있고 그 고통을 느꼈습니다.
공간이 선호되는 근본적인 이유가 있습니까?저는 탭을 사용하는 것이 훨씬 더 쉽다고 생각했을 것입니다.
음, 모든 사람들이 공간에 대해 강한 편견을 가지고 있는 것처럼 보입니다.저는 탭만 사용합니다.그 이유를 잘 알고 있습니다.
탭은 사실 공간 다음에 나온 멋진 발명품입니다.공간을 수백만 번 누르거나 가짜 탭(공간을 생성하는)을 사용하지 않고 들여쓰기할 수 있습니다.
저는 왜 모두가 탭 사용을 차별하는지 정말 이해할 수 없습니다.그것은 노인들이 더 새롭고 효율적인 기술을 선택한 것에 대해 젊은 사람들을 차별하고 이러한 화려한 새 전화기뿐만 아니라 모든 전화기에서 펄스 다이얼링이 작동한다고 불평하는 것과 매우 비슷합니다."톤 다이얼이 모든 전화기에서 작동하는 것은 아닙니다, 그래서 그것이 잘못된 것입니다."
편집기에서 탭을 제대로 처리할 수 없습니까?현대판 편집자를 구하세요.시간이 많이 지났을지 모르지만, 우리는 지금 21세기에 있고 편집자가 첨단 기술의 복잡한 소프트웨어였던 시대는 이미 오래 전입니다.이제 수많은 편집자들이 선택할 수 있습니다. 탭을 지원하는 모든 편집자들은 문제가 없습니다.또한 공백으로 수행할 수 없는 탭의 크기를 정의할 수 있습니다.탭을 볼 수 없습니까?그것은 무엇을 위한 논쟁입니까?여러분은 공간도 볼 수 없습니다!
대담하게도 더 나은 편집자를 구하자고 제안해도 될까요?이미 10년 전에 출시된 이 첨단 기술 중 하나는 보이지 않는 캐릭터를 보여줍니다.
공백을 사용하면 삭제 및 서식 지정 작업이 훨씬 더 많아집니다.이것이 바로 Python에 대한 탭을 사용하는 이유입니다.
탭과 공백을 혼합하는 것은 금지 사항이며 이에 대한 논쟁은 금지 사항입니다.그것은 엉망이고 절대 작동할 수 없습니다.
정답은 바로 PEP에 나와 있습니다 [ed: 이 구절은 2013년에 편집되었습니다].인용구:
Python을 들여쓰기하는 가장 일반적인 방법은 공백만 사용하는 것입니다.
당신이 필요로 하는 다른 근본적인 이유는 무엇입니까?
간단히 말하면, 첫 번째 단락에서 언급한 것처럼 PEP의 범위도 고려해야 합니다.
이 문서에서는 메인 Python 배포판의 표준 라이브러리를 구성하는 Python 코드에 대한 코딩 규칙을 제공합니다.
그 의도는 공식적인 파이썬 배포판에 들어가는 모든 코드를 일관된 형식으로 만드는 것입니다(이것이 보편적으로 좋은 것이라는 것에 동의할 수 있기를 바랍니다™).
개별 프로그래머를 위한 공간과 탭 사이의 결정은 a) 정말 취향의 문제이고 b) 기술적인 수단(편집자, 변환 스크립트 등)으로 쉽게 처리되기 때문에 모든 토론을 끝낼 수 있는 명확한 방법이 있습니다: 하나를 선택하십시오.
Guido가 선택한 사람입니다.그는 심지어 이유를 말할 필요도 없었지만, 여전히 경험적인 데이터를 참조함으로써 그렇게 했습니다.
다른 모든 목적을 위해 이 PEP를 권장사항으로 사용하거나 무시할 수 있습니다. 즉, 사용자의 선택, 팀의 선택 또는 팀의 리더입니다.
하지만 한 가지 조언을 하자면, '-'를 섞지 마세요;-) [ed: 탭과 공백을 섞는 것은 더 이상 선택 사항이 아닙니다.]
저는 개인적으로 탭 위에 공백이 있는 것에 동의하지 않습니다.제가 보기에 탭은 문서 레이아웃 문자/메커니즘이며, 코드의 경우 공백은 내용 또는 명령 간의 설명을 위한 것입니다.
저는 탭이 실제로 문제가 아니라 사람들과 탭과 공간을 어떻게 혼합하고 싶은지가 문제라는 Jim의 말에 동의해야 합니다.
그렇긴 하지만, 저는 관습을 위해 공간을 사용하도록 강요했습니다.저는 개인적인 선호보다 일관성을 중요시합니다.
2022년 편집:공백을 사용합니다.작업 중인 특정 프로젝트의 언어 규칙과 설정된 규칙을 따릅니다.링터를 사용하여 이러한 규칙이 유지되는지 확인합니다.저장 시 형식입니다.커밋 시 보풀 발생.이렇게 하면 팀의 "자전거 타기"가 줄어듭니다.몇 년 전에 말했듯이, 개인적인 선호보다 일관성!
파킨슨의 사소함의 법칙으로도 알려진 바이크셰딩은 중요한 문제는 방치한 채 사소한 문제에 우리 시간의 불균형적인 양을 할애하는 경향을 설명합니다.
공백의 이유는 탭이 선택 사항이기 때문입니다.공백은 구두점에서 실제 가장 낮은 공통 분모입니다.
모든 적절한 텍스트 편집기에는 "탭을 공백으로 바꾸기"가 있으며 많은 사람들이 이 기능을 사용합니다.하지만 항상은 아닙니다.
일부 텍스트 편집기는 공백을 탭으로 대체할 수 있지만 이는 매우 드문 일입니다.
맨 아래 줄.공간을 잘못 사용하면 안 됩니다.탭을 사용하면 잘못될 수 있습니다.그러니 탭을 사용하지 말고 실수할 위험을 줄여주세요.
들여쓰기와 관련된 주요 문제는 탭과 공백을 혼합할 때 발생합니다.분명히 이것은 여러분이 어떤 것을 선택해야 하는지 말해주지 않지만, 여러분이 동전을 뒤집어서 그것을 고르더라도 그것을 추천하는 좋은 이유입니다.
그러나 IMHO에는 탭보다 공백을 선호하는 몇 가지 사소한 이유가 있습니다.
다른 도구.때때로 코드는 프로그래머 편집기 외부에 표시됩니다.예: 뉴스 그룹 또는 포럼에 게시됨.여기서는 일반적으로 공백이 탭보다 낫습니다. 모든 곳에서 공백이 깨지고 탭이 깨지지만 그 반대는 아닙니다.
프로그래머들은 소스를 다르게 봅니다.이것은 매우 주관적입니다. 탭의 주요 이점이거나 사용자가 어느 쪽에 있는지에 따라 탭을 피해야 하는 이유입니다.또한 개발자는 선호하는 들여쓰기로 소스를 볼 수 있으므로 2-공간 들여쓰기를 선호하는 개발자는 동일한 소스에서 8-공간을 가진 개발자와 함께 작업하면서도 원하는 대로 볼 수 있습니다.단점은 이것에 대한 영향이 있다는 것입니다. - 어떤 사람들은 너무 깊게 중첩되어 있다는 매우 가시적인 피드백을 제공하기 때문에 8-공간을 좋아합니다. - 그들은 2-indenter에 의해 체크인된 코드가 그들의 편집기에서 계속 랩핑되는 것을 볼 수 있습니다.모든 개발자가 코드를 동일한 방식으로 보게 하는 것은 더 일관성 있는 쓰기 줄 길이와 다른 문제를 야기합니다.
줄 들여쓰기가 계속됩니다.때때로 이전 항목에서 가져온 줄을 들여쓰기할 수 있습니다.
def foo(): x = some_function_with_lots_of_args(foo, bar, baz, xyzzy, blah)탭을 사용하는 경우 공백과 탭을 혼합하지 않고 편집기에서 다른 탭 위치를 사용하는 사용자를 위해 이를 정렬할 수 있는 방법이 없습니다.이렇게 하면 위의 이점이 효과적으로 사라집니다.
물론 이것은 매우 종교적인 문제입니다. 프로그래밍이 골치를 썩이는 문제입니다.가장 중요한 문제는 당신이 선호하는 것이 아니더라도 우리가 하나를 선택해야 한다는 것입니다.때때로 저는 중요한 압입의 가장 큰 장점은 적어도 우리가 브레이스 배치 화염병을 피할 수 있다는 것이라고 생각합니다.
제이미 자윈스키의 이 문제에 대한 기사도 읽을 가치가 있습니다.
탭의 문제는 탭이 보이지 않고 사람들이 탭의 너비에 동의할 수 없다는 것입니다.탭과 공백을 혼합하고 Python이 아닌 다른 위치에 탭스톱을 설정하면 Python이 보는 것과 다른 레이아웃의 코드가 표시됩니다.레이아웃이 블록을 결정하기 때문에 다른 논리를 보게 됩니다.그것은 미묘한 버그로 이어집니다.
PEP 8을 무시하고 탭을 사용해야 하거나 탭과 공백을 혼합해야 하는 경우 적어도 항상 '-tt' 인수를 사용하여 python을 실행하면 일관성 없는 들여쓰기(때로는 탭, 때로는 동일한 들여쓰기 수준의 공백)가 오류가 됩니다.또한 가능한 경우 탭을 다르게 표시하도록 편집기를 설정합니다.하지만 실제로 가장 좋은 방법은 탭을 사용하지 않는 것입니다.
탭을 사용하면 PEP 8의 또 다른 측면을 혼동할 수 있습니다.
모든 행을 최대 79자로 제한합니다.
예를 들어, 탭 너비가 2이고 저는 탭 너비가 8이라고 가정합니다.당신이 코드를 모두 작성해서 당신의 가장 긴 줄이 79자가 되도록 하면, 나는 당신의 파일을 작업하기 시작합니다.(PEP가 명시한 대로) 이제 읽기 어려운 코드가 있습니다.
대부분의 도구에서 기본 래핑은 코드의 시각적 구조를 방해합니다.
우리 모두가 4개의 공간을 사용한다면, 그것은 항상 같습니다.편집자가 80자 너비를 지원할 수 있는 사람이라면 누구나 편하게 코드를 읽을 수 있습니다.참고: 80자 제한은 그 자체로 성전이기 때문에 여기서 시작하지 맙시다.
적합하지 않은 편집기에는 공백을 탭처럼 사용하는 옵션(삽입 및 삭제 모두)이 있어야 하므로 유효한 인수가 될 수 없습니다.
질문에 대한 대답은: PEP-8은 권장 사항을 제시하기를 원하며 공백이 더 인기가 있기 때문에 탭보다 공백을 강력하게 권장할 것이라고 결정했습니다.
PEP-8에 대한 참고 사항
PEP-8에는 '인덴테이션 레벨당 4칸 사용'이 표시됩니다.
이것이 표준 권장 사항임이 분명합니다.
엉망으로 만들고 싶지 않은 정말 오래된 코드의 경우, 8개의 공백 탭을 계속 사용할 수 있습니다.
탭을 사용할 수 있는 몇 가지 상황이 있음은 분명합니다.
'탭과 공백을 함께 사용하지 마십시오.'
이것은 혼합의 명백한 금지입니다 - 저는 우리 모두가 이것에 동의한다고 생각합니다.Python은 이를 감지할 수 있으며 종종 질식합니다.-tt 인수를 사용하면 이 오류가 명시적으로 발생합니다.
Python을 들여쓰기하는 가장 일반적인 방법은 공백만 사용하는 것입니다.두 있는 라고 .
이것은 둘 다 사용된다는 것을 분명히 말해줍니다.아주명게말씀자면리드하확▁ 은 같은 안 됩니다.동일한 파일에 공백과 탭을 함께 사용해서는 안 됩니다.
'새 프로젝트의 경우 탭보다 공백만 사용하는 것이 좋습니다.'
이는 명확한 권장 사항이며 강력한 권장 사항이지만 탭 금지는 아닙니다.
저는 PEP-8에서 제 질문에 대한 좋은 답을 찾을 수 없습니다.저는 다른 언어에서 역사적으로 사용해온 탭을 사용합니다.Python은 탭을 독점적으로 사용하는 소스를 허용합니다.그 정도면 충분해요.
저는 제가 공간을 가지고 일을 해볼 줄 알았습니다.편집기에서 공백만 사용하도록 파일 형식을 구성하여 탭을 누르면 4개의 공백이 삽입됩니다.탭을 너무 많이 누르면 공백을 삭제해야 합니다!으악! 탭의 4배에 달하는 삭제 횟수!편집자는 제가 들여쓰기에 4개의 공백을 사용하고 있는지 알 수 없으며(편집자가 이 작업을 수행할 수 있지만), 한 번에 하나씩 공백을 삭제해야 한다고 주장합니다.
Python은 들여쓰기를 읽을 때 탭을 공백으로 간주하라고 할 수 없습니까?들여쓰기당 4칸, 탭당 4칸으로 합의하고 파이썬이 이를 수용할 수 있도록 한다면 문제가 없을 것입니다.
우리는 문제에 대한 상생의 해결책을 찾아야 합니다.
코드에서 항상 탭을 사용했습니다.그렇긴 하지만, 저는 최근에 공간을 사용해야 하는 이유를 발견했습니다.Nokia N900 인터넷 태블릿에서 개발할 때 탭 키가 없는 키보드가 있었습니다.이로 인해 탭을 복사하여 붙여넣거나 공백으로 코드를 다시 작성해야 했습니다.다른 전화기에서도 같은 문제가 발생했습니다.물론 이것은 Python의 표준 사용이 아니라 유념해야 할 사항입니다.
python은 프로그램 구조를 인식하기 위해 들여쓰기에 의존하기 때문에 식별을 식별하는 명확한 방법이 필요합니다.따라서 공백이나 탭을 선택해야 합니다.
하지만 파이썬은 또한 일을 하는 방법이 하나밖에 없다는 강한 철학을 가지고 있기 때문에 들여쓰기를 하는 한 가지 방법에 대한 공식적인 추천이 있어야 합니다.
공백과 탭 모두 편집자가 들여쓰기로 처리해야 하는 고유한 문제를 제기합니다.탭 처리 자체는 편집기 또는 사용자 설정에 걸쳐 균일하지 않습니다.공백은 구성할 수 없으므로 결과가 모든 곳에서 동일하게 보이도록 보장하기 때문에 보다 논리적인 선택이 가능합니다.
[사람들이] 코드를 읽고 있을 때, 그리고 그들이 새로운 코드를 다 썼을 때, 그들은 새로운 스코프(또는 sexpr, 또는 무엇이든)가 열렸을 때 코드가 들여쓰기되는 경향이 있는 화면 열 수에 관심이 있습니다.
...기술적 문제를 해결하는 가장 좋은 방법은 디스크 파일에 ASCII #9 TAB 문자가 나타나지 않도록 하는 것입니다. 디스크에 줄을 쓰기 전에 편집자가 적절한 수의 공간으로 TAB를 확장하도록 프로그래밍하십시오.
...이것은 문자열이나 문자 상수와 같이 탭이 실제로 중요한 위치에서는 절대 사용하지 않는다고 가정합니다. 하지만 저는 절대 사용하지 않습니다. 탭이 중요할 때는 항상 대신 '\t'를 사용합니다.
탭에 비해 공백을 구분할 수 있는 가장 중요한 장점은 많은 프로그래머와 프로젝트가 소스 코드에 대해 설정된 열 수를 사용한다는 것입니다. 누군가 탭 중지를 2칸으로 설정한 상태에서 변경을 커밋하고 프로젝트가 탭 중지로 4칸을 사용하면 다른 사람의 편집기 창에 긴 줄이 너무 길어집니다.저는 탭 작업이 더 쉽다는 것에 동의하지만 Python과 같은 대규모 오픈 소스 프로젝트에서 중요한 협업을 위해 공간이 더 쉽다고 생각합니다.
당신은 당신의 케이크를 먹고 그것을 먹을 수 있습니다.탭을 자동으로 공백으로 확장하도록 편집기를 설정합니다.
은 (으)ㄹ 입니다.:set expandtab빔에서.)
이미 명명된 다른 모든 이유(일관성, 절대 공간과 탭을 혼합하지 않음 등) 외에도 4개 공간 협약이 주목해야 할 몇 가지 이유가 더 있다고 생각합니다.이는 파이썬(그리고 들여쓰기가 의미를 갖는 다른 언어)에만 적용됩니다.탭은 개별 환경설정에 따라 다른 언어에서 더 유용할 수 있습니다.
만약 편집자가 탭을 표시하지 않는다면(구성에 따라 꽤 많이 발생), 다른 작성자는 당신의 코드가 4개의 공백을 사용한다고 가정할 수 있습니다. b/c는 공개적으로 사용 가능한 거의 모든 파이썬 코드가 사용합니다. 동일한 편집자가 탭 너비가 4개인 경우, 적어도 불쾌한 일이 발생할 수 있습니다.그 가난한 사람은 관습을 고수함으로써 피하기 매우 쉬운 들여쓰기 문제로 시간을 잃을 것입니다.그래서 저에게, 첫 번째 이유는 일관성 있는 버그를 피하기 위해서입니다.
탭과 공백 중 어느 것이 더 나은지에 대한 질문을 재구성하면, 탭의 장점이 무엇인지 물어봐야 합니다. 탭을 칭찬하는 게시물은 많이 봤지만, 설득력 있는 주장은 거의 없습니다. emacs, vi(m), kate 등과 같은 훌륭한 편집자.코드의 의미에 따라 적절한 들여쓰기를 수행합니다. 탭이 없어도 동일한 편집기를 백스페이스 등에서 들여쓰기하도록 쉽게 구성할 수 있습니다.
어떤 사람들은 코드의 모양/레이아웃을 자유롭게 결정할 때 매우 강한 선호도를 가지고 있고, 다른 사람들은 이 자유보다 일관성을 중요시합니다.Python은 들여쓰기가 블록 등에 사용됨으로써 이러한 자유를 크게 줄입니다.이것은 버그나 기능으로 보일 수 있지만, Python을 선택하는 것과 관련이 있습니다.개인적으로, 저는 이러한 일관성이 마음에 듭니다. 새 프로젝트에서 코딩을 시작할 때, 적어도 레이아웃은 제가 익숙한 것에 가깝기 때문에 읽기가 상당히 쉽습니다.거의 항상.
들여쓰기를 위해 공간을 사용하면 코드를 쉽게 이해할 수 있는 "레이아웃 트릭"이 가능합니다. 예를 들어, PEP8에 나열되어 있습니다.
foo = long_function_name(var_one, var_two, var_three, var_four) # the same for lists a_long_list = [1, 2, # ... 79] # or dictionaries a_dict = {"a_key": "a_value", "another_key": "another_value"}물론, 위의 내용은 다음과 같이 잘 쓰여질 수 있습니다.
foo = long_function_name( var_one, var_two, var_three, var_four) # the same for lists a_long_list = [ 1, 2, # ... 79] # or dictionaries a_dict = { "a_key": "a_value", "another_key": "another_value"}그러나 후자는 코드 줄 수가 더 많고 줄 수가 더 적다고 주장되는 경우가 있습니다(b/c 단일 화면에서 더 많은 것을 얻을 수 있음).그러나 정렬을 좋아한다면 공백(좋은 편집자의 도움을 받는 것이 좋습니다)은 어떤 의미에서 Python에서 탭보다 더 많은 자유를 제공합니다.[글쎄요, 일부 편집자는 탭을 사용하여 동일한 작업을 수행할 수 있도록 허용합니다;) - 그러나 공백이 있으면 모든 편집자가 수행할 수 있습니다.
다른 모든 사람들이 주장하는 것과 같은 주장으로 돌아가서 - PEP 8은 공백을 지시합니다(좋습니다, 강력하게 권장합니다).물론 탭만 사용하는 프로젝트라면 선택의 여지가 거의 없습니다.그러나 PEP 8 규약의 제정으로 인해 거의 모든 파이썬 프로그래머들이 이 스타일에 익숙합니다.이것은 대부분의 프로그래머들이 수용하는 스타일에 대한 합의를 찾는 것을 너무 쉽게 만듭니다.그리고 개인들이 스타일에 동의하는 것은 그렇지 않으면 매우 어려울 수 있습니다.
스타일을 적용하는 데 도움이 되는 도구는 일반적으로 추가적인 노력 없이 PEP 8을 인식합니다.그것이 좋은 이유는 아니지만, 바로 사용할 수 있다는 것은 좋은 일입니다.
내 생각에 대부분의 리눅스 텍스트 편집기는 기본값이 터무니없이 커 보입니다.탭 위에 공백을 사용해야 하는 다른 좋은 이유가 생각나지 않습니다.
탭의 일반적인 문제는 탭이 다른 환경에서 다르게 표현될 수 있다는 것입니다.
지정된 편집기에서 탭은 8개의 공백 또는 2개일 수 있습니다.
일부 편집기에서는 이 작업을 제어할 수 있지만 다른 편집기에서는 제어할 수 없습니다.
탭과 관련된 또 다른 문제는 탭이 인쇄된 출력으로 표시되는 방식입니다.대부분의 프린터는 탭을 8칸으로 해석합니다.
공백이 있으면 의심의 여지가 없습니다.모든 것이 저자의 의도대로 정렬될 것입니다.
Jim과 Thomas Wouters의 의견에 대한 토론.
문제는...탭과 공간의 폭이 모두 다를 수 있기 때문에, 그리고 프로그래머들이 어느 한 폭에 동의할 수 없기 때문에, 탭이 책임을 져야 하는 이유는 무엇입니까?
저는 짐의 말에 동의합니다. 탭은 그 자체로 사악한 것이 아닙니다.하지만 문제가 있어요
공백을 사용하여 "내 코드"가 세계의 모든 편집기에서 어떻게 보이는지 제어할 수 있습니다.만약 제가 4개의 공백을 사용한다면 -- 어떤 편집기에서 제 코드를 열든, 왼쪽 여백에서 같은 거리를 가질 것입니다.탭을 사용하면 편집기의 탭 너비 설정에 좌우됩니다. 심지어 내 코드에 대해서도 마찬가지입니다.그리고 저는 그것을 좋아하지 않습니다.
따라서 공간조차도 일관성을 보장할 수 없다는 것은 사실이지만, 공간은 적어도 어디에서나 자신의 코드 모양을 더 잘 제어할 수 있습니다. 탭이 할 수 없는 것입니다.
저는 공간이 더 쉽게 달성(그리고 강요)할 수 있게 하는 것은 코드를 작성하는 프로그래머들의 일관성이 아니라, 그 코드를 보여주는 편집자들의 일관성이라고 생각합니다.
글쎄요, 저는 PEP 8에는 그러한 "권장"이 없다고 말하고 싶습니다.탭을 쓰는 것을 금지하지는 않지만 코드를 가장 표준화된 방식으로 작성해야 하므로 공간을 사용해야 하므로 권장 사항으로 명시되어 있습니다.
그렇긴 하지만, 만약 내가 표준 가이드를 쓴다면, 탭은 코드를 들여쓰기하는 현대적이고 실용적인 방법이기 때문에 추천하고 싶습니다.
마지막으로 강조하겠습니다. 탭을 사용하도록 권장하는 것이 아니라 스타일 가이드에 명시된 대로 모두 공간을 사용해야 한다는 것입니다.
언급URL : https://stackoverflow.com/questions/120926/why-does-python-pep-8-strongly-recommend-spaces-over-tabs-for-indentation
'programing' 카테고리의 다른 글
| 목록에 포함된 판다 데이터 프레임 (0) | 2023.06.09 |
|---|---|
| VBA/Excel에서 Google Chrome 열기 (0) | 2023.06.09 |
| OpenXML 형식 SDK를 사용하여 스프레드시트에서 데이터를 읽는 방법은 무엇입니까? (0) | 2023.06.09 |
| Xcode에서 LLDB로 디버깅하는 동안 변수 값을 변경하는 방법은 무엇입니까? (0) | 2023.06.04 |
| 새 GUI를 만들 때 WPF가 Windows Forms보다 선호됩니까? (0) | 2023.06.04 |