파이썬 pep-8은 들여 쓰기를 위해 탭 위에 공백을 강력하게 권장하는 이유는 무엇입니까?
나는 스택 오버플로와 PEP 8 에서 파이썬 프로그램에서 들여 쓰기에만 공백을 사용하는 것이 좋습니다. 나는 일관된 들여 쓰기의 필요성을 이해할 수 있으며 그 고통을 느꼈다.
공백이 선호되는 근본적인 이유가 있습니까? 탭을 사용하는 것이 훨씬 쉽다고 생각했을 것입니다.
이에 대한 답은 PEP [ed :이 구절은 2013 년 에 편집되었다 ]에 바로 나와있다. 나는 인용한다 :
가장 인기있는 파이썬 들여 쓰기의 방법은 공백입니다.
다른 근본적인 이유가 필요하십니까?
덜 둔하게 말하면 : 첫 번째 단락에 명시된 PEP의 범위도 고려하십시오.
이 문서는 기본 Python 배포판에 표준 라이브러리를 포함하는 Python 코드에 대한 코딩 규칙을 제공합니다.
의도는 공식 파이썬 배포판에 들어가는 모든 코드를 일관된 형식으로 만드는 것입니다 (이것이 보편적으로 Good Thing ™이라는 데 동의 할 수 있기를 바랍니다).
개별 프로그래머를위한 공간과 탭 사이의 결정은 a) 실제로 맛의 문제이며 b) 기술적 수단 (편집자, 변환 스크립트 등)으로 쉽게 처리되므로 모든 토론을 끝내는 명확한 방법이 있습니다. .
귀도는 하나를 선택했습니다. 그는 이유를 제시 할 필요조차 없었지만, 여전히 경험적 데이터를 참조하여 수행했습니다.
다른 모든 목적을 위해이 PEP를 권장 사항으로 사용하거나 선택, 팀 또는 팀 리더를 무시할 수 있습니다.
그러나 한 가지 조언을 드리겠습니다 : 혼합하지 마십시오 ;-) [ed : 탭과 공백 혼합은 더 이상 옵션이 아닙니다.]
글쎄, 모든 사람들이 우주를 향해 강하게 편향되어있는 것 같습니다. 나는 탭을 독점적으로 사용합니다. 왜 그런지 잘 압니다.
탭은 실제로 공백 이후 에 나온 멋진 발명품 입니다. 그것은 공간을 수백만 번 밀거나 가짜 탭 (공백을 생성)을 사용하지 않고 들여 쓰기를 허용합니다.
왜 모두가 탭 사용을 차별하는지 모르겠습니다. 이는 더 효율적인 새로운 기술을 선택하고 펄스 다이얼링 이 멋진 새로운 기술뿐만 아니라 모든 전화 에서 작동한다고 불평하는 젊은 사람들을 차별하는 노인과 매우 흡사 합니다. "모든 전화에서 톤 다이얼링이 작동하는 것은 아닙니다. 이것이 잘못된 것입니다."
편집기가 탭을 올바르게 처리 할 수 없습니까? 글쎄, 최신 편집자를 얻으십시오 . 우리는 이제 21 세기에 왔고 편집자가 첨단 기술이었던 복잡한 소프트웨어 조각이었던 시간은 오래되었습니다. 우리는 이제 엄청나게 많은 탭을 선택할 수있는 많은 편집자를 가지고 있습니다. 또한 공백으로는 할 수없는 탭의 양을 정의 할 수 있습니다. 탭이 보이지 않습니까? 그 주장에 대해 무엇입니까? 글쎄, 당신은 공백도 볼 수 없습니다!
더 나은 편집자를 제안하기 위해 너무 대담 할 수 있습니까? 이미 10 년 전에 출시 된이 첨단 기술 중 하나는 보이지 않는 문자 를 표시 합니까? (비열한)
공백을 사용하면 삭제 및 서식 작업이 훨씬 더 많이 발생합니다. 그렇기 때문에 (그리고 이것을 알고 동의하는 다른 모든 사람들이) 파이썬 탭을 사용하는 이유입니다.
탭과 공백을 혼합하는 것은 그에 대한 논쟁이 아닙니다. 그것은 엉망이며 결코 작동하지 않습니다.
나는 개인적으로 탭 위의 공백에 동의하지 않습니다. 나에게 탭은 문서 레이아웃 문자 / 메커니즘이며 공백은 코드의 경우 명령 사이의 내용 또는 묘사를위한 것입니다.
탭이 실제로 문제가 아니라 사람과 탭과 공백을 혼합하는 방법에 대한 Jim의 의견에 동의해야합니다.
즉, 나는 컨벤션을 위해 공간을 사용하도록 강요했다. 개인 취향보다 일관성을 중요하게 생각합니다.
공백이있는 이유는 탭이 선택 사항이기 때문입니다. 공백은 문장 부호에서 실제로 가장 낮은 공통 분모입니다.
모든 괜찮은 텍스트 편집기에는 "공백으로 탭 바꾸기"가 있으며 많은 사람들이 이것을 사용합니다. 그러나 항상 그런 것은 아닙니다.
일부 텍스트 편집기는 공백을 탭으로 대체 할 수 있지만 실제로는 드 this니다.
결론 . 공백으로 잘못 갈 수는 없습니다. 탭이 잘못되었을 수 있습니다 . 따라서 탭을 사용하지 말고 실수의 위험을 줄이십시오.
탭의 문제점은 보이지 않으며 사람들은 탭의 너비에 동의 할 수 없다는 것입니다. 탭과 공백을 혼합하고 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 자로 제한하십시오.
Let's say, hypothetically, that you use a tab width of 2 and I use a tab width of 8. You write all your code so your longest lines reach 79 characters, then I start to work on your file. Now I've got hard-to-read code because (as the PEP states):
The default wrapping in most tools disrupts the visual structure of the code
If we all use 4 spaces, it's ALWAYS the same. Anyone whose editor can support an 80 character width can comfortably read the code. Note: The 80 character limit is a holy war in and of itself, so let's not start that here.
Any non-sucky editor should have an option to use spaces as if they were tabs (both inserting and deleting), so that really shouldn't be a valid argument.
The answer to the question is: PEP-8 wants to make a recommendation and has decided that since spaces are more popular it will strongly recommend spaces over tabs.
Notes on PEP-8
PEP-8 says 'Use 4 spaces per indentation level.'
Its clear that this is the standard recommendation.
'For really old code that you don't want to mess up, you can continue to use 8-space tabs.'
Its clear that there are SOME circumstances when tabs can be used.
'Never mix tabs and spaces.'
This is a clear prohibition of mixing - I think we all agree on this. Python can detect this and often chokes. Using the -tt argument makes this an explicit error.
'The most popular way of indenting Python is with spaces only. The second-most popular way is with tabs only.'
This clearly states that both are used. Just to be ultra-clear: You should still never mix spaces and tabs in same file.
'For new projects, spaces-only are strongly recommended over tabs.'
This is a clear recommendation, and a strong one, but not a prohibition of tabs.
I can't find a good answer to my own question in PEP-8. I use tabs, which I have used historically in other languages. Python accepts source with exclusive use of tabs. That's good enough for me.
I thought I would have a go at working with spaces. In my editor, I configured a file type to use spaces exclusively and so it inserts 4 spaces if I press tab. If I press tab too many times, I have to delete the spaces! Arrgh! Four times as many deletes as tabs! My editor can't tell that I'm using 4 spaces for indents (although AN editor might be able to do this) and obviously insists on deleting the spaces one at a time.
Couldn't Python be told to consider tabs to be n spaces when its reading indentations? If we could agree on 4 spaces per indentation and 4 spaces per tab and allow Python to accept this, then there would be no problems.
We should find win-win solutions to problems.
I've always used tabs in my code. That said, I've recently found a reason to use spaces: When developing on my Nokia N900 internet tablet, I now had a keyboard without a tab key. This forced me to either copy and paste tabs or re-write my code with spaces. I've run into the same problem with other phones. Granted, this is not a standard use of Python, but something to keep in mind.
When [people are] reading code, and when they're done writing new code, they care about how many screen columns by which the code tends to indent when a new scope (or sexpr, or whatever) opens...
...My opinion is that the best way to solve the technical issues is to mandate that the ASCII #9 TAB character never appear in disk files: program your editor to expand TABs to an appropriate number of spaces before writing the lines to disk...
...This assumes that you never use tabs in places where they are actually significant, like in string or character constants, but I never do that: when it matters that it is a tab, I always use '\t' instead.
Since python relies on indentation in order to recognize program structure, a clear way to identify identation is required. This is the reason to pick either spaces or tabs.
However, python also has a strong philosophy of only having one way to do things, therefore there should be an official recommendation for one way to do indentation.
Both spaces and tabs pose unique challenges for an editor to handle as indentation. The handling of tabs themselves is not uniform across editors or even user settings. Since spaces are not configurable, they pose the more logical choice as they guarantee that the outcome will look everywhere the same.
The most significant advantage I can tell of spaces over tabs is that a lot of programmers and projects use a set number of columns for the source code, and if someone commits a change with their tabstop set to 2 spaces and the project uses 4 spaces as the tabstop the long lines are going to be too long for other people's editor window. I agree that tabs are easier to work with but I think spaces are easier for collaboration, which is important on a large open source project like Python.
You can have your cake and eat it to. Set your editor to expand tabs into spaces automatically.
(That would be :set expandtab in Vim.)
Besides all the other reasons already named (consistency, never mixing spaces and tabs etc) I believe there are a few more reasons for the 4 spaces convention to note. These only apply to Python (and maybe other languages where indentation has meaning). Tabs may be nicer in other languages, depending on individual preferences.
If an editor doesn't show tabs (which happens, depending on the configuration, in quite a few), another author might assume that your code uses 4 spaces, b/c almost all of the Python code being publicly available does; if that same editor happens to have a tab width of 4, nasty things may happen - at least, that poor person will lose time over an indentation issue that would have been very easy to avoid by sticking to the convention. So for me, the number one reason is to avoid bugs with consistency.
Reframing the question of which is better, tabs or spaces, one should ask which the advantages of tabs are; I've seen plenty posts praising tabs, but few compelling arguments for them; good editors like emacs, vi(m), kate, ... do proper indentation depending on the semantics of your code - even without tabs; the same editors can easily be configured to unindent on backspace etc.
Some people have very strong preferences when it comes to their freedom in deciding the look/ layout of code; others value consistency over this freedom. Python drastically reduces this freedom by dictating that indentation is used for blocks etc. This may be seen as a bug or a feature, but it sort of comes with choosing Python. Personally, I like this consistency - when starting to code on a new project, at least the layout is close to what I'm used to, so it's fairly easy to read. Almost always.
Using spaces for indentation allows "layout tricks" that may facilitate to comprehend code; some examples of these are listed in PEP8; eg.
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"}Of course, the above can also be written nicely as
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"}However, the latter takes more lines of code and less lines are sometimes argued to be better (b/c you get more on a single screen). But if you like alignment, spaces (preferably assisted by a good editor) give you, in a sense, more freedom in Python than tabs. [Well, I guess some editors allow you to do the same w/ tabs ;) - but with spaces, all of them do...]
Coming back to the same argument that everybody else makes - PEP 8 dictates (ok, strongly recommends) spaces. If coming to a project that uses tabs only, of course, you have little choice. But because of the establishment of the PEP 8 conventions, almost all Python programmers are used to this style. This makes it sooooo much easier to find a consensus on a style that is accepted by most programmers... and having individuals agree on style might be very hard otherwise.
Tools that help enforcing style are usually aware of PEP 8 without extra effort. That's not a great reason, but it's just nice to have things work ~out of the box.
My guess is that most the linux text editors make defaults look ridiculously large by default. I can't think of any other good reason to use spaces over tabs.
The universal problem with tabs is that they can be represented differently in different environment.
In a given editor, a tab might be 8 spaces or it might be 2.
In some editors, you can control this, while in others you can't.
Another issue with tabs is how they are represented in printed output. I believe most printers interpret a tab as 8 spaces.
With spaces, there is no doubt. Everything will line up as the author intended.
On the discussion between Jim and Thomas Wouters in the comments.
The issue was... since the width of tabs and spaces both can vary -- and since programmers can't agree on either width -- why is it that tabs bear the blame.
I agree with Jim on that -- tabs are NOT evil in and of themselves. But there is a problem...
With spaces I can control how "MY OWN CODE" looks in EVERY editor in the world. If I use 4 spaces -- then no matter what editor you open my code in, it will have the same distance from the left margin. With tabs I am at the mercy of the tab-width setting for the editor -- even for MY OWN CODE. And I don't like that.
So while it is true that even spaces can't guarantee consistency -- they at least afford you more control over the look of your OWN code everywhere -- something that tabs can't.
I think it's NOT the consistency in the programmers writing the code -- but the consistency in editors showing that code -- that spaces make easier to achieve (and impose).
'IT story' 카테고리의 다른 글
| 자바 스크립트 : 자연 숫자의 영숫자 문자열 (0) | 2020.06.24 |
|---|---|
| HTML을 이미지로 렌더링 (0) | 2020.06.24 |
| 소프트 삭제는 좋은 생각입니까? (0) | 2020.06.24 |
| move_uploaded_file은 내가 수행 한 모든 구성 후에 "스트림 열기 실패 : 권한 거부"오류를 발생시킵니다. (0) | 2020.06.24 |
| Gradle에서 환경 변수를 얻는 더 좋은 방법이 있습니까? (0) | 2020.06.24 |