와이드 스크린 모니터의 경우 80 자 제한이 여전히 관련이 있습니까? [닫은]


56

와이드 스크린 모니터에서는 스크롤 막대없이 한 번에 80 자 이상을 쉽게 볼 수 있습니다. linus torvalds조차도 80 자 제한은 구식 으로 간주 합니다.

그렇다면 80 자 제한은 여전히 ​​와이드 스크린 모니터와 관련이 있습니까?


1
예를 들어 Eclipse와 같이 줄을 짧게 유지해야하는 매우 좋은 이유가 있습니다. 이렇게하면 줄 바꿈없이 일반 프린터에서 읽을 수있는 글꼴로 프로그램 을 인쇄 할 수 있습니다 .

어떤 맥락에서? 특정 프로그래밍 컨텍스트에서 요청하는 경우 다시 열어야합니다.
Nicole


Visual Studio의 줄 바꿈이 깨져서 대부분의 사용자가 사용하지 않습니다. 대신 손으로 줄 바꿈을합니다. 화면 너비가 다른 사람에게는 끔찍해 보입니다. visualstudio.uservoice.com/forums/121579-visual-studio/…
Panic 대령

답변:


28

80 자 제한을 준수해야하는 몇 가지 이유가 있습니다 (또는 74 자 제한이 더 좋습니다. 코드 검토를 수행하는 경우 diff 마커 및 이메일 인용이 추가 된 경우에도 코드가 80 열 미만으로 유지 될 수 있습니다) 메일 링리스트).

와이드 스크린 모니터 시대에도 코드의 다른 부분을 보여주는 몇 개의 창이 나란히 열려있는 것을 좋아합니다. 예를 들어, 일반적으로 웹 브라우저와 전자 메일이 한 화면에 열리고 두 개의 파일과 터미널이 두 번째 모니터에서 나란히 열립니다. 열이 80 개가 넘는 줄이있는 경우 줄을 감싸는 편집기를 다루거나 (보기 흉하고 코드를 탐색하기 어렵게 함) 창을 넓히면 화면에 여러 줄을 맞출 수 없습니다. 한번.

일반적으로이 방법으로 편집하지 않더라도 side-by-side diff 도구를 사용하는 경우 합리적인 선 길이를 가진 파일을 사용하면 diff를보다 쉽게 ​​볼 수 있습니다.

코드 밀도 문제도 있습니다. 코드를 읽을 때 많은 컨텍스트를 갖고 싶습니다. 스크롤하는 것보다 창을 위아래로 보는 것이 훨씬 빠릅니다. 매우 긴 선이있는 경우 길이가 많은 선이 많은 경향이있어 화면 공간이 많이 낭비되고 전체적으로 주어진 시간에 화면에 적은 코드를 넣을 수 있습니다.

마지막으로 매우 긴 줄이있는 경우 일반적으로 매우 복잡한 줄, 깊은 들여 쓰기 또는 매우 긴 식별자가 있음을 의미합니다. 이 모든 것이 문제가 될 수 있습니다. 복잡한 줄은 아마도 너무 많은 일을하고있을 것입니다. 여러 간단한 줄로 나눌 수 있다면 아마 그럴 것입니다. 들여 쓰기는 너무 많은 루프와 조건을 중첩하여 코드 흐름을 혼란스럽게 할 수 있음을 의미합니다. 여러 기능으로 리팩토링을 고려합니다. 식별자가 너무 길면 코드를 읽기가 매우 어려울 수 있습니다. 사람들은 일반적으로 단어를 개별 단위로 인식합니다. 모든 문자를 하나씩 읽지는 않지만 단어의 전체적인 모양을 살펴 봅니다. 긴 식별자는 이러한 방식으로 구분하기 어렵고 일반적으로 긴 경우 중복되거나 반복되는 정보를 포함합니다.

이제 코드를 80 열 미만으로 유지하는 것이 여전히 좋은 방법이지만, 종교적으로 따라야하는 규칙 중 하나가 아니기 때문에 자신에게 맞지 않는 라인을 만들기 위해 자신을 왜곡하는 것이 아닙니다. 모든 코드를 80 열 미만으로 유지하려고 시도하지만 적합하지 않을 때 너무 걱정하지 마십시오.


3
동의했다. 그러나 긴 식별자는 "의미있는 이름 사용"또는 "암호 약어 사용 안 함"과 같은 지침을 코딩하여 권장되거나 때로는 (예 :) 권장 std::vector<...>::const_iterator되지만, 후자의 경우 일반적으로 typedef로 완화 할 수 있습니다.
musiphil

좋은 이유가 있습니다. 팀 (또는 메일 목록)이 동의하는 한 정확한 줄 길이가 중요한지 확실하지 않습니다. 개인적으로, 나는 Uncle Bob의 제안으로 120자를 넘지 않아야합니다.
Allan

1
@musiphil 그래, 내가 마지막 단락을 포함시킨 이유입니다. 메서드를 선언 할 때 클래스 이름, 메서드 이름 및 반환 유형을 하나의 80 열 줄에 맞출 수없는 C ++ 행을 실행했습니다. 정말 이상한 줄 바꿈을 수행하는 대신 해당 한 줄에 대해 80 열 (또는 100 열) 규칙을 위반하는 것이 좋습니다.
Brian Campbell

46

줄을 약 100 자 미만으로 유지하면 와이드 스크린 모니터에 두 개의 편집기 창이 나란히있을 수 있습니다. 클래스 헤더 파일과 구현을 동시에 표시하거나 한쪽 코드를 다른 쪽 코드를 호출하는 것이 매우 유용합니다. 그리고 줄을 짧게 유지하면 편집기 창에 가로 스크롤 막대가 필요하지 않으므로 더 많은 수직 공간이 생깁니다.

80자가 구식 일 수 있지만 사유를 유지하는 데에는 장점이 있습니다.


1
+1, Vim 또는 다른 편집기에서 여러 소스 파일을 나란히 자주 엽니 다. 충분히 작은 글꼴과 상당히 좁은 오른쪽 여백을 사용하면 프로젝트에 대한 좋은 개요를 빠르게 얻을 수 있으며 문서를 많이 열 수도 있습니다.
greyfade

4
많은 사람들이 기본적으로 터미널과 편집기를 넓게 사용하기 때문에 80자는 여전히 관련이 있습니다. 따라서 자신을 80 명으로 제한하면 모든 창을 다시 정렬하거나 줄 바꿈 또는 가로 스크롤을 처리해야하는 것과는 대조적으로 해당 사용자에게 친숙 할 것입니다.
Brian Campbell

1
80 문자는 여전히 합리적입니다. 그보다 오래 걸리면 리팩토링 대신 코드를 과도하게 사용하고 많은 창을 나란히 배치하는 것이 매우 유용합니다. 다른 모니터를 추가하면 한 번에 볼 수있는 창 수가 늘어납니다!
Donal Fellows

1
80은 VMS에 친숙합니다. 나의 새로운 생각을 용서하지만 가능한 한 한계를 확장하고 필요한 곳에 유지해야합니다.
Ross

29

나는 모니터가 그것과 관련이 있다고 생각하지 않습니다. 적어도 더 이상은 아닙니다.

80 자로 된 줄을 코딩 할 수 없다면 아마도 잘못된 코드의 표시 일 것입니다. 너무 복잡한 표현. 들여 쓰기가 너무 깊습니다. 당신이하고있는 일을 멈추고 다시 생각해야합니다.

그러나 코드에 80 줄 이상이 필요하다고 확신하면 계속하십시오. 작게 만들기 위해 관용적 변경 사항을 추가하는 것보다 80자를 초과하는 코드를 사용하는 것이 좋습니다.

나는 이런 종류의 물건을 개인적으로 싫어합니다.

ret = my_function(parameter1, \
                  parameter2, \
                  parameter3, parameter4);

단순히 대신 :

ret = my_function(parameter1, parameter2, parameter3, parameter4);

5
첫 번째 예의 3 행이 너무 길지 않으면 2 행을 1 행으로 결합하여 훨씬 더 읽기 쉽게 만들 수 있습니다. (어떤 괄호 안에 이스케이프 개행이 필요한 언어는 무엇입니까?)

1
아, 그건 내가 쓴 의사 코드 일뿐입니다. 그러나 C가 필요하다고 생각합니다.
Cesar Canassa

4
여러 줄의 매크로 정의에서만 가능합니다. 그것은 최대 라인 길이의 선택에 크게 영향을 미칩니다 (이러한 백 슬래시를 유지하는 것은 재미 있지 않습니다). 짚맨 인 것 같아 ?

2
함수 호출에서 줄을 끊는 데 어려움을 겪으면 각 매개 변수를 한 줄씩 들여 쓰기합니다.
starblue

20

코딩?

물론 그렇습니다. 정상적인 인간은 너무 넓게 읽을 수 없습니다. 적은 열로 눈을 덜 움직이면 집중력이 향상되고 피곤함이 늦어집니다. 최소한의 이득이지만 중요한 것입니다.


3
코드가 산문과는 매우 다르다고 생각하지만, 정기적으로 (즉, 산문은 일반적으로 훨씬 더 일관성이있을 것입니다) 행을 120 개 이상의 열로 확장하는 코드를 읽는 것이 지루합니다.

6

예, 코드 라인 길이를 제한해야하는 이유가 있습니다.

  1. 화면이 넓어 지지만 때로는 코드를 인쇄해야합니다. 이런 이유로 만 .
  2. Diff-viewers는 종종 세로 분할로 선을 표시합니다. 선이 넓은 화면에서 허용 할 수있는 길이이면 더 어려워집니다.

그러나 80은 너무 작습니다. 그러나 여전히 일부 제한은 설계 원칙으로서 좋은 아이디어 일 것입니다.

때때로 그들은 때문에, 여분의 긴 줄이 허용되지 않아야 함을 말할 것 입니다 필요합니다. 그러나 대부분의 기능을 30 인치 화면에서만 볼 수 있다면 코드에 몇 가지 문제가 있습니다.


5

그것은 임의적이지만, 읽기 쉬운 것에 임의적이지 않은 한계가 있습니다. 코드 전체 또는 산문에 상관없이 초광각 텍스트 열은 스캔하고 읽기가 매우 어렵다는 것을 알았습니다. 또한 많은 다른 답변이 지적 했듯이이 코드가 화면에서 유일한 것 같지는 않습니다. 동시에 두 개 이상의 코드 창이 있고 하나의 와이드 스크린 모니터에 맞도록하는 것이 좋습니다.


3

정확히 80자를 제한하는 것은 적절하지 않습니다. 예를 들어, 한계가 85이면 어떤 변화가 있습니까?

오늘날 사용되는 모니터의 해상도는 더 높지만 텍스트 편집기 / IDE에서는 모든 공간이 텍스트보기에서 사용되지는 않습니다. 편집기에서 프로젝트에 포함 된 파일 목록을 왼쪽에 표시합니다.

넷북 또는 노트북에 사용 된 해상도는 모니터에 사용 된 해상도와 동일하지 않습니다. 다른 사람에게 "문제"를 만들지 않는 문자 제한을 사용하는 것이 좋습니다.


5
펀치 카드의 열 수에 대한 제한은 80 자입니다!
ChrisF

5
표준이 무엇인지는 중요하지 않지만 모든 사람이 동일한 표준으로 작업하면 삶이 더 쉬워집니다.
Skilldrick

2

실제로 개발 환경에 따라 다릅니다.

예를 들어, 수천 명의 개발자가있는 대기업에는 제품 수명 기간 동안 코드의 일부를 조사해야하는 수백 명의 사람들이있을 것입니다. 많은 사람들과 함께 어떤 이유로 든 (구 하드웨어, 넷북 등) 800x600 이하에서 작동하는 소수의 사람들이 있습니다. 그것들을 수용 할 가치가 있습니다.

하지만 25 명 규모의 회사에서는 망쳤다 고 말합니다. 우리는 모두 최대 해상도 120-140에서 듀얼 현대식 모니터를 사용하고 있으며 비공식 지침입니다.


2

약간의 한계가 있다는 것은 확실히 의미가 있습니다. 그러나 80 자 제한이 너무 제한적입니다. 96 자 제한과 같은 것을 선호합니다. 처리 해야하는 대부분의 코드에 대해 충분히 넓고 두 파일이 나란히 배치되어 (와이드 스크린으로) 두 파일을 나란히 넣을 수있을 정도로 좁습니다.

코드 가독성이 다른 모든 문제보다 우선합니다. 또한 라인 코드 당 96자를 사용하면 80보다 훨씬 읽기 쉽습니다.

나는 대부분의 사람들이 터미널을 80 자로 넓게 설정한다는 주장을 믿지 않으며 프린터가 80자를 초과하는 줄을 감쌀 필요는 없다. 과거 (원격) 과거에 있었던 것처럼 하드 한계가 아닙니다. 터미널과 프린터 너비를 100 자로 쉽게 설정할 수 있습니다.


1

아니요, 더 이상 관련이 없습니다.

  • 응용 프로그램과 웹에서 사용되는 대부분의 글꼴은 고정 너비가 아닙니다. 즉, 80 자! = 80 자입니다.
  • 당신이 말했듯이, 화면 너비가 변경되었습니다-80 문자는 합리적인 경계가 아닙니다.

80자는 실제로 콘솔 환경에서 고정 너비 글꼴에 대한 지침이었습니다.

물론 콘솔 환경에서 여전히 고정 너비 글꼴을 사용하는 경우 80 문자는 합리적입니다. :)


3
필자는 소스 코드에서 80 자 제한 사용을 언급하고 있다고 확신한다. 이는 거의 보편적으로 모노 스페이스 글꼴로 표시된다.
Fishtoaster

1
흠 ... 그 경우에 ... 아니,하지만 다른 이유로 :)
Damovisa

1
펀치 카드의 열 수에 대한 제한은 80 자입니다!
ChrisF

0

GUI에서 편집기를 사용하는 경우 대부분의 편집기 (예 : Notepad ++)에는 줄 바꿈을 전환 할 수있는 단추가 있으므로 줄당 80자가 관련이 없습니다. 따라서 얇은 창에서 코드를 볼 때도 문제가되지 않습니다.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.