탭과 공백 — 모든 상황에서 모든 상황에 적합한 들여 쓰기 특성은 무엇입니까? [닫은]

drupal.org에 호스팅 된 코드의 코딩 표준은 코드를 들여 쓰기 위해 두 개의 공백을 사용하도록 제안합니다. 다른 사이트에서는 탭을 사용하여 코드를 들여 쓰는 것이 좋습니다.

모든 상황과 모든 상황에 적합한 들여 쓰기 특성은 무엇입니까? 당신이주는 대답을 설명하십시오.

공백

환경에 따라 탭은 다른 수의 열이 될 수 있지만 공백은 항상 하나의 열입니다.

들여 쓰기를 구성하는 공백 (또는 탭)의 수와 관련하여 특정 탭 중지 값을 사용하는 것보다 코드 전체에서 일관성을 유지하는 것이 더 중요합니다.

탭

물론 일관성은 둘 이상의 문제가되며 IDE가 우수하면 차이점을 무시할 수 있습니다. 즉,이 스레드의 요점은 거룩한 전쟁이어야한다는 것입니다.

나는 탭을 선호합니다 :

• 그들은 들여 쓰기를 위해 특별히 고안된 캐릭터입니다.
• 들여 쓰기 크기가 다른 환경 설정을 가진 개발자는 코드를 변경하지 않고 코드의 모양을 변경할 수 있습니다 (데이터 분리 및 격렬한 승리를위한 프레젠테이션)!
• 탭으로 무언가를 반 들여 쓰기는 불가능합니다. 따라서 3 개의 공백을 사용한 일부 웹 사이트의 코드를 4 칸 들여 쓰기 파일로 복사 할 때 정렬 오류를 처리 할 필요가 없습니다.

탭을 사용하여 줄의 시작 부분을 들여 쓰고 들여 쓰기 수준 당 한 개의 탭을 만들고 모두가 원하는 너비를 선택할 수 있도록합니다.

줄 안에 문자를 정렬하려면 공백을 사용 하여 탭 크기에 관계없이 항상 줄을 정렬하십시오.

그리고이 어리석은 일이 처음부터 문제가되게했던 초기 소프트웨어 제작자를 모두 찾아서 펀치하십시오.
(이것이 왜 논의 된 것입니까? 다음에 줄 바꿈에 여러 문자를 사용하고 싶다고 말할 것입니다!)

탭

• 실수를 더 눈에 띄게 만들면 공간을 미세하게 관리하는 것이 귀찮습니다.
• 일관성 이 있으며 잘못 설명하지 않는 한 들여 쓰기에만 사용됩니다.
• 사용자 정의 할 수 있습니다 , 당신은 그들이 얼마나 넓은 편집기의 옵션에 지정할 수 있습니다.
• 더 생산적 이므로 1 탭을 누를 수있는 경우 4 개의 공백을 입력하십시오.
• 여러 공간보다 크기가 적습니다.
• 공간보다 더 많은 공간을 차지하십시오.
• 통과하는 데 걸리는 시간이 줄어 듭니다 .
• IDE에서 더 잘 작동하는 경향이 있습니다.

탭이 완전히 쓸모없는 곳에 공백을 사용해야합니다.

매개 변수와 주석을 정렬하더라도 탭이 여전히 더 잘 작동 합니다.

탭에 대한 모든 주장은 이론적으로 훌륭합니다. 그러나...

이론적으로는 실천과 이론이 동일합니다. 실제로는 그렇지 않습니다.

예, 탭을 사용하면 들여 쓰기 수준을 결정할 수 있습니다. 예, 탭과 공백을 조합하여 사물을 정렬 할 수 있습니다. 이상적인 세상에서는

실제로 공백과 탭의 차이점을 볼 수 없으며 코드를 이동할 때 항상 혼합되는 것처럼 보이며 탭이 8 열로 설정된 다른 프로그램에서 코드를 보는 것이 번거 롭습니다.

나는 탭을 사용했다. 그런 다음 팀의 일원으로 일하고 코드를 공유하기 시작했습니다. 나는 공간의 제안자가되었다. 그래서 탭의 유토피아에 동조 할 수는 있지만 공백을 사용하지 않는다고 상상할 수는 없습니다.

관심을 가질만한 몇 가지 관련 의견 :

• 귀도는 공간을 말한다
• 조엘은 공간을 말한다
• Atwood는 공간을 말한다
• Zawinski는 공간을 말합니다.

승리를위한 탭.

난 절대적으로 미움. 4. 공백.

왜? 주로 키보드로 코드를 탐색 left left left left하고 하나의 들여 쓰기를 다루기 위해 끊임없이 충돌 해야 하기 때문에 피곤 합니다. 이것은 메모장 + +의 초기 버전과 심지어 포맷 버튼과 같은 것이없는 일반 Windows 메모장에서 태어났습니다. 다른 곳에서 4를 사용했을 때 사람들이 3을 사용할 때 많은 문제가있었습니다.

다른 이유는 탭 문자 가 들여 쓰기를 위해 특별히 존재 하고 나중에 탐색에만 채택 되었기 때문입니다. space space space space단순한 tab것이 효과가 있을 때 우리는 왜하고 있습니까? 간단한 탭과 환경 설정 옵션이 작동 할 때 IDE에서 2-5 간격의 코드와 형식을 올바르게 처리해야하는 이유는 무엇입니까?

불행히도 나는 소수입니다.

각 개발자가 탭 당 들여 쓰기 양을 제어 할 수 있기 때문에 개인적으로 모든 것에 탭을 사용하고 싶습니다. 그렇게하면 디스플레이의 유연성을 얻을 수 있습니다.

즉, 유지 관리 작업을 수행하는 데 많은 시간을 소비하기 때문에 일반적으로 파일에 코딩 스타일이 무엇이든 모방합니다.

나는 적절한 들여 쓰기 (적어도 사소한 전쟁이없는 것은 아님)와 같은 것이 있다고 생각하지 않습니다.

개인적으로 나는 네 개의 공간을 좋아합니다. 그들은 훨씬 더 빨리 코드를 읽을 수있게 해주 었으며 모든 편집기에서 심지어 Vi까지 동일하게 보입니다.

공백은 주석을 코드의 오른쪽, 함수 매개 변수 목록, 복잡한 여러 줄 표현 또는 그 성격에 맞출 때 아름다운 작품이 모든 사람에게 올바르게 나타나기를 원하기 때문 입니다. 탭을 사용하고 사람들이 탭 스톱을 다르게 설정하도록 허용하면 가장 단순한 코드 들여 쓰기 사례를 제외하고 정렬이 중단됩니다.

게다가, 전 세계의 모든 사람들이 vim을 사용해야한다는 것이 명백히 명백합니다. 이는 공간 들여 쓰기 파일에서도 "탭 정지"를 들여 쓰기, 들여 쓰기 및 탐색이 쉽지 않습니다.

탭은 정의에 따라 들여 쓰기에 사용되는 자연스럽고 정통적인 선택입니다.

불행히도 탭은 고르지 않게 구현되므로 실제 솔루션은 4 개 공간뿐입니다.

당신은 분명히 조합 접근법이 필요합니다.

다른 개발자와 코드를 공유하는 경우 표준화해야하며, 불가능하기 때문에 (koff koff) 모든 사람이 4 개의 공백을 수행하도록해야합니다.

그런 다음 멍청하지 않을만큼 똑똑한 편집기가 필요합니다. 들여 쓰기 된 것처럼 앞면에 4 개의 공백이있는 줄을 처리해야한다는 것을 알고 있습니다. 최신 IDE 또는 프로그래머의 편집기는 탭 대신 공백이있는 코드를 자동 흐름시킬 수 있습니다.

누군가 이것을 구현할 수없는 이유는 무엇입니까?

• 코드는 해당 시스템에 유리한 컴팩트 형식으로 저장됩니다
• 각 개발자가 코드를 열면 원하는 방식으로 정확하게 형식이 지정됩니다.
• 완료되면 컴팩트 형식으로 돌아갑니다.

모두 자신의 '자신의'형식을 볼 때 모두가 행복합니다

그렇게 어려운가요?

스페이스 또는 탭-Atwood가 실제로 말하는 것은 한 가지를 선택하고 프로젝트에서 일관성을 유지하는 것입니다. 코드 형식의 유일한 성배는 일관성을 유지하여 코드를 유지하는 정신병자가 상황을 영구적으로 해결해야한다고 느끼지 않도록하는 것입니다.

즉, 파이썬이나 공백이 실제 프로그래밍 구조 인 다른 언어로 작업하는 경우 탭을 사용한다고 상상할 수 없습니다.

나는 4 공간 종류의 사람입니다. 탭은 일관성이 없습니다.

분명히 탭은 Delphi에서 엉망이되어 델파이에서 탭을 사용하지 않습니다.

그러나 Emacs를 사용하여 다른 모든 작업을 수행하고 탭은 원하는 위치로 정확하게 이동하기 때문에 항상 탭을 사용합니다.

정답은 모든 상황에 대해 하나의 적절한 들여 쓰기 문자가있을 수 없다는 것입니다. 문자를 사용한 형식 지정은 융통성이 없으며 팀 내에서 다른 스타일을 사용할 때 충돌이 발생할 수 있습니다.

다른 형식 지정 스타일로 코드를 완벽하고 유연하게 형식화하는 유일한 방법은 가상으로, 즉 들여 쓰기 문자없이 코드를 작성하는 것입니다. 이것을 지원하는 유일한 코드 편집기는 아래 샘플에서 사용되는 것입니다.

가상 서식 을 보여주기 위해 아래 스크린 샷은이 들여 쓰기 방법을 사용하는 XSLT 편집기 *의 것입니다 ( 여기 에는 짧은 비디오도 있음 ). XSLT의 모든 문자는 설명을 위해 내용의 탭 또는 공백 문자 만 선명하게 보이도록 노란색으로 강조 표시되었습니다. 코드 들여 쓰기는 왼쪽 여백 (흰색 배경)을 조정하는 편집기의 렌더링 시스템에서 처리합니다.

Books 줄 앞에는 선행 공백 문자 만 있습니다. 이것은 코드가 아닌 리터럴 텍스트 내용이므로 공백 문자를 유지해야합니다.

가상 형식을 사용하면 소스 파일의 문자에 영향을주지 않으면 서 환경 및 들여 쓰기 스타일에 맞게 들여 쓰기 너비를 선택할 수 있습니다. 아래와 같이 코드를 평평하게 볼 필요가있는 경우 들여 쓰기 너비를 0으로 설정할 수도 있습니다.

이를 공백 문자 형식과 대조하기 위해 가상 형식없이 편집기에서 열린 동일한 XSLT는 해당 편집기의 자동 형식기에 의해 다음과 같이 변환됩니다.

위 스크린 샷에서 더 큰 빈 노란색 블록은 기존 편집기의 포맷터에 의해 추가 된 공백 문자를 명확하게 보여줍니다. 안타깝게도 이제는 실제 컨텐츠와 구별 할 수 없으므로이 문제를 해결하려면 XSLT를 수정해야합니다.

요약

XSLT는 극단적 인 경우 일 수 있지만이 원칙은 많은 프로그래밍 언어에 적용됩니다. 문자는 내용에 사용해야하고 형식화와 관련하여 다른 방법을 찾아야합니다.

** 공개 : 가상 형식의 XSLT 편집기는 내 회사에서 개발했습니다. *

지금까지 언급되지 않음 : 들여 쓰기가 중요한 언어 (Python, Haskell)가 있습니다. 그러나 1 문자는 공백 또는 탭이므로 1 문자로 간주되므로 탭을 사용하는 경우 컴파일러에서 볼 수있는 들여 쓰기가 화면에 표시되는 들여 쓰기와 같지 않을 수 있습니다.

따라서 Haskell과 같은 언어에서는 공백이 필수입니다. Makefile에서 TABS는 필수입니다. 다른 모든면에서 그것은 개인적인 취향의 문제이며 현재는 별다른 문제가 아닙니다. 모든 괜찮은 편집자에게는 "(공백) 탭을 공백으로"및 "(공백) 공백을 탭으로"명령이 있습니다.

나는 공백을 사용했지만 최근에 탭을 사용했습니다. 왜냐하면 Eclipse가 마침내 눈에 띄게 설정 되었기 때문입니다. 우리 팀의 다른 모든 개발자는 Eclipse를 사용하므로 이미 오랫동안 사용하고 있으며 공간으로 변경할 필요가 없다는 것을 알았을 때 탭을 표준화하는 것이 합리적이었습니다. 문제가 아닌 것이 얼마나 놀랐습니다.

IDE에서 표시된 탭 크기를 3 또는 5 자로 설정하면 공백으로 들여 쓰기 된 코드 섹션 (거의 항상 4 일)과 탭으로 들여 쓰기 된 코드 섹션을 쉽게 구별 할 수 있습니다.

이미 많은 논란이 있었지만 앞으로 우리가 어디로 향할 수 있을지는 아무도 언급하지 않았습니다 .

탭이나 공백!

코드는 데이터로 간주하고 특정 텍스트 형식으로 저장해서는 안됩니다. 모든 개발자는 자신이 선호하는보기를 적용 할 수 있습니다. 또한이 뷰 는 text로만 제한되지 않아야 하지만 테이블, 색상 선택기 및 수학 공식을 포함 할 수 있습니다.

이 아이디어는 그리 멀지 않습니다. JetBrain의 언어 지향 프로그래밍 편집기 메타 프로그래밍 시스템 (MPS) 이 처음으로 이것이 전체 토론을 해결하고 동시에 많은 가능성을 추가한다는 것을 깨달았습니다. (그렇습니다. 에디터 플러그인을 사용하면 가능하지만 MPS 방식과 달리 텍스트 작업을 수행하면 불필요한 많은 복잡성이 직접 추가됩니다.)

탭과 공백과 달리 추상 구문 트리 에서 직접 작업 할 때 언급 할 수있는 단점은 거의 없습니다 . 필요한 것은 기술이 상업적으로 실행 가능한 제품으로 발전하기위한 것입니다. 이것의 첫 징후가 나타납니다. 상용 액션 스크립트 편집기 인 MPS를 기반으로 Realaxy 가 개발되었습니다.

저는이 기술의 개념을 뛰어 넘는 큰 선수 중 한 명을보고 어떤 일이 일어나는지보고 싶습니다!

어느 쪽도 좋지 않으며 나쁘지도 않습니다. 유일한 중요한 것은 일관성을 유지하는 것입니다.

당신이 하나의 팀이라면, 당신이 개인적으로 좋아하는 것을 고르십시오. 선호하는 편집기의 기본 동작을 고려하고 원하는 것을 선택하십시오.

팀원 인 경우 팀이하는 일을하십시오. 기간.

다양한 작업에서 두 ​​개의 공백, 네 개의 공백, 여덟 개의 공백, 탭, 공백 및 탭을 사용했는데 한 개의 공간도 사용했다고 생각합니다. 편집자에게해야 할 일을 말한 다음 다시 생각하지 않고 편집자가 세부 사항을 해결합니다.

다른 유일한 방법은 스마트 편집기를 선택하는 것입니다. 이맥스 또는 vi? 이제 그건 내가 :-) 싸울 기꺼이 거룩한 전쟁