이 날과 나이에 코드 파일에 최대 80 자 너비를 적용해야하는 유효한 이유가 있습니까?

이 날과 나이에 코드 파일에 최대 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 행입니다.

---

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

You won't get any ammo from me. In fact, I'd hate to see it changed since in emergencies I still see rare cases where I need to change code from a text-console.

---

Super-long lines are harder to read. Just because you can get 300 characters across on your monitor doesn't mean you should make the lines that long. 300 characters is also way too complex for a statement unless you have no choice (a call that needs a whole bunch of parameters.)

I use 80 characters as a general rule but I'll go beyond that if enforcing it would mean putting a line break in an undesirable location.

---

The only thing I enforce to stay within 80 chars is my commenting.

Personally...I'm devoting all my brain power (what little there is) to coding right, it's a pain to have to go back and break everything up at the 80 char limit when I could be spending my time on the next function. Yes, Resharper could do it for me I suppose but then it freaks me out a little that a 3rd party product is making decisions on my code layout and changes it ("Please don't break my code into two lines HAL. HAL?").

That said, I do work on a fairly small team and all of our monitors are fairly large so worrying about what bothers my fellow programmers isn't a huge concern as far as that goes.

Seems though some languages encourage longer lines of code for the sake of more bang for the buck (short hand if then statements).

---

I have two 20" 1600x1200 monitors and I stick to 80 columns because it lets me display multiple text editor windows side-by-side. Using the '6x13' font (the trad. xterm font) 80 columns take up 480 pixels plus the scrollbar and window borders. This allows one to have three windows of this type on a 1600x1200 monitor. On windows the Lucida Console font won't quite do this (the minimun usable size is 7 pixels wide) but a 1280x1024 monitor will display two columns and a 1920x1200 monitor such as an HP LP2465 will display 3. It will also leave a bit of room at the side for the various explorer, properties and other windows from Visual Studio.

Additionally very long lines of text are hard to read. For text the optimum is 66 characters. There is a point where excessively long identifiers start to be counterproductive because they make it hard to lay out code coherently. Good layout and indentation provides visual cues as to the code structure and some languages (Python comes to mind) use indentation explicitly for this.

However, The standard class libraries for Java and .Net tend to have a preponderance of very long identifiers so one cannot necessarily guarantee to be able to do this. In this case, laying out code with line-breaks still helps to make the structure explicit.

Note that you can get windows versions of '6x13' fonts Here.

---

The other answers already summed things up nicely, but it is also worth considering when you might want to copy & paste some code into an email, or if not code then a diff.

That's a time when having a "max width" is useful.

---

You are not the only person who is going to maintain your code.

The next person who does might have a 17" screen or might need large fonts to read the text. The limit has to be somewhere and 80 chars is the convention due to previous screen limitations. Can you think of any new standard (120) and why it is a good idea to use that other then "that's what fits on my monitor at Xpt font?"

Remember, there are always exceptions to every rule so it you have a particular line or block of code that makes sense to be more than 80 chars then be a rebel.

But take the time first to think "is this code really that bad that it can not live within 80 chars?"

---

In the Linux coding standard, not only do they keep the 80 character limit, but they also use 8 space indentation.

Part of the reasoning is that if you ever reach the right margin, you should consider moving an indentation level into a separate function.

This will make clearer code because regardless of indentation lengths, it is harder to read code with many nested control structures.

---

I wonder if this might cause more problems in this day and age. Remember that in C (and possibly other languages) there are rules for how long a function name can be. Therefore, you often see very hard-to-understand names in C code. The good thing is that they don't use a lot of space. But every time I look at code in some language like C# or Java the method names are often very long, which makes it close to impossible to keep your code at a 80 characters length. I don't think 80 characters are valid today, unless you need to be able to print the code, etc.

---

As others have said, I think it's best for (1) printing and (2) displaying multiple files side by side vertically.

---

I like to limit my width to 100 chars or so to allow two SxS editors on a widescreen monitor. I don't think that there is any good reason for a limit of exactly 80 chars anymore.

---

I've widened my code out to 100 characters which fits comfortably in less than half my screen on my Macbook. 120 characters is probably the limit before lines start to get too long and complex. You don't want to get too wide else you encourage compound statements and deeply nested control structures.

The right margin is nature's way of telling you to perform an extra method refactoring.

---

Use proportional fonts.

I'm serious. I can usually get the equivalence of 100-120 characters in a line without sacrificing readability or printability. In fact it's even easier to read with a good font (e.g., Verdana) and syntax coloring. It looks a little strange for a few days, but you quickly get used to it.

---

People say long lines of code tend to be complex. Consider a simple Java class:

public class PlaintiffServiceImpl extends RemoteServiceServlet implements PlaintiffService {

This is 94 characters long and the class name is quite short (by GWT standards). It would be difficult to read on 2 lines and it is very readable on one line. Being pragmatic about it and thus allowing "backwards compatibility", I'd say 100 characters is the right width.

---

As the author of coding guidelines for my employer I have upped the line length from 80 to 132. Why this value? Well, like others pointed out, 80 is the length of many old hardware terminals. And 132 is as well! It's the line width when terminals are in wide mode. Any printer could also make hardcopies in wide mode with a condensed font.

The reason for not staying at 80 is that I rather

• prefer longer names with a meaning for identifiers
• not bother with typedefs for structs and enums in C (they are BAD, they HIDE useful information! Ask Peter van der Linden in "Deep C Secrets" if you don't believe it), so the code has more struct FOO func(struct BAR *aWhatever, ...) than code of typedef fanatics.

and under these rules just 80 chars/line cause ugly line wraps more often than my eyes deem acceptable (mostly in prototypes and function definitions).

---

I try to keep things down near 80 characters for a simple reason: too much more than that means my code is becoming too complicated. Overly verbose property/method names, class names, etc. cause as much harm as terse ones.

I'm primarily a Python coder, so this produces two sets of limitations:

1. Don't write long lines of code
2. Don't indent too much

When you start to reach two or three levels of indentation, your logic gets confusing. If you can't keep a single block on the same page, your code is getting too complicated and tricky to remember. If you can't keep a single line within 80 characters, your line is getting overly complicated.

It's easy in Python to write relatively concise code (see codegolf) at the expense of readability, but it's even easier to write verbose code at the expense of readability. Helper methods are not a bad thing, nor are helper classes. Excessive abstraction can be a problem, but that's another challenge of programming.

When in doubt in a language like C write helper functions and inline them if you don't want the overhead of calling out to another function and jumping back. In most cases, the compiler will handle things intelligently for you.

---

There's already a lot of good answers to this, but it's worth mentioning that in your IDE you might have a list of files on the left, and a list of functions on the right (or any other configuration).

You're code is just one part of the environment.

---

I thing not enforcing 80 characters means eventually word wrapping.
IMO, any length chosen for a max-width line is not always appropriate and word wrapping should be a possible answer.
And that is not as easy as it sound.

It is implemented in jedit
_{(source: jedit.org)} which offers word wrap

But it is bitterly missed in eclipse from a looong time ! (since 2003 in fact), mainly because a word wrap for text editor involves:

• Wrapped line information is for the text viewer, code navigation, vertical rulers.
• Unwrapped line information is required for functionalities like goto line, line numbering ruler column, current line highlight, saving file.

---

I actually follow a similar rule for my own code but only because of printing code to an A4 page - 80 columns is about the right width for my desired font size.

But that's personal preference and probably not what you were after (since you want ammo to go the other way).

What don't you question the reasoning behind the limit - seriously, if no-one can come up with a good reason why it's so, you have a good case for having it removed from your coding standards.

---

I'm diffing side-by-side all day long and I don't have a freakin' 22 inch monitor. I don't know if I ever will. This, of course, is of little interest to write-only programmers enjoying arrow-coding and 300-char lines.

---

Yes, because even in this day and age, some of us are coding on terminals (ok, mostly terminal emulators), where the display can only display 80 chars. So, at least for the coding I do, I really appreciate the 80 char rule.

---

I still think that the limit isn't limited on the visual part. Sure, the monitors and resolutions are big enough to show even more characters in one line nowadays, but does it increase the readability?

If the limit is really enforced it's also a good reason to re-think the code and not to put everything into one line. It's the same with indentation - if you need to much levels your code needs to be re-thought.

---

Breaking at 80 characters is something you do while coding, not afterwards. Same with comments, of course. Most editors can assist you in seeing where the 80-characters limit is.

(This may be a little OT, but in Eclipse there is an option which formats the code when you save it (according to whatever rules you want). This is a little freaky at first, but after a while you start to accept that the formatting is no more in your hands than the generated code is.)

---

If we had one of these, we wouldn't be having this discussion! ;-)

But seriously the issues that people have raised in their answers are quite legitimate. However the original poster was not arguing against a limit, merely that 80 columns is too few.

The issue of emailing code snippets has some merit. But considering the evil things that most email clients do to pre-formatted text I think that line wrapping is only one of your problems.

As for printing I usually find that 100 character lines will very comfortably fit onto a printed page.

---

I try and keep my lines below 80 columns. The strongest reason is that i often find myself using grep and less to browse my code when working at the command-line. I really don't like how terminals are breaking long source lines (they after all aren't made for that job). Another reason is that i find it looks better if everything fits into the line and isn't broken by the editor. For example having parameters of long function calls nicely aligned below each other and similar stuff.

참고 : https://stackoverflow.com/questions/110928/is-there-a-valid-reason-for-enforcing-a-maximum-width-of-80-characters-in-a-code