이 시대에 코드 파일에 최대 80 자 너비를 적용해야하는 유효한 이유가 있습니까? [닫은]

진심으로. 22 인치 모니터에서는 화면의 1/4 만 덮을 수 있습니다.이 규칙을 줄이기 위해 탄약이 필요합니다.

나는 제한이 없어야한다는 말이 아닙니다. 그냥 80 글자가 매우 작습니다.

80 열 (또는 79) 열로 코드를 유지하는 관행은 원래 80 열 덤 터미널 또는 80 열 인쇄에서 코드를 편집하는 사람들을 지원하기 위해 만들어 졌다고 생각합니다. 이러한 요구 사항은 현재 대부분 사라졌지 만 80 열 규칙을 유지해야하는 유효한 이유는 여전히 있습니다.

• 이메일, 웹 페이지 및 서적에 코드를 복사 할 때 줄 바꿈을 피하십시오.
• 여러 소스 창을 나란히 또는 단계별 diff 뷰어를 사용하여 볼 수 있습니다.
• 가독성을 향상시킵니다. 눈을 좌우로 스캔하지 않고도 좁은 코드를 빠르게 읽을 수 있습니다.

마지막 요점이 가장 중요하다고 생각합니다. 지난 몇 년 동안 디스플레이의 크기와 해상도가 커졌지 만 눈은 그렇지 않았습니다 .

80 열 텍스트 형식의 기원은 80 열 터미널보다 빠릅니다. IBM 펀치 카드는 1928 년으로 거슬러 올라갑니다 ! 이것은 로마 철도의 전차 바퀴 너비에 의해 미국 철도 계기판이 결정되었다는 (아포 크리프) 이야기를 떠올리게합니다 .

때로는 약간의 수축을 발견하지만 표준 제한 이 있는 것이 합리적 이므로 80 열입니다.

다음은 Slashdot에서 다루는 동일한 주제 입니다.

그리고 여기 구식 포트란 진술이 있습니다 :

요즘 80 문자는 어리석은 한계입니다. 임의의 문자 제한이 아닌 코드 라인을 의미있는 곳으로 분할하십시오.

22 인치 와이드 스크린 모니터가없는 모든 사람을 위해해야합니다. 개인적으로 저는 17 인치 4 : 3 모니터를 사용하는데, 그 너비는 충분히 넓습니다. 그러나 3 개의 모니터가 있으므로 사용 가능한 화면 공간이 여전히 많습니다.

뿐만 아니라 줄이 너무 길면 사람의 눈에는 실제로 텍스트를 읽는 데 문제가 있습니다. 어느 라인에서 길을 잃기 쉽습니까? 신문은 17 인치 (또는 그와 비슷한 크기)이지만 페이지 전체에서 글을 쓰지 않고 잡지 나 기타 인쇄 된 기사도 마찬가지입니다. 열을 좁 히면 실제로 읽기가 더 쉽습니다.

사소한 변형으로 반복되는 일련의 명령문이있는 경우 유사점과 차이점이 선으로 그룹화되어 차이점이 수직으로 정렬되면 더 쉽게 유사점과 차이점을 확인할 수 있습니다.

나는 여러 줄로 나누면 다음보다 훨씬 더 읽기 쉽다고 주장한다.

switch(Type) {
case External_BL:   mpstrd["X"] = ptDig1.x - RadialClrX;    mpstrd["Y"] = ptDig1.y - RadialClrY;    break;
case External_BR:   mpstrd["X"] = ptDig1.x + RadialClrX;    mpstrd["Y"] = ptDig1.y - RadialClrY;    break;
case External_TR:   mpstrd["X"] = ptDig1.x + RadialClrX;    mpstrd["Y"] = ptDig1.y + RadialClrY;    break;
case External_TL:   mpstrd["X"] = ptDig1.x - RadialClrX;    mpstrd["Y"] = ptDig1.y + RadialClrY;    break;
case Internal_BL:   mpstrd["X"] = ptDig1.x + RadialClrX;    mpstrd["Y"] = ptDig1.y + RadialClrY;    break;
case Internal_BR:   mpstrd["X"] = ptDig1.x - RadialClrX;    mpstrd["Y"] = ptDig1.y + RadialClrY;    break;
case Internal_TR:   mpstrd["X"] = ptDig1.x - RadialClrX;    mpstrd["Y"] = ptDig1.y - RadialClrY;    break;
case Internal_TL:   mpstrd["X"] = ptDig1.x + RadialClrX;    mpstrd["Y"] = ptDig1.y - RadialClrY;    break;
}

업데이트 : 의견에서 이것은 위의 작업을보다 간결한 방법으로 제안합니다.

switch(Type) {
  case External_BL: dxDir = - 1; dyDir = - 1; break;
  case External_BR: dxDir = + 1; dyDir = - 1; break;
  case External_TR: dxDir = + 1; dyDir = + 1; break;
  case External_TL: dxDir = - 1; dyDir = + 1; break;
  case Internal_BL: dxDir = + 1; dyDir = + 1; break;
  case Internal_BR: dxDir = - 1; dyDir = + 1; break;
  case Internal_TR: dxDir = - 1; dyDir = - 1; break;
  case Internal_TL: dxDir = + 1; dyDir = - 1; break;
}
mpstrd["X"] = pt1.x + dxDir * RadialClrX;
mpstrd["Y"] = pt1.y + dyDir * RadialClrY; 

지금은 80 열에 맞지만 내 요점은 여전히 ​​존재하고 있다고 생각합니다. 행에 여러 명령문을 배치하면 가독성을 향상시킬 수 있음을 여전히 보여줍니다.

기본 크기로 고정 폭 글꼴을 인쇄하는 것은 (A4 용지에서) 80 열 x 66 행입니다.

더 큰 화면의 이점을 사용하여 서로 옆에 여러 코드 조각을 갖습니다.

당신은 나에게서 탄약을 얻지 못할 것입니다. 사실, 나는 비상 사태 이후에 텍스트 콘솔에서 코드를 변경 해야하는 드문 경우를 본 이후로 변경되는 것을 싫어했습니다.

매우 긴 줄은 읽기 어렵습니다. 모니터에서 300자를 넘길 수 있다고해서 줄을 길게 만들어야하는 것은 아닙니다. 선택의 여지가없는 한 (전체 매개 변수가 필요한 호출) 300 자도 명령문에 너무 복잡합니다.

나는 일반적으로 80자를 사용하지만 그것을 강제하면 바람직하지 않은 위치에 줄 바꿈을 넣는 것을 의미합니다.

80 문자 이내로 유지하도록 강요하는 유일한 것은 내 의견입니다.

개인적으로 ... 나는 모든 뇌의 힘을 (소소한) 코딩에 바치고 있습니다. 다음 기능에 시간을 보낼 수있을 때 다시 돌아가서 80 자 제한에서 모든 것을 깨뜨리는 것은 고통입니다. . 예, Resharper가 제게 생각할 수는 있지만 타사 제품이 코드 레이아웃을 결정하고 변경한다는 사실을 조금 놀라게합니다 ( "코드를 두 줄로 HAL하지 마십시오. HAL?" ).

즉, 나는 상당히 작은 팀에서 일하고 있으며 모든 모니터는 상당히 커서 동료 프로그래머가 무엇을 방해하는지에 대해 걱정하지 않습니다.

일부 언어는 더 많은 돈을 벌기 위해 더 긴 코드 줄을 권장하는 것처럼 보입니다 (그렇다면 짧은 손).

2 개의 20 "1600x1200 모니터가 있고 여러 텍스트 편집기 창을 나란히 표시 할 수 있기 때문에 80 열을 고수합니다. '6x13'글꼴 (trad. xterm 글꼴)을 사용하면 80 열에 480 픽셀에 스크롤 막대가 더해집니다 창 테두리 1600x1200 모니터에서이 유형의 창 세 개를 가질 수 있습니다 .Windows에서는 Lucida Console 글꼴이이 작업을 수행하지 않지만 (최소 사용 가능한 크기는 7 픽셀) 1280x1024 모니터는 두 개의 열을 표시합니다. HP LP2465 와 같은 1920x1200 모니터 는 3을 표시합니다. 또한 Visual Studio의 다양한 탐색기, 속성 및 기타 창을위한 공간도 약간 남습니다.

또한 매우 긴 텍스트 줄은 읽기 어렵습니다. 텍스트의 경우 최적은 66 자입니다. 지나치게 긴 식별자는 코드를 일관되게 배치하기 어렵 기 때문에 역효과를 낳기 시작합니다. 좋은 레이아웃과 들여 쓰기는 코드 구조에 대한 시각적 단서를 제공하고 일부 언어 (Python이 떠오를 것)는이를 위해 들여 쓰기를 명시 적으로 사용합니다.

그러나 Java 및 .Net 용 표준 클래스 라이브러리는 매우 긴 식별자보다 우월한 경향이 있으므로 반드시이를 수행 할 수 있다고 보장 할 수는 없습니다. 이 경우 줄 바꿈이있는 코드를 배치하면 구조를 명시 적으로 만드는 데 여전히 도움이됩니다.

'6x13'글꼴의 Windows 버전을 Here에서 얻을 수 있습니다 .

사람들은 긴 코드 줄이 복잡한 경향이 있다고 말합니다. 간단한 Java 클래스를 고려하십시오.

public class PlaintiffServiceImpl extends RemoteServiceServlet implements PlaintiffService {

길이는 94 자이며 클래스 이름은 매우 짧습니다 (GWT 표준에 따라). 두 줄로 읽기가 어렵고 한 줄에서 읽을 수 있습니다. 그것에 대해 실용적이고 "역 호환성"을 허용하기 때문에, 나는 100 문자가 올바른 너비라고 말하고 싶습니다.

다른 답변은 이미 훌륭하게 요약되었지만 전자 메일에 코드를 복사하여 붙여 넣을 때 또는 코드가 아닌 경우 diff를 고려할 가치가 있습니다.

"최대 너비"가 유용 할 때입니다.

귀하는 귀하의 코드를 유지할 유일한 사람이 아닙니다.

17 "화면이 있거나 텍스트를 읽으려면 큰 글꼴이 필요할 수있는 다음 사람은 이전 화면 제한으로 인한 어딘가에 80 자까지 적용해야합니다. 새로운 표준 (120)과 "Xpt 글꼴의 모니터에 맞는 것"이외의 다른 것을 사용하는 것이 좋은 생각 인 이유는 무엇입니까?

모든 규칙에는 항상 예외가 있으므로 80 자 이상이되는 특정 행 또는 코드 블록이 있으면 반란군이됩니다.

그러나 먼저이 코드가 80 문자 이내로 살 수 없다는 것이 나쁜가?

Linux 코딩 표준에서는 80자를 제한 할뿐만 아니라 8 개의 들여 쓰기를 사용합니다.

올바른 여백에 도달하면 들여 쓰기 수준을 별도의 함수로 옮기는 것이 좋습니다.

들여 쓰기 길이에 관계없이 중첩 된 제어 구조가 많은 코드를 읽기가 더 어렵 기 때문에 코드가 더 명확 해집니다.

Macbook 화면의 절반 이하로 편안하게 사용할 수있는 코드를 100 자로 확장했습니다. 줄이 너무 길고 복잡해지기 전에 120자를 사용하는 것이 좋습니다. 너무 넓어지고 싶지 않다면 복합 문장과 깊이 중첩 된 제어 구조를 권장합니다.

올바른 마진은 추가 메소드 리팩토링 을 수행하도록 말하는 자연의 방법입니다 .

이것이 오늘날과 시대에 더 많은 문제를 일으킬 수 있는지 궁금합니다. C (및 다른 언어)에는 함수 이름의 길이에 대한 규칙이 있습니다. 따라서 종종 C 코드에서 이해하기 어려운 이름을 보게됩니다. 좋은 점은 공간을 많이 사용하지 않는다는 것입니다. 그러나 C # 또는 Java와 같은 언어로 코드를 볼 때마다 메소드 이름이 매우 길어서 코드를 80 자 길이로 유지하는 것이 거의 불가능합니다. 코드 등을 인쇄 할 수 없다면 80 문자가 유효하다고 생각하지 않습니다.

고용주를위한 코딩 지침의 저자로서 줄 길이를 80에서 132로 올렸습니다. 왜이 값이 있습니까? 글쎄, 다른 사람들이 지적했듯이 80은 많은 오래된 하드웨어 터미널의 길이입니다. 그리고 132도 있습니다! 터미널이 와이드 모드 일 때의 선 너비 입니다. 또한 모든 프린터는 압축 된 글꼴로 와이드 모드에서 하드 카피를 만들 수 있습니다.

80에 머물지 않는 이유는 오히려

• 식별자를 의미하는 더 긴 이름을 선호
• (! 그들이 유용한 정보를 숨기기 나쁜 당신이 그것을 믿지 않는 경우 "깊은 C 비밀"에서 린든 데르 피터 밴 문의) C에서 구조체와 열거 형 구조체에는 신경 코드가 더있다, 그래서없는 struct FOO func(struct BAR *aWhatever, ...)형식 정의 광신자의 코드를보다 .

이 규칙에 따르면 80 자 / 라인만으로도 제 눈이 수용 할 수있는 것보다 더 못생긴 줄 바꿈이 더 자주 발생합니다 (주로 프로토 타입 및 함수 정의에서).

다른 사람들이 말했듯이 (1) 인쇄 및 (2) 여러 파일을 세로로 나란히 표시하는 것이 가장 좋습니다.

와이드 스크린 모니터에서 두 개의 SxS 편집기를 허용하기 위해 너비를 100 자로 제한하고 싶습니다. 더 이상 정확히 80 자로 제한할만한 이유가 있다고 생각하지 않습니다.

비례 글꼴을 사용하십시오.

나는 진지하다. 나는 보통 가독성이나 인쇄 가능성을 희생하지 않고 한 줄에 100-120자를 동등하게 얻을 수 있습니다. 사실 좋은 글꼴 (예 : Verdana)과 구문 색상을 사용하면 훨씬 쉽게 읽을 수 있습니다. 며칠 동안 조금 이상해 보이지만 빨리 익숙해집니다.

간단한 이유로 80자를 가까이 유지하려고합니다. 그보다 너무 많으면 코드가 너무 복잡해집니다. 지나치게 자세한 속성 / 메소드 이름, 클래스 이름 등은 간결한 것만 큼 많은 피해를줍니다.

저는 주로 파이썬 코더이므로 두 가지 제한 사항이 있습니다.

1. 긴 코드 줄을 작성하지 마십시오
2. 너무 많이 들여 쓰지 마십시오

들여 쓰기 수준이 2 ~ 3 단계에 도달하면 논리가 혼란스러워집니다. 같은 페이지에 단일 블록을 유지할 수 없으면 코드가 너무 복잡하고 기억하기가 어렵습니다. 80 자 이내로 한 줄을 유지할 수 없으면 줄이 지나치게 복잡해집니다.

파이썬에서는 가독성을 희생하면서 비교적 간결한 코드 (코드 골프 참조)를 작성하는 것이 쉽지만 가독성을 희생하여 자세한 코드를 작성하는 것이 훨씬 쉽습니다. 도우미 메서드는 나쁜 것이 아니며 도우미 클래스도 아닙니다. 과도한 추상화는 문제가 될 수 있지만 프로그래밍의 또 다른 과제입니다.

C와 같은 언어로 의심되는 경우 도우미 함수를 작성하고 다른 함수를 호출하고 뒤로 건너 뛰는 오버 헤드를 원하지 않으면 인라인하십시오. 대부분의 경우 컴파일러는 지능적으로 처리합니다.

이미 이것에 대한 좋은 대답이 많이 있지만 IDE에서 왼쪽에 파일 목록이 있고 오른쪽에 기능 목록 (또는 다른 구성)이있을 수 있습니다.

당신은 코드가 환경의 한 부분 일뿐입니다.

80자를 적용하지 않는 것은 결국 단어 줄 바꿈을 의미합니다.
최대 너비 줄에 대해 선택된 모든 길이가 항상 적절한 것은 아니며 단어 줄 바꿈이 가능한 대답이어야합니다.
그리고 그것은 쉬운 것처럼 쉽지 않습니다.

단어 줄 바꿈을 제공하는 jedit _{(source : jedit.org )} 로 구현됩니다 _.

그러나 그것은 일식에서 엄청나게 빠졌다 ! (2003 년 이후) 주로 텍스트 편집기의 줄 바꿈 에는 다음이 포함 되기 때문입니다 .

• 줄 바꿈 된 정보는 텍스트 뷰어, 코드 탐색, 세로 눈금자를위한 것입니다.
• 줄 바꾸기 줄 정보는 이동 줄, 줄 번호 매기기 눈금자 열, 현재 줄 강조 표시, 파일 저장과 같은 기능에 필요합니다.

실제로 내 코드와 비슷한 규칙을 따르지 만 A4 페이지에 코드를 인쇄하기 때문에 80 열이 원하는 글꼴 크기에 적합한 너비입니다.

그러나 그것은 개인적 취향이며 아마도 탄약이 다른 방향으로 가고 싶어하기 때문에 당신이 쫓아 온 것이 아닐 것입니다.

한계 뒤에있는 추론에 의문을 제기하지 않는 이유는 무엇입니까? 아무도 그럴만 한 이유가 아무도 없다면 코딩 표준에서 제거 해야하는 좋은 사례가 있습니다.

나는 하루 종일 나란히 흩어져 있고 22 인치 모니터가 없습니다. 내가 할 것인지 모르겠습니다. 물론 이것은 화살표 코딩과 300 문자 행을 즐기는 쓰기 전용 프로그래머에게는 거의 관심이 없습니다.

그렇습니다. 오늘날에도 불구하고 우리 중 일부는 터미널에 코딩하고 있기 때문에 대부분 터미널 에뮬레이터를 사용합니다. 디스플레이에는 80 자만 표시 할 수 있습니다. 따라서 적어도 내가하는 코딩에 대해서는 80 문자 규칙을 정말로 고맙게 생각합니다.

나는 여전히 한계가 시각적 부분에 국한되지 않는다고 생각합니다. 물론, 모니터와 해상도는 오늘날 한 줄에 더 많은 문자를 표시 할만큼 충분히 크지 만 가독성이 향상됩니까?

제한이 실제로 적용되면 코드를 다시 생각하고 모든 것을 한 줄에 넣지 않는 것이 좋습니다. 들여 쓰기와 동일합니다. 많은 수준에서 코드를 다시 생각해야 할 경우.

80 자 이상으로 나누는 것은 나중에 코딩 하지 않고 코딩 하는 작업입니다. 물론 코멘트와 동일합니다. 대부분의 편집자가 80 자 제한이있는 위치를 확인하는 데 도움을 줄 수 있습니다.

(이것은 약간의 OT 일 수 있지만 Eclipse에는 코드를 저장할 때 코드를 저장하는 옵션이 있습니다 (원하는 규칙에 따라). 처음에는 약간 이상하지만 조금 후에는 그것을 받아들이 기 시작합니다. 형식은 생성 된 코드보다 더 중요합니다.)

우리가 하나가 있다면 이를 , 우리는이 토론을하지 않을 것입니다! ;-)

그러나 사람들이 자신의 답변에서 제기 한 문제는 매우 합법적입니다. 그러나 원래 포스터는 한계에 대해 논쟁하지 않았으며 단지 80 개의 열이 너무 적습니다.

이메일 코드 스 니펫 문제에는 몇 가지 장점이 있습니다. 그러나 대부분의 전자 메일 클라이언트가 미리 서식이 지정된 텍스트에 수행하는 악의적 인 점을 고려하면 줄 바꿈이 문제 중 하나라고 생각합니다.

인쇄에 관해서는 보통 100 문자 줄이 인쇄 된 페이지에 매우 편안하게 맞습니다.

줄을 80 열 아래로 유지하려고합니다. 가장 강력한 이유는 명령 줄에서 작업 할 때 종종 내 코드를 사용 grep하고 less찾아 보는 것입니다. 터미널이 긴 소스 라인을 끊는 방법이 정말 마음에 들지 않습니다 (결국 그 일을 위해 만들어지지는 않았습니다). 또 다른 이유는 모든 것이 줄에 들어가고 편집기에 의해 깨지지 않으면 더 좋아 보인다는 것입니다. 예를 들어 긴 함수 호출의 매개 변수가 서로 아래에 잘 정렬되어 있습니다.