언어에서 블록의 명시 적 마커보다 들여 쓰기를 선호해야하는 이유는 무엇입니까?

저는 Haskell을 배우고 있으며 자동 들여 쓰기 도구를 찾고있었습니다. 나는 많이 보지 않았고 Haskell (파이썬에서와 같이)에서 들여 쓰기가 블록을 의미한다는 것을 알았습니다. 결과적으로 C 계열의 다른 언어와 마찬가지로 {} (중괄호) 또는 begin end키워드 와 같은 명시 적 마커를 사용하는 자동 서식 도구를 만드는 것은 불가능하다고 생각합니다 .

가독성을 위해 들여 쓰기를 시행하는 언어는 신경 쓰지 않지만 들여 쓰기를 시행하고 명시 적 마커를 갖는 것의 이점을 이해할 수 없으므로 자동화 된 도구가 어떤 블록에 속하는지 이해할 수 있습니다.

들여 쓰기를 선호하여 블록을 표시하면 코드 가 더 좋아 보이 더라도 여전히 이점을 이해하지 못합니다. 탭과 공백이 다른 편집기와 다른 글꼴 (예 : 단정 한 글꼴은 더 ​​깔끔 해짐)로 다르게 표시되면 프로그래머가 코드를 적절하게 제시 할 것으로 기대할 수 없습니다. 현재 텍스트 편집기를 고려할 수있는 도구는 코드를 올바르게 형식화하는 데 훨씬 적합합니다.

언어 설계자가 명시 적 블록 마커보다 들여 쓰기를 선택하는 이유는 무엇입니까?

귀도 폰 로섬

에서 귀도 반 로섬 (Guido van Rossum)과의 인터뷰 전체 텍스트에서 볼 수있는, books.google.com으로 (강조 광산) :

그룹화를위한 들여 쓰기 선택은 파이썬에서 새로운 개념이 아니었다. 나는 이것을 ABC로부터 물려 받았지만 오래된 언어 인 occam에서도 발생했습니다. ABC 작가가 아이디어를 occam에서 얻었는지 또는 독립적으로 발명했는지 또는 공통 조상이 있는지는 알 수 없습니다. 물론 다른 영역에서와 같이 ABC의 리드를 따르지 않기로 선택할 수 있었지만 (예 : ABC는 언어 키워드 및 프로 시저 이름에 대문자를 사용 했지만 복사하지 않은 아이디어) 이 기능을 매우 좋아했습니다 . C를 사용하는 동안 비트 는 중괄호를 배치 할 위치 에 대해 당시 C 사용자에게 공통적 인 특정 유형의 무의미한 토론을 없애는 것처럼 보였습니다 .

Von Rossum은 ABC 에서 많은 영감을 받았으며 , 모든 사본을 복사 할 필요는 없지만, 종교적인 전쟁을 피하는 데 도움이 될 수 있기 때문에 들여 쓰기 사용이 유지되었습니다.

또한 읽을 수있는 코드는 어쨌든 그룹화를 나타 내기 위해 들여 쓰기를 자발적으로 사용 한다는 것을 잘 알고 있었고 , 중괄호를 사용하여 들여 쓰기가 구문 그룹화에 동의하지 않는 코드의 미묘한 버그를 발견했습니다 . 프로그래머와 검토자는 들여 쓰기가 그룹화와 일치한다고 가정했습니다 따라서 버그를 발견하지 못했습니다. 다시 한 번 긴 디버깅 세션에서 유용한 교훈을 얻었습니다.

Rossum은 또한 그룹화와 들여 쓰기 간의 불일치로 인해 버그를 목격했으며 분명히 코드를 구조화하기 위해 들여 쓰기에 의존하는 것이 프로그래밍 오류 ¹ 에서 더 안전 할 것 입니다.

Donald E. Knuth & Peter J. Landin

언급 된 인터뷰에서 Guido는 Don Knuth의 들여 쓰기 사용 아이디어를 언급합니다. 자세한 내용은 Knuth Indentation Quote rediscovered에 자세히 설명되어 있으며 goto 문으로 구조화 된 프로그래밍 을 인용합니다 . Knuth는 또한 Peter John Landin의 다음 700 가지 프로그래밍 언어를 참조합니다 (들여 쓰기에 대한 토론 섹션 참조). Landin 은 시작 / 종료 블록 대신 들여 쓰기가있는 첫 번째 언어처럼 보이는 ISWIM 을 설계 했습니다 . 이 논문은 프로그램을 구조화하기 위해 들여 쓰기를 사용하는 것이 타당성이 아니라 실제 주장이 유리하다는 주장에 더 가깝습니다.

_{1. 나는 이것이 실제로 발생해야 할 프로그래밍 오류를 포착하고 복구하기 위해 그룹화 구문과 자동 서식을 모두 선호 한다는 주장이라고 생각합니다 . 파이썬에서 들여 쓰기를 망치면 코드를 디버깅하는 사람이 올바른 것을 추측해야합니다.}

if (test(x)):
  foo(x)
  bar(x)

_{bar테스트가 성공한 경우에만 항상 전화 해야 합니까?}

_{그룹화 구문은 코드를 자동 들여 쓰기 할 때 실수를 발견하는 데 도움이되는 중복 수준을 추가합니다. C에서 동등한 코드는 다음과 같이 자동 들여 쓰기 할 수 있습니다.}

if (test(x))
  foo(x);
bar(x);

_{bar와 동일한 수준에 있도록 의도 한 경우 foo코드 구조에 따라 자동 들여 쓰기를 사용하면 foo및에 괄호를 추가하여 수정할 수있는 문제가 있음을 알 수 있습니다 bar.}

_{에서 파이썬 : 신화는 들여 쓰기에 대해 , C에서 가정으로 나쁜 예는있다 :}

/*  Warning:  bogus C code!  */

if (some condition)
        if (another condition)
                do_something(fancy);
else
        this_sucks(badluck);

_{위와 같은 경우입니다. Emacs에서 전체 블록 / 기능을 강조 표시하고 Tab 키를 누르면 모든 코드가 다시 들여 쓰기됩니다. 인간의 들여 쓰기와 코드 구조의 불일치로 인해 무언가 잘못되었다는 것을 알 수 있습니다 (앞의 주석!).}

_{또한 C에서 들여 쓰기가 해제 된 중간 코드는 단순히 마스터 분기를 통해 코드를 작성하지 않으며 모든 스타일 검사를 수행하면 GCC / Jenkins가 비명을 지 릅니다. 나는 최근에 파이썬에서 위에서 설명한 것과 비슷한 문제를 겪었고 한 단계의 들여 쓰기로 문을 닫았습니다. 때로는 C에 닫는 중괄호를 넘어서는 코드가 있지만 Tab 키를 누르면 코드가 "잘못"들여 쓰기됩니다. 버그를 볼 기회가 한 번 더 있습니다.}

이것은 매우 주관적이고 많은 화염 전쟁의 원인입니다. 하나:

블록 과 들여 쓰기를 구분하는 기호 가 두 가지 방법으로 동일한 정보를 표현하기 때문에 DRY 원칙을 위반합니다 . 자동 들여 쓰기 도구의 존재는 이 DRY 위반 의 증상 입니다. 들여 쓰기를 자동으로 생성 할 수 있다는 것은 중복 정보임을 나타내며 , 들여 쓰기와 기호 가 동기화되지 않아 코드를 오도 할 수 있습니다.

Python Design and History FAQ 는이를 매우 명확하게 설명합니다.

왜 파이썬은 문장 그룹화에 들여 쓰기를 사용합니까?

귀도 반 로섬 (Guido van Rossum)은 그룹화에 들여 쓰기를 사용하는 것이 매우 우아하며 일반적인 파이썬 프로그램의 명확성에 크게 기여한다고 믿고 있습니다. 대부분의 사람들은 잠시 후에이 기능을 좋아하는 법을 배웁니다.

시작 / 끝 괄호가 없기 때문에 파서가 인식하는 그룹화와 인간 독자 사이에 의견 차이가있을 수 없습니다.

파이썬 용 자동 들여 쓰기 도구를 만들 수 없다는 것은 사실이지만 좋은 일입니다. 즉, 구문을 조정하기 위해 자동화 된 도구가 필요한 구문에 중복성이 없음을 의미합니다.

탭 대 공백은 Python에서 합법적 인 문제이므로 동일한 코드베이스에서 탭과 공백 (들여 쓰기)을 혼합하지 않는 것이 좋습니다.

파이썬은 (이전의) 이전 언어 인 ABC에서 상당한 들여 쓰기를 물려 받았습니다. ABC는 사용성 테스트 를 사용 하여 디자인을 지시 한 프로그래밍 언어 중 하나입니다 . 따라서 구문에 대한 논의는 일반적으로 주관적인 의견과 개인적 선호에 달려 있지만, 중요한 들여 쓰기의 선택은 실제로 더 견고한 기초를 가지고 있습니다.

언어 설계자는 코드를 읽을 때 세미콜론과 중괄호에 노이즈가 추가되어 생산성이 저하된다고 생각하기 때문에 구문 적으로 중요한 공백을 선택합니다. 또 다른 일반적인 이유는 잘못된 / 일관되지 않은 코딩 스타일이 가독성을 떨어 뜨리기 때문입니다. 공통 들여 쓰기 체계를 강요하면 언어의 가독성이 전반적으로 향상됩니다. 나중에 자동 포맷 IDE가 더 일반적이지만 여전히 적용 할 수 있기 때문에 그 이후의 이유는 덜 중요합니다.