IDE에서 고정 폭 글꼴을 사용하는 이유는 무엇입니까? [닫은]

나는 SO에서 몇 가지 글꼴 주제를 보았고 대부분의 사람들이 프로그래밍 작업에 고정 폭 글꼴을 사용하는 것 같습니다. 저는 프로그래밍을 위해 Verdana를 몇 년 동안 사용해 왔으며 고정 폭과 관련된 어떤 것도 놓치지 않고 향상된 가독성을 정말 좋아합니다.

고정 폭 글꼴을 사용하는 이유는 무엇입니까?

고정 폭 글꼴 :

• 길이가 같은 문자열 리터럴은 동일하게 보입니다.
• 다음과 같이가는 구두점을 보는 것이 더 쉽습니다. () {}
• 비슷한 캐릭터가 더 다르게 보입니다 : Il 0O vs Il 0O
• X 자 너비의 창에서 줄 바꿈 여부를 알고 있습니다. 즉, 팀이 100 자 라인으로 표준화 할 수 있으며 라인은 항상 라인처럼 보입니다.

전에 비례 글꼴로 코딩하는 것을 고려한 적이 없습니다. 그래서 과학의 이익을 위해 편집자를 바꾸어 놓았습니다.

다음은 몇 가지 쉬운 티켓을 수정 한 후 몇 가지 관찰 사항입니다.

• 코드가 매우 조밀 해 보입니다. 내 코드의 대부분은 약 80 개 열이며 거의 100 개가 넘지 않습니다. 비례 글꼴은 편집기 왼쪽에있는 작은 줄로 압축합니다. 화면 공간이 짧은 경우 유용 할 수 있지만 불필요하게 압축 된 것 같습니다.
• 코드의 '텍스처'가 손실됩니다. 내가보고있는 구조의 종류를 말하기는 어렵습니다. 거의 문자 단위로 읽어야하는 큰 텍스트 조각 일뿐입니다.
• 그것은이다 매우 미스 쉽게 !연산자를 if (!foo). (만약 (! foo),보십시오!)
• 구두점 문자가 매우 잘못 정의되었습니다. 많은 사람들이 구별하기 어렵다 ( {}[]()vs {} [] ())
• 일부 구두점 문자는 다른 것보다 훨씬 커서 의도하지 않은 부분을 강조합니다 ( $@%$ @ % 대비)
• 일부 문자는 매우 좁고 식별하기 매우 어렵습니다 ( '"!;:,.vs ' "!; :,.)
• 일부 숫자와 문자는 매우 유사합니다 ( 0Oo iIl대 0Oo iIl).
• 나는 구문 강조에 매우 의존하고있다. 따옴표가 균형을 이루는 지 확인하는 것과 같은 일을하는 것은 거의 불가능하다.
• 정렬 (단순 들여 쓰기 제외)이 완전히 깨졌습니다. 여분의 공간을 넣어 날개를 달 수는 있지만 글꼴의 비례 적 특성으로 인해 줄이 정확하게 정렬되지 않을 수 있습니다 . 코드가 더 복잡해 보입니다 .
• 정규 표현식은 .. 흥미 롭습니다!

가 있는 몇 가지 긍정적 인 점은, 그래도. 분명히 나는 ​​잠시 동안 만 사용했지만 비례 글꼴에서 조금 더 잘 작동하는 몇 가지 측면이 있습니다.

• '단어'는 읽기가 더 쉽습니다. 맞춤법 오류 (예 : 변수 철자 오류)가 당신에게 튀어 나옵니다.
• 더 길고 설명적인 변수 이름을 사용하는 것이 더 기분이 좋습니다 (텍스트의 가로 크기가 압축되어 있기 때문일 수 있습니다).
• 이와 같은 코드 를 읽는 것이 약간 더 쉬워 보입니다 . 내 두뇌가 각 단어를 '토큰 화'하고 그 의미를 이해하는 것이 더 쉽습니다. 구두점 문자는 읽기가 더 어렵 기 때문에 여전히 어렵지만 익숙해지기 위해 약간의 시간이 주어지면 변경 될 수 있습니다.

내일 다시이 답변을 업데이트하겠습니다 (이렇게 하루 종일 할 수 있다고 가정합니다!)

관련 조건문을 정렬하여 그룹화되어 있음을 더 명확하게하는 것을 좋아합니다. 예를 들면 :

if ((var1 == FOO) && ((var2 == BAR) ||
                      (var2 == FOOBAR)))

가변 너비 글꼴은 이것을 더 어렵게 만듭니다.

여기에서 계속해서보고있는 것은 "코드 정렬"과 들여 쓰기에 대한 논의입니다. 다음 사항을 지적하고 싶습니다.

• 8 개의 공백은 항상 모든 글꼴에서 4 개의 공백의 두 배입니다.
• 두 탭은 항상 모든 글꼴에서 한 탭의 두 배입니다.
• 한 줄의 식별자는 모든 글꼴에서 항상 다음 줄의 너비가 동일합니다!
• 팀원이 고정 폭을 사용하고 있고 그렇지 않은 경우에는 다르게 보일 것입니다.하지만 무엇이든 표준화해야합니다. 그것이 무엇이든간에, 그것이 사실이라면 모든 사람에게 동일하게 보일 것입니다. .. 모든 글꼴로! 웃음을 위해 모든 사람을 고정 폭으로 유지하고 절반은 와이드 스크린 모니터를 제공 할 수도 있습니다.
• 사용중인 식별자의 범위가 아니라 화면에서 해당 문자의 열 위치를 기반으로 코드를 정렬하는 데 의존하는 작업을 수행하는 경우 수행중인 작업이 해킹이라고 생각합니다. 식별자는 이름의 품질을 희생하여 특정 문자 수로 제한되어서는 안됩니다. 그 외에도 ... 코드의 주석에 별표가있는 ASCII 상자를 아직 그리지 않습니까?

따라서이 모든 것을 함께 그리면 각 줄을 같은 위치에서 시작하고 일관된 간격이 같은 너비이고 식별자가 각 줄의 너비를 자발적으로 변경하지 않으면 코드가 실제로 정렬됩니다! ... 무언가가 다를 때까지.

예를 들면 :

identifier.Method().Property.ToString();
identifier.Method().OtherGuy.ToString(); //how lined up and pretty!
identifier.Method().Sumthing.YouGetThePoint;

• identifier.Method (). Property.ToString ();
• identifier.Method (). OtherGuy.ToString (); // 오 안돼! 어긋난!
• identifier.Method (). Sumthing.YouGetThePoint; // ...하지만 누가 신경 쓰나요? 그들은 다른 속성입니다!

제가 인정할 점은 영숫자가 아닌 문자는 일반적으로 그다지 넓지 않다는 것입니다. 여기에는) (] [} {,: | "; ',`! 및이 포함됩니다. 그러나 이것은 글꼴 편집기에서 간단히 수정할 수 있습니다. 단순히 글꼴을 더 넓게 만들어 문제를 해결할 수 있습니다. 수요가 많지 않아서 아직 완료되지 않았습니다.

요약하면 개인적 선호도는 괜찮지 만, 비단 일 공간보다 모노 스페이스를 선호하는 실질적인 이유는 거의 없다고 생각합니다. 당신은 그것의 모습을 좋아합니까? 물론 고정 폭을 사용하십시오. 화면에 더 많은 항목을 표시 하시겠습니까? 모노가 아닙니다. 그러나 사람들이 비단 일 공간을 이단처럼 취급하는 방식은 약간 과장되어 있습니다.

고정 폭 글꼴에 대한 많은 주장이 약간의 조정으로 쉽게 반박 될 수 있기 때문에이 스레드에 대해 궁금해졌습니다. 그래서 저는 IDE를 Calibri로 바꿨습니다 (왜냐하면 그것은 멋지고 둥근 얼굴을 가지고 있고 UI 화면에서 가독성에 최적화 되었기 때문입니다 – 완벽합니다). 이제 분명히 들여 쓰기를 위해 공백 대신 탭을 사용해야하고 (모든 문제를 무시하고) 4 개의 공백 너비는 분명히 충분하지 않아서 10으로 전환했습니다.

이제 꽤 좋아 보인다. 그러나 내가 발견 할 수있는 몇 가지 명백한 문제가 있습니다. 이 설정을 잠시 테스트 한 후 나중에 더 많이 나타날 수 있습니다.

• 이미 언급했듯이 일부 문자 (특히 괄호, 세미콜론)는 너무 얇아 보입니다. 나는 이것을 연속적인 텍스트로 원하지만 소스 코드에서는 원하지 않습니다. 이것이 가장 큰 문제라고 생각합니다.

• 기호가 잘 정렬되지 않습니다. 예를 들어 다음 C # 코드를 고려하십시오.

  var expr = x => x + 1;
  

  화살표 ( =>)는 고정 폭 글꼴에 대한 단위처럼 보입니다. 다른 글꼴에서는 두 개의 인접한 문자처럼 보입니다. >>등의 연산자도 마찬가지입니다 .

• 공간이 작게 보입니다. 가독성을 높이기 위해 소스 코드 간격을 정교하게 배치합니다. 이것은 비례 글꼴로 전환 할 때 소용이 없습니다. 공간의 너비를 제어 할 수 있다면 확실히 도움이 될 것입니다.

• 상황에 맞는 들여 쓰기가 완전히 깨졌습니다. 일부 상황에서는 고정 된 수의 탭을 들여 쓰기하는 것으로 충분하지 않습니다. 다음과 같은 방식으로 들여 쓰기 될 수있는 LINQ 식을 사용합니다.

  var r = from c in "This, apparently, is a test!"
          where !char.IsPunctuation(c)
          select char.ToUpper(c);
  

  비례 글꼴로는이 작업을 수행 할 수 없습니다.

대체로 문자가 너무 좁습니다. 다시 말하지만 추가 문자 간격이 도움이 될 수 있으며 구두점의 경우 반드시 필요합니다. 그러나 비례 글꼴을 더 읽기 쉽게 만들기위한이 모든 조정은 고정 폭 글꼴을 자연스럽게 모방하는 것입니다. 지금까지 언급 된 모든 요점에 대해 확실히 사실입니다.

저는 Comic Sans MS를 사용하는데, 이것은 작은 포인트 크기로 상당히 합리적으로 보입니다 (헤드 라인 크기에서 "조키"로 보이기 시작합니다). 보기에는 쉽지만 VS의 도킹 된 여러 패널이 열려있는 상태에서 텍스트 창에 적절한 양의 코드를 표시 할 수있을만큼 텍스트를 작게 유지합니다.

솔루션 탐색기 패널을 꺼도 수평 스크롤 없이도 100 개의 텍스트 열을 읽을 수 있습니다. 이동하면 DXCore Documentor 패널 (형식화 된 XMLDOC 표시)을 읽을 수있을만큼 넓게 열면서도 XMLdocs를 문서화하기에 충분한 텍스트를 볼 수 있습니다.

팀에서 작업하는 경우 고정 폭 글꼴은 사용하는 고정 폭 글꼴에 관계없이 모든 사람에게 코드가 명확하고 올바르게 배치되도록합니다.

가변 너비 글꼴을 사용하면 코드가 명확 해 보일 수 있지만 고정 폭 글꼴 사용자가 열면 동일하게 보이지 않을 수 있습니다.

Monospace 글꼴을 사용해야한다는 사실을 깨닫기 위해 리터럴에 1이 아닌 2 개의 공백이 있기 때문에 검색에서 무언가를 찾지 못하는 이유를 파악하는 데 몇 시간 만 걸립니다. 디자이너가 고정 폭 글꼴을 사용하지 않을 때 Lotus Notes 에이전트를 수정하려고 할 때 이런 일이 한 번 발생했습니다. 코드를 CodeWright에 붙여 넣기 전에는 문제가 무엇인지 분명히 알 수있었습니다.

고정 폭 글꼴을 사용하면 코드를 훨씬 쉽게 정렬 할 수 있습니다.

팀과 함께 작업 할 때 특히 그렇습니다. 팀의 모든 구성원은 서로 다른 글꼴을 사용할 수 있으며 모두 고정 폭인 한 모든 것이 정렬됩니다. 마찬가지로 한 사람이 다양한 개발 도구를 사용하는 경우 모두 고정 폭이면 모든 것이 정렬됩니다. 모두 고정 폭이 아니라면 모두 동일한 글꼴을 사용하는지 확인해야하며 두 플랫폼에서 개발하는 경우 어려울 수 있습니다.

실제로 일부 개발 도구는 고정 폭 글꼴 만 지원합니다.

또 다른 이유는 고정 폭 글꼴이 더 뚜렷한 문자를 갖는 경향이 있기 때문입니다. lIiO0를으로 비교 lIiO0하면 무슨 뜻인지 알 수 있습니다. 또한 공백을 훨씬 쉽게 계산할 수 있습니다.

고정 폭 글꼴이 텍스트 기반 DOS 시대의 이월로 프로그래머의 선호 사항이라고 생각합니다.

반면에 저 자신은 Verdana와 몇 가지 다른 권장 비례 글꼴을 사용해 보았지만 변경 사항을 처리 할 수 ​​없었습니다. 내 눈은 고정 폭에 대해 너무 잘 훈련되었습니다. C / C ++, C #, Perl 등과 같이 기호가 많은 언어는 나에게 너무 다르게 보입니다. 기호를 배치하면 코드가 완전히 다르게 보입니다.

일반 언어가 아닌 코드의 특성상 올바르게 정렬하는 것이 더 좋습니다. 또한 코드 편집에서 선택, 복사 및 붙여 넣기를 차단하고 싶을 때가 있습니다. Visual Studio에서는 마우스 선택을하는 동안 Alt 키를 사용하여 블록 선택을 수행 할 수 있습니다. 편집기마다 다를 수 있지만, 어떤 경우에는 편집기의 옵션이 매우 중요하다는 것을 항상 발견했으며 고정 폭 글꼴을 사용하지 않는 한 잘 작동하지 않을 것입니다.

개인적으로 고정 폭 글꼴은 코드 편집기에서 읽기가 더 쉽습니다. 물론 저는 거의 장님입니다. 그것은 차이를 만들 수 있습니다. 저는 현재 고 대비 문자로 어두운 배경에 15 포인트에서 consolas 글꼴을 실행합니다.

들여 쓰기를 위해 공백을 사용하는 것은 한 단계보다 깊어지면 문제가 될 것입니다.

대부분 정렬 목적 (예 : 함수 매개 변수 선언이 여러 행에 걸쳐 있고이를 정렬하거나 주석을 정렬하려는 경우).

탭 문자 문제와 마찬가지로 복잡한 요소는 정렬을 위해 무언가를 들여 쓰고 다른 사람이 다른 선호도를 갖는 경우입니다. 일이 잘못 정렬됩니다.