Definitelytyped: 탭 대 공백?

전투가 없습니다. 탭을 사용합니다.

나는 빈칸에 투표한다!

내부 갈등을 시작하자! :웃다:

ㅋ. 우리는 그것을 필요로하지 않습니다. 하지만 알다시피... 우리가 탭을 사용하고 모든 개발자가 원하는 방식(2칸 또는 4칸)으로 완벽하게 정렬된 코드를 갖고 있다면 우리는 이 대화를 하지 않을 것입니다. 그냥.

나는 탭을 좋아한다.
하지만 VisualStudio의 기본 설정을 따라야 한다고 생각합니다.

들여쓰기 크기가 4인 공백(VS 기본값).
귀하와 모두가 만족할 수 있도록 가상 탭을 수행하도록 IDE를 설정하십시오.
위 줄의 단어와 정렬하려는 코드에 대해 [탭] [탭] [공백] [공백] [공백]을 보고 싶지 않습니다.

일관된 스타일을 적용하기 위해 TSLint 규칙을 작성하고 싶은 사람이 있으면(예: 탭 또는 공백 4개, 둘 다 아님) 새 테스터에서 실행합니다(TSLint 지원 있음).

https://github.com/palantir/tslint/issues/122 도

스페이스! FWIW JS 라이브러리는 공백을 사용합니다(각도/jquery)

이것은 아마도 Crockford 때문일 것입니다 : http://javascript.crockford.com/code.html

들여쓰기의 단위는 4칸입니다. (21세기에 이 글을 쓰는 현재) 여전히 탭 스톱 배치에 대한 표준이 없기 때문에 탭 사용을 피해야 합니다. 공백을 사용하면 더 큰 파일 크기를 생성할 수 있지만 크기는 로컬 네트워크에서 중요하지 않으며 그 차이는 축소를 통해 제거됩니다.

TS는 JS이기 때문에 정말 준수해야 합니다.

글쎄, Crockford는 약간 심술 궂은 늙은이이므로 그를 소금 한 알과 함께 데려갑니다.

얼마 전 Reddit에 누군가가 Github의 상당한 덩어리를 분석한 통계가 있었는데 공백에 찬성하여 60% / 40%였습니다. 저와 제가 지금까지 일했던 모든 곳은 탭이었습니다(그 중 큰 부분은 AS3이었지만). 그것은 완전히 잘 작동합니다. 코드 정렬은 시간 낭비이지만 필요한 경우 스마트 탭도 잘 작동합니다.

내가 없애고 싶은 진짜 골칫거리는 _indents_ 혼합되어 있습니다. 전체 리포지토리에 대해 열핵을 사용하기 전에 적어도 _파일당_ 일관성이 있어야 합니다.

어느 시점에서 우리는 #2228을 할 것이지만 그것은 꽤 큰 단계입니다.

글쎄, Crockford는 약간 심술 궂은 늙은이이므로 그를 소금 한 알과 함께 데려갑니다.

동의

지루하다면 JSON.js에 대한 pull 요청을 읽는 것이 좋습니다. 변함없이 그들은 Doug의 약간 조잡한 방식을 모르는 사람들에 의해 제출되었습니다. 모두 거부된 공백입니다 :-)

방금 이것을 보았습니다 : https://github.com/iplabs/typescript/blob/languageService-v2/src/services/languageService.ts#L199 -L213 기본값은 탭이 공백으로 변환된 4개의 공백입니다.

    export class EditorOptions {
        public IndentSize: number = 4;
        public TabSize: number = 4;
        public NewLineCharacter: string = "\r\n";
        public ConvertTabsToSpaces: boolean = true;

        public static clone(objectToClone: EditorOptions): EditorOptions {
            var editorOptions = new EditorOptions();
            editorOptions.IndentSize = objectToClone.IndentSize;
            editorOptions.TabSize = objectToClone.TabSize;
            editorOptions.NewLineCharacter = objectToClone.NewLineCharacter;
            editorOptions.ConvertTabsToSpaces = objectToClone.ConvertTabsToSpaces;
            return editorOptions;
        }
    }

@basarat 얼마나 만족스럽습니까!

CRLF는 약간 바보 같지만 어쨌든.

어쩌면 우리는 그것을 위해 가야합니다. 모든 것에 typescript-formatter를 실행하고 어떤 일이 일어나는지 살펴보겠습니다.

주인님, 도살장이라니.. 총 .d.ts 파일 562개, 파일 446개가 변경되었습니다..

https://github.com/Bartvds/DefinitelyTyped/tree/34907936bfc22562f30bb09ee82282ca0515b8b3

https://github.com/Bartvds/DefinitelyTyped/commit/34907936bfc22562f30bb09ee82282ca0515b8b3

죄송합니다. 너무 많은 파일(446개)이 변경되어 전체 diff를 표시할 수 없습니다.

헤.

테스트도 수행했습니다.

https://github.com/Bartvds/DefinitelyTyped/tree/46f9d17b2b074c887bff35b06112070b28924248

https://github.com/Bartvds/DefinitelyTyped/commit/46f9d17b2b074c887bff35b06112070b28924248

죄송합니다. 너무 많은 파일(442개)이 변경되어 전체 diff를 표시할 수 없습니다.

멋진. 그래서 우리는 기술을 가지고 있습니다. 그것은 쉬운 부분이었습니다. 그러나 이제 이것이 우리가 원하는 것인지 결정해야 합니다. 왜냐하면 그것이 심각한 영향을 미칠 것이기 때문입니다.

한 줄 속성은 지옥에 가고 있습니다. 그리고 우리가 그것을 받아들인다면 아마도 테스터에서 형식을 적용해야 할 것입니다. 테스터에 TSLint 설정이 있으므로(비활성화됨) 많은 작업을 수행할 수 있습니다.

아마도 우리는 테스터를 훌륭하게 사용할 수 있는 방식으로 포맷터를 실행하고 테스트를 실행할 수 있는 CLI 유틸리티로 개선해야 합니다(지금은 로컬에서 작동하지만 깨끗한 CLI API 등으로 개선되어야 함).

빠를수록 좋다고 합니다. 그러나 좋은 소식은 비난의 역사를 잃지 않을 것 입니다. GitHub가 diff 보기에서도 이 기능을 구현했으면 했습니다.

예, 하지만 git blame -w -M 가 온라인에서 작동하지 않는다는 것은 짜증나는 일입니다. 방금 Github 지원팀에 이메일을 보냈습니다.

@Bartvds , GitHub에서 응답이

GitHub 비난 보기에서 공백을 무시하는 것은 현재 불가능하지만 나중에 추가할 수 있습니다. 제안해 주셔서 감사합니다. 팀에서 볼 수 있도록 기능 요청 목록에 추가하겠습니다.

따라서 시간이 걸릴 수 있습니다.

나는 모든 것을 알고 있다고 가정하는 스타일 가이드가 뭐라고 말하든 상관하지 않습니다. 들여쓰기를 위한 탭은 정렬이 포함될 때 개발자의 의도를 보존하는 유일한 방법입니다. 그것에 대한 내 블로그 게시물을 참조하십시오.

코드 정렬(귀하의 경우 var 및 = 에 정렬) 개념이 좋습니다. 그러나 리팩토링에서 유지하기가 어렵습니다. 그래서 그냥 사용하지 않습니다. 또한 자동 서식 도구는

또한

  public string FirstName { get; set; }        =>  public  string  FirstName { get; set; }    
  public string Surname { get; set; }          =>  public  string  Surname   { get; set; }
  public int Age { get; private set; }         =>  public  int     Age       { get; private set; }
  private Address Address { get;  set; }       =>  private Address Address   { get; set; } 

새 속성을 추가하면 이 모든 줄을 _reformat_해야 합니다. 검토하기에 좋은 코드 변경이 아닙니다.

워크플로가 다를 수 있으며 이를 허용할 수 있습니다. 그것은 훨씬 더 읽기 쉽게 만들지만(아트로서의 코드), 나는 그것을 옮기는 팀을 경험해 보지 못했습니다.

가장 이상한 일입니다. 탭과 공백을 섞는 아이디어에 대한 나의 본능적인 반응은 몸을 떨며 "그냥 더럽다!"라고 생각하는 것입니다.

나는 완전히 비합리적이라는 것을 압니다. 그러나 전적으로 진지합니다. 인간이 이상해...

@johnnyreilly 당신은 일반적인 오해의 희생자입니다. 들여쓰기에 탭을 사용하고 정렬에 공백을 사용하는 것은 공백이 있는 탭을 _혼합_하는 것과 다릅니다. 당신은 분명히 블로그 게시물을 읽지 않았습니다.

정렬을 위해 탭을 사용하는 것은 사람들이 잘못하고 있었기 때문에 탭에서 너무 많은 사람들이 전혀 꺼진 이유입니다. 처음부터 제대로 했다면 아무도 탭 너비를 다른 크기로 표시하도록 편집자의 기본 설정을 변경했을 때 눈치채지 못했을 것입니다. 이것은 위의 애니메이션 GIF가 사람들이 어떻게 잘못하고 있는지 보여주려는 것입니다.

@basarat , 전적으로 동의합니다. 코드 정렬이 있는 프로젝트에서는 거의 작업하지 않지만 가끔 봅니다. 프로젝트의 개발자가 정렬을 전혀 사용하지 않도록 강제할 수 있다면 그렇게 하라고 말하고 싶습니다. 그렇지 않으면 들여쓰기를 위한 공백이 있는 린트 도구가 코드를 CST로 구문 분석하는 것 외에는 들여쓰기와 정렬을 위해 의도된 것을 구별할 수 있는 방법이 없습니다(과도한 방법).

물론, 이 현대 시대에 들여쓰기에 공백을 사용하지 않는 다른 많은 이유가 있습니다. 편집자는 탭을 잘 다루지만 공백은 전혀 다루지 않습니다. 화살표 키 탐색, 삭제, 백스페이스 - 공백의 들여쓰기를 하나의 단위로 취급하지 않습니다. Visual Studio, Sublime, PHPStorm 및 Notepad++를 사용해 보았지만 모두 들여쓰기 공백에 대한 근본적인 문제가 있습니다.

화살표 키 탐색, 삭제, 백스페이스 - 공백의 들여쓰기를 하나의 단위로 취급하지 않습니다.

탐색: Ctrl + 화살표 키를 사용합니다. 공백(실제로는 모두 공백) + 단어를 홉핑합니다.

삭제/백스페이스의 경우: 단어 선택의 경우 단어 확장(reshaper 기본값에서 ctrl+w)과 선택 해제(ctrl+shift+w)를 사용합니다. _inside_ 공백을 선택해야 하는 경우는 거의 없지만 탭(들여쓰기 증가)과 탭 이동(들여쓰기 감소)을 사용하면 됩니다.

@jedmao 사실 나는 당신의 요점을 이해했습니다. 나는 본능적인(그리고 비이성적인) 반응을 공유하고 있었습니다. 나는 그것이 의미가 있다고 말하지 않았다 : 스마일 :

@johnnyreilly 잡았다.

@basarat 일부 공백 시나리오에서 Home 및 End 키를 사용합니다. Ctrl + arrow key 탐색을 사용하려고 시도했지만 항상 작동하지 않습니다. 이것이 내가 정신적인 일관성 때문에 거의 사용하지 않는 이유입니다. 다음 예를 고려하십시오.

for (var i = 0; i < 10; i++) {
    if (i > 5) {
        console.log('I am greater than 5');
    }
}

내 커서가 3행의 시작 부분에 있고 2행의 시작 부분까지 탐색하고 싶다고 가정해 보겠습니다.

Sublime에서 귀하의 기술을 사용하여 두 가지 방법 중 하나로 할 수 있습니다.

• Up , Hold Ctrl , Left , Release Ctrl (4 논리적 단계)
• Hold Ctrl , Left , Release Ctrl , Up , Hold Ctrl , Right , Left , Release Ctrl (8 논리적 단계)

Visual Studio에서 두 번째 시나리오는 7개의 논리적 단계로 줄일 수 있습니다.

• Hold Ctrl , Left , Release Ctrl , Up , Hold Ctrl , Right , Release Ctrl (7 논리적 단계)

실제 탭 문자의 경우 최단 경로는 수정자 키가 없는 단 2개의 논리적 단계입니다. 더 간단할 수 없습니다.

• Left , Up

단어 선택이 공백 들여쓰기를 삭제하거나 백스페이스하는 데 어떻게 도움이 되는지 알 수 없습니다. 나는 성공하지 않고 Visual Studio에서 그것을 시도하고 있습니다. 이것이 내가 Visual Studio용 TabSanity 플러그인을 만든 이유입니다. 불행히도, 다른 편집자들을 위한 그러한 플러그인은 알지 못합니다.

실제 탭 문자의 경우 수정자 키가 없는 항상 2개의 논리적 단계입니다. 더 간단할 수 없다

:+1: 당신의 장점이 보입니다. 그러나이 주석을 편집하면 ctrl 등이 내 VS와 동일하게 작동하므로 내 습관이 이어집니다.)

단어 선택이 공백 들여쓰기를 삭제하거나 백스페이스하는 데 어떻게 도움이 되는지 알 수 없습니다.

내 나쁜, 내 설명이 혼란 스러웠습니다. "단어" 선택 비트를 무시하십시오. I rarely need to select inside whitespace though, just use tab (increase indent) and shift tab (decrease indent). 에 집중하세요. 간격 들여쓰기가 잘 작동합니다.

실제 탭 문자의 경우 수정자 키가 없는 항상 2개의 논리적 단계입니다.

이건 어떤가요 :

public  string  FirstName { get; set; }    
public  string  Surname   { get; set; }
public  int     Age       { get; private set; }
private Address Address   { get; set; } 

의 처음부터하지 않을 것입니다 Age 의 유형 변화에 Surname IE의 string 이전 라인에이 같은 일 Ctrl 시나리오?

@basarat 저는 Tab 와 Shift+Tab 종교적으로 사용합니다. 그러나 일반적으로 여러 줄의 코드에 사용됩니다. Shift+Tab 탭의 backspace 키 누름에 대한 좋은 별칭이라고 말할 수 있지만 backspace 만큼 간단하거나 직관적이지 않습니다.

Ctrl+Delete 는 Delete 키에 가장 가까운 별칭이지만 둘 이상의 들여쓰기를 삭제할 가능성이 있습니다. 반면에 탭의 간단한 Delete 키는 들여쓰기를 하나만 제거합니다. 때때로 일하고 다른 사람들은 일하지 않기 때문에 전혀 사용하지 않습니다(정신적 일관성).

나도 당신과 마찬가지로 내부 공백을 선택해야 하는 경우는 거의 없습니다. 하겠다고 제안한 적이 없습니다. 나는 공백을 선택하지 않고 어딘가로 이동하기 위해 그것을 탐색합니다. 위의 정렬 예는 확실히 Ctrl + arrow key 탐색을 사용할 때입니다. 이것이 내가 이전에 말했듯이 Ctrl + arrow key 탐색을 거의 사용하지 않는 이유입니다. 왜냐하면 당신이 지적한 시나리오가 아마도 제가 사용할 유일한 경우이기 때문입니다.

결국, 나를 가장 괴롭히는 것은 들여쓰기를 위한 탭이 있는 파일과 들여쓰기를 위한 공백 사이를 전환할 때 근육 메모리를 완전히 변경해야 한다는 것입니다. 들여쓰기를 위한 탭이 있는 파일에서 효율적인(가장 적은 논리적 단계) 들여쓰기를 위한 공백이 있는 파일에서는 작동하지 않습니다. 원활한 경험을 제공하지 않는 편집자를 비난할 수 있지만, 편집자가 들여쓰기와 정렬에 대해 들여쓰기를 위한 공백이 있는 파일에서 가정을 하는 것은 문자 그대로(CST 없이) 불가능하기 때문에 공정하지 않습니다.

더욱 안타까운 것은 사람들이 그것을 알아차리기 어렵다는 점이다. 들여쓰기를 위한 공간은 순수한 악입니다... 뿔이 있습니다.

최종 결론은? 나는 단지 기여하고 싶습니다, 당신은 도대체 무엇을 사용하고 있습니까?

최종 결론은? 나는 단지 기여하고 싶습니다, 당신은 무엇을 사용하는

파일별로 일관성이 있습니다. 파일에 혼합하지 마십시오.

@basarat 만화가 잘못되었습니다. 우리 모두는 Apple 직원이 공백을 사용하고 Microsoft 직원이 탭을 사용한다는 것을 알고 있습니다.

@jedmao 저는 ms 사람이고 공백을 사용합니다 :)

나는 #4211이 좋은 제안이라고 생각한다.

airbnb /javascript styleguide에서 수행한 대로 2개의 공백을 사용할 것을 제안합니다.

제안: 입력 중인 라이브러리에서 설정한 코딩 표준을 사용하십시오. 입력되는 라이브러리가 공백, 작은따옴표 및 LF를 사용하는 경우 유형 정의에서 동일한 작업을 수행합니다. 이렇게 하면 공백 대 탭 인수를 피할 수 있습니다.

유일한 문제는 이 규칙을 적용하기가 쉽지 않다는 것입니다. 이를 시행하고 일관성을 유지해야 하는 경우 가장 인기 있는 규칙을 사용하는 것이 좋습니다. 이 웹 사이트에 따르면 공백과 작은 따옴표입니다.

개인적으로 선호하는 것은 공백(4)과 _큰 따옴표이지만 모든 것이 일관성이 있다는 의미라면 작은 따옴표를 사용해도 괜찮습니다.

탭을 찬성하는 사용자와 탭 공간을 선호하는 사용자가 비슷한 타협을 받아들일 수 있습니까?

제 개인적인 취향은 공백(4)과 큰따옴표이지만 모든 것이 일관성이 있다는 의미라면 작은따옴표를 사용해도 괜찮습니다.

@glen-84는 순전히 당신의 즐거움을 위한 것입니다 ... 컴파일러 팀이 큰따옴표를 사용한 이유는 다음과 같습니다. https://github.com/Microsoft/TypeScript/issues/5811#issuecomment -160187924

• JSON
• 모든 언어에서 작동하므로 인지 부하가 ​​적습니다.

나는 점점 더 많은 TypeScript를 독점적으로 수행하는 자신을 발견함에 따라 개인적으로 작은 따옴표를 사용합니다.

저도 좀 가독성이 좋은 것 같은데, 57% vs 43%(큰 차이는 아님)였는데, 어딘가에 선을 그어야 할 것 같습니다. =)

나는 들여쓰기를 위한 탭과 정렬을 위한 공백에 대한 @jedmao 의 포인트를 좋아합니다.

전체 공개: 저는 go fmt 있고 탭이나 공백에 대해 논의한 적이 없는 Go-land에서 왔습니다. 들여쓰기를 위한 탭과 정렬을 위한 공백이며 매우 잘 작동합니다.+1:

물론 공간. 탭이 다른 곳에서 사용되는 경우 다른 편집기에서 탭이 정확히 어떻게 렌더링되는지 아무도 모르기 때문입니다.

@hinell 다른 편집기에서 탭이 다르게 렌더링되는 것이 중요한 이유는 무엇입니까? 탭이 들여쓰기에 "전용" 사용되는 한 그렇지 않습니다.

나는 특히 이것 때문에 탭을 선호합니다: http://nickgravgaard.com/elastic-tabstops/

탭을 사용해야 하는 더 큰 이유가 있습니다. 바로 개발자 접근성 입니다.

• https://github.com/prettier/prettier/issues/7475
• https://www.reddit.com/r/javascript/comments/c8drjo/nobody_talks_about_the_real_reason_to_use_tabs/