공백 뒤에 왜 큰 문제가 발생합니까? [닫은]

후행 공백은 Emacs와 같은 편집기가 강조 표시하거나 자동으로 제거하는 특수 기능을 가지고 있으며 많은 코딩 표준에서 모든 인스턴스를 제거해야하는 프로그래머에게는 문제가됩니다. 나는 왜 그런지 완전히 확신하지 못한다. 불필요한 공백을 피하는 한 가지 실질적인 이유를 생각할 수 있습니다. 사람이 피하지 않도록주의하지 않으면 커밋 사이에서 변경 될 수 있으며 누군가가 제거되었거나 공간을 추가했습니다.

이것은 이미 피해야 할 꽤 좋은 이유처럼 들리지만 그보다 더 많은 것이 있는지 알고 싶습니다. 그렇다면 왜 공백 뒤에 오는 것이 그렇게 큰 문제입니까?

나에게 중요한 이유 :

• "End"키를 누르면 커서가 줄 끝으로 이동하고 (사용중인 편집기 및 구성 방법에 따라) 입력을 즉시 시작할 수있을 것으로 기대합니다. 커서가 도착하고 3 ~ 4자를 삭제해야한다면 성가신 일입니다. 특히 파일 전체에서 일관성이없는 경우.

• 여러 줄에 걸쳐있는 문자열 리터럴이 있으면 후행 공백으로 인해 출력 문자열이 잘못 사용될 수 있습니다.

엄격하게 프로그래밍하는 것은 아니지만 파일에서 구문 분석되고 다른 항목의 입력으로 사용될 파일에 후행 / 선행이 있으면 공백은 데이터 입력을 심각하게 망칠 수 있습니다. 이것은 누군가가 Excel에서 파일을 편집하거나 공백 문자 및 기타 형식 문제가 발생하여 깨끗하고 생성 된 입력 파일이 더러워지면 가장 많이 발생합니다.

나는 공백 문자를 싫어하지만 정확한 이유는 약간 모호합니다.

그 느낌의 기원은 프로그래밍이 아니라 데스크탑 출판 분야에 있다고 생각합니다. 출판물에 조판해야하는 다른 사람이 입력 한 문서를받은 적이 있습니까? 모든 현대 간행물에서, 특히 열을 사용할 때 각 문장마다 새로운 줄을 시작하지 않고 문장이 한 단락 내에서 순차적으로 서로 뒤 따르도록하는 것이 일반적입니다. 글쎄, 후행 공백이있을 때 올바르게 처리하려면 많은 노력이 필요합니다 (더블 스페이스 등을 제거하는 많은 검색 및 대체 작업 등).

다른 이유 (프로그래밍에서), 좋은 이유는 아니지만, 나는 그들이 잠재 의식을 제거하기 위해 강렬한 방식으로 내 잠재 의식을 귀찮게합니다.

• 필요한 것보다 더 많은 저장 공간이 필요합니다
• 파서는 컴파일 할 때 아무런 이유없이 추가 문자를 건너 뛰어야합니다.
• WordWrap이 켜져 있고 후행 공백이 맞지 않으면 일부 편집자가 빈 줄을 추가 할 수 있습니다.

예, 알아요! 나는 이것이 정크 이유라는 것을 안다. 나는 완벽 주의자가 아니지만 ... 어쩌면 내가 있을까요?

내가 생각할 수있는 마지막 이유는 커서 움직임이 일치하지 않기 때문입니다. 커서가 줄 끝에서 얇은 공기에 매달려있는 것처럼 느껴집니다. 오른쪽 단계마다 커서가 떨어지거나 알 수없는 정도로 멀리 떨어질 수 있습니다. 수퍼가 보이지 않거나 사라지는 블록처럼 마리오는 계속 뛰어 다녔다).

아마도 트레일 스페이스 포비아로 진단받을 수 있습니까?

이 답변의 대부분 은 나에게 나쁜 이유에 거의 영향을 미치지 만 기본적으로 텍스트 편집기를 "중단"합니다. 내 경험은 vim입니다.

Vim은 일반적인 동작이 문자에 깔끔하게 매핑되도록 설계되어 어떤 문자 나 키 조합을 칠 것인지조차 생각할 필요가 없습니다. 다양한 단축키를 사용하면 커서가 텍스트를 빠르게 이동할 수 있으므로 원하는 위치로 몇 번의 키 입력만으로 충분합니다. END 또는 $를 눌러 줄의 끝으로 이동할 수 있으므로 커서가 {또는} 또는 (또는) 또는 무언가 겹치게 될 수 있으므로 코드 흐름을 접는 것과 같은 것조차 빠릅니다. 화면에 아이디어를 얻으십시오.

그러나 후행 공백이 생겨 커서의 움직임을 더 이상 예측할 수 없습니다. 보이지 않는 것이 커서의 위치에 영향을 미치기 때문에 입력 과정이 중단되고 있으므로 원하는 위치로 보내려면 생각의 기차를 끊어야합니다.

작업에 집중할 때 성가신 사람들이 어떻게 방해를 받는지 알고 누군가가 방해 하는가? 예, 예상치 못한 공백을 찾는 것은 정확히 같습니다.

_{참고로, 후행 공백을 신경 쓰지 않는 사람들은 탐색을 위해 마우스를 사용하는 사람들이며, 그로 인해 타이 포스트가 느리다는 경향이 있습니다 ...}

놀랍게도, 가장 명확한 대답은 빠졌습니다. 후행 공백은 버그를 찾기 어렵고 생성 할 수 있습니다.

가장 확실한 상황은 여러 줄 문자열입니다. Python, JavaScript 및 Bash는 이에 영향을받을 수있는 언어의 몇 가지 예입니다.

print("Hello\·
····World")

생산 :

  File "demo.py", line 1
    print("Hello\
                 ^
SyntaxError: EOL while scanning string literal

편집기가 공백 문자를 표시하도록 구성되어 있지 않으면 어쨌든 비밀스럽고 해결하기가 어렵습니다.

구문 강조는 이러한 경우를 피하는 데 도움이 될 수 있지만 줄 끝에 공백을 두지 않으면 서 처음에는 문제가 발생하지 않는 것이 더 쉽습니다. 이런 이유로 일부 스타일 체커는 후행 공백이 발생할 때 경고를 발생시키고 일부 편집기는 자동으로 트리밍합니다.

^{그림 : 구문 강조는 버그로 이어질 수있는 상황에서 후행 공백을 피하는 데 도움이되지만 그에 의존하지는 않습니다.}

이전 답변 에서 간단히 언급 한 또 다른 컨텍스트 는 파일에 저장된 데이터입니다.

예를 들어, 후행 공백이 포함 된 CSV 파일은 데이터 불일치를 유발할 수 있으며 이로 인해 탐지하기가 매우 어렵습니다. 표준 호환 파서는 공백을 자릅니다 (표준은 큰 따옴표로 묶지 않는 한 선행 또는 후행 공백은 관련이 없음을 나타냅니다). 일부 파서는 잘못 동작하여 공백을 값의 일부로 유지할 수 있습니다.

다른 사용자 정의 형식은 공백이 값의 일부라고 구체적으로 고려할 수 있으므로 일관성은 있지만 상황을 디버그하기는 여전히 어렵습니다.

최근에 데이터에서 예기치 않은 후행 공백으로 판명 된 버그를 찾는 데 하루를 보냈습니다.

복사 및 붙여 넣기 위해 프로그램 소스 코드를 선택하면 (또는 삭제) 줄 끝에서 불규칙한 여분의 공백을 모두 보는 것이 약간 성가시다. 선택하는 동안 코드를 읽어야하기 때문에 후행 공백은 불필요한 노이즈입니다. 예 (점은 공백을 나타냄) :

if (fp)........
{....
    fclose(fp);.
}
else
{.....
    prinft("File is NULL\n");
}..

이 예제는 인위적이지만 다음과 같은 많은 코드를 보았습니다.

어떤 경우에는 파싱이 깨지는 명백한 문제 외에도? 다른 포스터에서 언급했듯이 미묘하고 오류를 추적하기가 어려울 수 있습니다. 공백이 항상 중요하지는 않습니다. 경우에 따라 후행 공백은 코드 또는 데이터 라인의 의미를 크게 변경할 수 있습니다.

대부분의 경우 공백은 사람이 읽을 수 있도록 코드 형식을 지정합니다. 후행 공백은 다음을 포함하여 여러 가지를 나타낼 수 있습니다.

• 불완전한 진술;
• 누락 된 설명;
• 잘못된 편집; 또는
• 조잡한 편집.

이 중 두 가지가 잘못된 기능을 유발할 수 있고 다른 하나는 코드를 이해하기가 더 어려울 수 있습니다.

엔드 라인 공백에 민감한 프로그래밍 언어가 있습니다. 예를 들어, 줄 끝에 공백이 있으면 TCL 스크립트에서 오류가 발생합니다.