Stack Overflow와 PEP 8 에서 파이썬 프로그램에서 들여 쓰기에만 공백을 사용하는 것이 좋습니다. 나는 일관된 들여 쓰기의 필요성을 이해할 수 있으며 그 고통을 느꼈다.
공백이 선호되는 근본적인 이유가 있습니까? 탭을 사용하는 것이 훨씬 쉽다고 생각했을 것입니다.
Stack Overflow와 PEP 8 에서 파이썬 프로그램에서 들여 쓰기에만 공백을 사용하는 것이 좋습니다. 나는 일관된 들여 쓰기의 필요성을 이해할 수 있으며 그 고통을 느꼈다.
공백이 선호되는 근본적인 이유가 있습니까? 탭을 사용하는 것이 훨씬 쉽다고 생각했을 것입니다.
답변:
이에 대한 답은 PEP [ed :이 구절은 2013 년 에 편집되었다 ]에 바로 나와있다. 나는 인용한다 :
가장 인기있는 파이썬 들여 쓰기의 방법은 공백입니다.
다른 근본적인 이유가 필요하십니까?
덜 둔하게 말하면 : 첫 번째 단락에 명시된 PEP의 범위도 고려하십시오.
이 문서는 기본 Python 배포판에 표준 라이브러리를 포함하는 Python 코드에 대한 코딩 규칙을 제공합니다.
의도는 공식 파이썬 배포판에 들어가는 모든 코드를 일관된 형식으로 만드는 것입니다 (이것이 보편적으로 Good Thing ™이라는 데 동의 할 수 있기를 바랍니다).
개별 프로그래머를위한 공간과 탭 사이의 결정은 a) 실제로 맛의 문제이며 b) 기술적 수단 (편집자, 변환 스크립트 등)으로 쉽게 처리되므로 모든 토론을 끝내는 명확한 방법이 있습니다. .
귀도는 하나를 선택했습니다. 그는 이유를 제시 할 필요조차 없었지만, 여전히 경험적 데이터를 참조하여 수행했습니다.
다른 모든 목적을 위해이 PEP를 권장 사항으로 사용하거나 선택, 팀 또는 팀 리더를 무시할 수 있습니다.
그러나 한 가지 조언을 드리겠습니다 : 혼합하지 마십시오 ;-) [ed : 탭과 공백 혼합은 더 이상 옵션이 아닙니다.]
글쎄, 모두가 공간을 향해 강하게 편향되어있는 것 같습니다. 나는 탭을 독점적으로 사용합니다. 왜 그런지 잘 압니다.
탭은 실제로 공백 이후 에 나온 멋진 발명품 입니다. 그것은 공간을 수백만 번 밀거나 가짜 탭 (공백을 생성)을 사용하지 않고 들여 쓰기를 허용합니다.
왜 모든 사람이 탭 사용을 차별하는지 모르겠습니다. 젊은이들이 새로운보다 효율적인 기술을 선택하고 펄스 다이얼링 이 멋진 새로운 기술뿐만 아니라 모든 전화기 에서 작동한다고 불평하는 것은 젊은이들을 차별하는 것과 매우 흡사 합니다. "전화 걸기 기능이 모든 전화에서 작동하지는 않기 때문에 전화가 잘못되었습니다."
편집기가 탭을 올바르게 처리 할 수 없습니까? 글쎄, 현대 편집자를 얻으십시오 . 우리는 이제 21 세기에 왔고 편집자가 첨단 기술이었던 복잡한 소프트웨어 조각이었던 시간은 오래되었습니다. 우리는 이제 엄청나게 많은 탭을 선택할 수있는 많은 편집자를 보유하고 있습니다. 또한 공백으로는 할 수없는 탭의 양을 정의 할 수 있습니다. 탭이 보이지 않습니까? 그 주장에 대해 무엇입니까? 글쎄, 당신은 공백도 볼 수 없습니다!
더 나은 편집자를 제안하기 위해 너무 대담 할 수 있습니까? 이미 10 년 전에 출시 된이 첨단 기술 중 하나는 보이지 않는 문자 를 표시 합니까? (비열한)
공백을 사용하면 삭제 및 서식 작업이 훨씬 더 많이 발생합니다. 그렇기 때문에 (그리고 이것을 알고 동의하는 다른 모든 사람들이) 파이썬 탭을 사용하는 것입니다.
탭과 공백을 혼합하는 것은 그에 대한 논쟁이 아닙니다. 그것은 엉망이며 결코 작동하지 않습니다.
나는 개인적으로 탭 위의 공백에 동의하지 않습니다. 나에게 탭은 문서 레이아웃 문자 / 메커니즘이며 공백은 코드의 경우 명령 사이의 내용 또는 묘사를위한 것입니다.
탭이 실제로 문제가 아니라 사람과 탭과 공백을 혼합하려는 방법에 대한 Jim의 의견에 동의해야합니다.
즉, 나는 컨벤션을 위해 공간을 사용하도록 강요했다. 개인 취향보다 일관성을 중요하게 생각합니다.
공백이있는 이유는 탭이 선택 사항이기 때문입니다. 공백은 문장 부호에서 실제로 가장 낮은 공통 분모입니다.
모든 괜찮은 텍스트 편집기에는 "공백으로 탭 바꾸기"가 있으며 많은 사람들이 이것을 사용합니다. 그러나 항상 그런 것은 아닙니다.
일부 텍스트 편집기는 공백을 탭으로 대체 할 수 있지만 실제로는 드 rare니다.
결론 . 공백으로 잘못 갈 수는 없습니다. 탭이 잘못되었을 수 있습니다 . 따라서 탭을 사용하지 말고 실수의 위험을 줄이십시오.
탭의 문제점은 보이지 않으며 사람들은 탭 너비에 동의 할 수 없다는 것입니다. 탭과 공백을 혼합하고 Python 이외의 다른 곳에서 tabstops를 설정하면 (8 개의 공백마다 tabstops를 사용함) Python이 보는 것과 다른 레이아웃으로 코드가 표시됩니다. 레이아웃에 따라 블록이 결정되므로 다른 논리가 표시됩니다. 그것은 미묘한 버그로 이어집니다.
PEP 8을 무시하고 탭을 사용하거나 더 나쁜 경우 탭과 공백을 혼합해야한다고 주장하는 경우 적어도 '-tt'인수로 파이썬을 실행하여 일관성 이 없는 들여 쓰기 를 만듭니다 (때로는 탭, 때로는 같은 들여 쓰기 공간) 수준) 오류. 또한 가능하면 편집기가 탭을 다르게 표시하도록 설정하십시오. 그러나 실제로 가장 좋은 방법은 탭, 마침표를 사용하지 않는 것입니다.
들여 쓰기와 관련된 주요 문제는 탭과 공백을 혼합 할 때 발생합니다. 분명히 이것은 당신이 어떤 것을 선택해야하는지 알려주지 않지만, 동전을 뒤집어서 선택하더라도 추천하는 것이 좋습니다.
그러나 IMHO는 탭보다 공백을 선호하는 몇 가지 사소한 이유가 있습니다.
다른 도구. 때로는 코드가 프로그래머의 편집기 외부에 표시됩니다. 예 : 뉴스 그룹 또는 포럼에 게시되었습니다. 스페이스는 일반적으로 탭보다 낫습니다. 스페이스는 엉망이되고 탭도 마찬가지이지만 그 반대도 아닙니다.
프로그래머는 소스를 다르게 본다. 이것은 매우 주관적입니다-탭의 주요 이점 또는 사용중인 측면에 따라 탭을 피하는 이유입니다. 또한 개발자는 선호하는 들여 쓰기를 사용하여 소스를 볼 수 있으므로 2 칸 들여 쓰기를 선호하는 개발자는 동일한 소스에서 8 칸 개발자와 작업하고 원하는대로 볼 수 있습니다. 단점은 이것에 대한 영향이 있다는 것입니다. 8 공간과 같은 일부 사람들은 너무 깊게 중첩되어 매우 눈에 띄는 피드백을 제공하기 때문에 2 인 덴터가 코드를 지속적으로 편집기에 배치하여 볼 수 있습니다. 모든 개발자가 동일한 방식으로 코드를 볼 수있게하면보다 일관성있는 wrt 줄 길이 및 기타 문제가 발생합니다.
줄 들여 쓰기 계속. 때로는 이전 줄에서 나왔음을 나타내는 줄을 들여 쓰기를 원할 수도 있습니다. 예.
def foo():
x = some_function_with_lots_of_args(foo, bar, baz,
xyzzy, blah)
탭을 사용하는 경우 공백과 탭을 혼합하지 않고 편집기에서 다른 탭 정지를 사용하는 사람들을 위해 이것을 정렬 할 수있는 방법이 없습니다. 이것은 위의 이점을 효과적으로 없애줍니다.
그러나 이것은 매우 종교적인 문제이며, 프로그래밍에는 어려움이 있습니다. 가장 중요한 문제는 선호하는 것이 아닌 경우에도 하나를 선택해야한다는 것입니다. 때로는 중요한 들여 쓰기의 가장 큰 장점은 적어도 우리가 중괄호 배치 화염을 피할 수 있다는 것입니다.
또한 가치가 독서는 이 문제에 대한 제이미 자윈 스키에 의한 문서.
탭을 사용하면 PEP 8의 또 다른 측면이 혼동됩니다.
모든 줄을 최대 79 자로 제한하십시오.
가설 적으로 탭 너비 2를 사용하고 탭 너비 8을 사용한다고 가정합니다. 가장 긴 줄이 79 자에 도달하도록 모든 코드를 작성한 다음 파일 작업을 시작합니다. 이제 PEP 상태로 인해 읽기 어려운 코드가 있습니다.
대부분의 도구에서 기본 줄 바꿈은 코드의 시각적 구조를 방해합니다.
모두 4 개의 공백을 사용하면 항상 동일합니다. 편집자가 80 자 너비를 지원할 수 있으면 누구나 코드를 편안하게 읽을 수 있습니다. 참고 : 80 자 제한은 그 자체로 거룩한 전쟁이므로 시작하지 마십시오.
sucky가 아닌 편집기에는 공백과 같은 탭을 삽입하고 삭제하는 것처럼 공백을 사용할 수있는 옵션이 있어야하므로 실제로 유효한 인수가 아니어야합니다.
이 질문에 대한 답은 PEP-8이 권장 사항을 만들고 싶을 때 공간이 더 대중적이기 때문에 탭보다 빈 공간을 강력히 추천한다는 것입니다.
PEP-8에 대한 참고 사항
PEP-8은 '들여 쓰기 수준 당 4 칸 사용' 이라고 말합니다 .
이것이 표준 권장 사항임이 분명합니다.
``엉망이 아닌 오래된 코드의 경우 8 칸 탭을 계속 사용할 수 있습니다. ''
탭을 사용할 수있는 상황이 있다는 것은 분명합니다.
'탭과 스페이스를 혼용하지 마십시오.'
이것은 혼합의 명백한 금지입니다-우리 모두 이것에 동의한다고 생각합니다. 파이썬은 이것을 감지하고 종종 질식 할 수 있습니다. -tt 인수를 사용하면 명시적인 오류가됩니다.
'파이썬을 들여 쓰는 가장 보편적 인 방법은 공백 만있는 것입니다. 두 번째로 많이 사용되는 방법은 탭만 사용하는 것입니다. '
이것은 두 가지가 모두 사용되었음을 분명히 나타냅니다. 매우 명확하게하기 위해 : 여전히 동일한 파일에서 공백과 탭을 혼합해서는 안됩니다.
'새 프로젝트의 경우 탭보다 공백 만 사용하는 것이 좋습니다.'
이것은 명확한 권장 사항이며 강력한 권장 사항이지만 탭 금지는 아닙니다.
PEP-8에서 내 질문에 대한 올바른 답변을 찾을 수 없습니다. 역사적으로 다른 언어로 사용했던 탭을 사용합니다. 파이썬은 탭을 독점적으로 사용하는 소스를 허용합니다. 그것은 나에게 충분합니다.
나는 공간을 다루는 데 갈 것이라고 생각했다. 내 편집기에서 공백을 독점적으로 사용하도록 파일 형식을 구성 했으므로 tab 키를 누르면 4 개의 공백이 삽입됩니다. 탭을 너무 여러 번 누르면 공백을 삭제해야합니다! 아아! 탭보다 4 배 많은 삭제! 내 편집자는 들여 쓰기에 4 개의 공백을 사용하고 있다고 말할 수 없으며 (편집기 가이 작업을 수행 할 수는 있지만) 한 번에 하나씩 공백을 삭제해야합니다.
파이썬은 읽기 들여 쓰기시 탭을 n 칸으로 간주한다고 말할 수 없습니까? 들여 쓰기 당 4 칸과 탭 당 4 칸에 동의하고 파이썬이 이것을 받아 들일 수 있다면 아무런 문제가 없습니다.
문제에 대한 윈-윈 솔루션을 찾아야합니다.
[사람들이] 코드를 읽고 새로운 코드를 작성하면 새로운 범위 (또는 sexpr 등)가 열릴 때 코드가 들여 쓰기되는 화면 열 수에 관심이 있습니다.
... 제 생각에 기술적 인 문제를 해결하는 가장 좋은 방법은 ASCII # 9 TAB 문자가 디스크 파일에 나타나지 않도록 명령하는 것입니다. 디스크에 줄을 쓰기 전에 TAB을 적절한 수의 공간으로 확장하도록 편집기를 프로그래밍하십시오. ..
... 이것은 문자열이나 문자 상수와 같이 실제로 중요한 곳에서는 탭을 사용하지 않는다고 가정하지만 절대 그렇게하지는 않습니다. 탭이 중요하다면 항상 '\ t'를 대신 사용합니다.
파이썬은 프로그램 구조를 인식하기 위해 들여 쓰기에 의존하기 때문에 식별을 식별하는 명확한 방법이 필요합니다. 이것이 공백이나 탭을 선택하는 이유입니다.
그러나 파이썬은 또한 한 가지 방법으로 만 할 수 있다는 강력한 철학을 가지고 있으므로 한 가지 들여 쓰기 방법에 대한 공식 권장 사항이 있어야합니다.
공백과 탭 모두 편집자가 들여 쓰기로 처리하는 데 고유 한 문제가 있습니다. 탭 자체의 처리는 편집기 또는 사용자 설정에서 균일하지 않습니다. 공백은 구성 할 수 없으므로 결과가 모든 곳에서 동일하게 보일 것임을 보장하므로보다 논리적으로 선택합니다.
탭보다 공백을 알 수있는 가장 큰 장점은 많은 프로그래머와 프로젝트가 소스 코드에 대해 설정된 수의 열을 사용하고 누군가가 탭 스톱을 2 공백으로 설정하고 변경을 커밋하면 프로젝트는 4 공백을 사용한다는 것입니다 긴 줄이 다른 사람의 편집기 창에 비해 너무 길어질 수 있습니다. 탭을 사용하는 것이 더 쉽다는 데 동의하지만 공간은 협업하기가 더 쉽다고 생각합니다. 이는 Python과 같은 대규모 오픈 소스 프로젝트에서 중요합니다.
케이크를 가지고 먹을 수 있습니다. 탭을 공백으로 자동 확장하도록 편집기를 설정하십시오.
( :set expandtab
Vim에 있을 것 입니다.)
내 생각에 대부분의 Linux 텍스트 편집기는 기본값이 기본적으로 엄청나게 크게 보입니다. 탭 위에 공백을 사용해야하는 다른 좋은 이유는 생각할 수 없습니다.
이미 명명 된 다른 모든 이유 (공백과 탭을 혼합하지 않는 등) 외에도 4 개의 공백 규칙에 주목해야 할 몇 가지 이유가 더 있다고 생각합니다. 이것들은 파이썬 (그리고 들여 쓰기가 의미가있는 다른 언어)에만 적용됩니다. 개별 환경 설정에 따라 다른 언어에서는 탭이 더 좋을 수 있습니다.
만약 편집기가 탭을 보여주지 않는다면 (이것은 구성에 따라 발생합니다), 다른 저자는 당신의 코드가 4 개의 공백을 사용한다고 가정 할 것입니다. 동일한 편집기의 탭 너비가 4이면 불쾌한 일이 발생할 수 있습니다. 최소한 가난한 사람은 컨벤션을 고수하여 피하기 매우 쉬운 들여 쓰기 문제로 인해 시간을 잃게됩니다. 저에게있어 가장 중요한 이유는 일관성있는 버그를 피하는 것입니다.
탭이나 스페이스 중 어느 쪽이 더 나은지에 대한 질문을 수정하면 탭의 장점이 무엇인지 묻어 야합니다. 나는 탭을 찬양하는 많은 글을 보았지만 그것들에 대한 설득력있는 주장은 거의 없었다. emacs, vi (m), kate와 같은 훌륭한 편집기는 탭이 없어도 코드의 의미에 따라 적절한 들여 쓰기를 수행합니다. 백 스페이스 등에서 들여 쓰기를하지 않도록 동일한 편집기를 쉽게 구성 할 수 있습니다.
어떤 사람들은 코드의 모양 / 레이아웃을 결정할 때 자신의 자유에 대해 매우 강한 선호를 가지고 있습니다. 다른 사람들은이 자유에 대한 일관성을 중요하게 생각합니다. 파이썬은 들여 쓰기가 블록 등에 사용되도록 지시함으로써 이러한 자유를 대폭 줄입니다. 이것은 버그 나 기능으로 보일 수 있지만, 파이썬을 선택할 때 발생합니다. 개인적으로, 나는이 일관성을 좋아합니다. 새로운 프로젝트에서 코딩을 시작할 때 적어도 레이아웃은 익숙한 것에 가깝기 때문에 읽기가 쉽습니다. 거의 언제나.
들여 쓰기에 공백을 사용하면 코드를 이해하는 데 도움이되는 "레이아웃 트릭"이 가능합니다. 이들의 일부 예는 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"}
그러나 후자는 더 많은 코드 라인을 필요로하고 때로는 적은 라인이 더 나은 것으로 주장됩니다 (단일 화면에서 더 많은 것을 얻는다). 그러나 정렬을 좋아한다면 공백 (좋은 편집자가 선호하는 것이 좋습니다)은 탭보다 파이썬에서 더 많은 자유를줍니다. [글쎄, 일부 편집자는 탭을 사용하여 동일한 작업을 수행 할 수 있다고 생각합니다.)-공백이 있으면 모두 수행합니다 ...]
PEP 8은 다른 사람들이했던 것과 같은 주장으로 되돌아 가서 공간을 지시합니다 (권장). 물론 탭만 사용하는 프로젝트에 온다면 선택의 여지가 거의 없습니다. 그러나 PEP 8 규칙이 설정 되었기 때문에 거의 모든 Python 프로그래머가이 스타일에 익숙합니다. 이렇게하면 대부분의 프로그래머가 받아 들일 수있는 스타일에 대한 합의를 찾는 것이 훨씬 쉬워집니다. 개인이 스타일에 동의하는 것은 그렇지 않으면 매우 어려울 수 있습니다.
스타일을 적용하는 데 도움이되는 도구는 일반적으로 추가 노력없이 PEP 8을 인식합니다. 좋은 이유는 아니지만, 즉시 사용할 수있는 것이 좋습니다.
탭의 일반적인 문제는 탭이 다른 환경에서 다르게 표시 될 수 있다는 것입니다.
주어진 편집기에서 탭은 8 개의 공백 또는 2 일 수 있습니다.
개일 일부 편집기에서는이를 제어 할 수 있지만 다른 편집기에서는 제어 할 수 없습니다.
탭의 또 다른 문제는 인쇄 출력에 탭이 표시되는 방식입니다. 대부분의 프린터는 탭을 8 개의 공백으로 해석합니다.
공백이 있으면 의심의 여지가 없습니다. 저자가 의도 한대로 모든 것이 정렬됩니다.
코멘트에서 짐과 토마스 Wouters 사이의 토론에 .
문제는 ... 탭과 공백의 너비가 다를 수 있기 때문에-프로그래머가 어느 쪽의 너비에 동의 할 수 없기 때문에 탭이 비난을받는 이유는 무엇입니까?
나는 Jim이 탭 자체가 악한 것이 아니라는 점에 동의합니다. 그러나 문제가 있습니다 ...
공백으로 "MY OWN CODE"를 제어 할 수 있습니다 전 세계의 모든 편집기에서 가 표시되는 있습니다. 4 개의 공백을 사용하면 코드를 여는 편집기에 관계없이 왼쪽 여백과 같은 거리가됩니다. 탭을 사용하면 편집기의 탭 너비 설정, 심지어 내 소유 코드의 자비에 달려 있습니다. 그리고 나는 그것을 좋아하지 않습니다.
따라서 공백조차도 일관성을 보장 할 수는 없지만 탭을 통해 불가능한 OWN 코드의 모양을 더 잘 제어 할 수 있습니다.
나는 코드를 작성하는 프로그래머의 일관성이 아니라 코드를 보여주는 편집기의 일관성이 있다고 생각합니다. 공백은 쉽게 달성하고 부과합니다.