Eclipse default line length of 80 chars outdated?

Today I write to get your opinion.

I believe defaults are important as few developers take the time to change them and in a distributed team it is often the easiest to stay with the default settings.

As we all know Eclipse defaults to 80 chars per line. After that the “Format Source” command will break the line.

A quick poll on Twitter indicated that people would like to see that limit increased.

What do you think about this setting? Wouldn’t it make sense to increase this? Is this even possible or would this change create too much noice in the version control systems of the existing code base?

About Lars Vogel

Lars Vogel is the founder and CEO of the vogella GmbH and works as Eclipse and Android consultant, trainer and book author. He is a regular speaker at international conferences, With more than one million visitors per month his website is one of the central sources for Eclipse and Android programming information.
This entry was posted in Eclipse. Bookmark the permalink.

47 Responses to Eclipse default line length of 80 chars outdated?

  1. joseph says:

    It definitely needs to be increased. I believe that developers mostly work on desktops, and screens got bigger in average during past years…. I would let those working on laptop decrease the line length if they need to… but majority is majority…. 80 is way too short.

    For me on 24″ screen, 130 is optimum and I can even have 2 java editors next to each other.

    Then I switch to project’s code formatting before I commit that to SCM and I’m done…

    JAVA language is not for 80 chars long lines :-) a few generics and number of lines doubles….

  2. Alex Moldovan says:

    A value between 120-150 would be perfect if we take in consideration our days hardware.

  3. Joachim Sauer says:

    Personally I much prefer 120 characters. It allows for a bit more information, while still being displayable in a usefully large font on a modern wide-screen monitor (and leaves some room for tools).

    Anything more than that and you need all of the screen (which is not always given). Less and there will be quite a few unnecessary line breaks in the code.

  4. Kai Tödter says:

    I use 120 with the System font.

  5. Hannes says:

    I also set to 120.

  6. We use 120 characters mostly nowadays…

  7. Charles says:

    make sense to increase, since the screen getting bigger and bigger, and source code is seldom sent to printers.

  8. Mister Potes says:

    Outdated? Absolutely – here we default to 140 width as that seems to be roughly what fits on a 1280 width monitor using the default font settings in windows. If the default were 120, we probably wouldn’t bother changing it.

  9. Guyomar Nicolas says:

    While 120 seems to be a nice limit with our current screens resolution, 80 is really user friendly when you use a lot the vertical file comparison, especially for patch reviewing (eg comitter work), diff, merge etc … 80 columns is the average maximum if you do not want to use the horizontal scrollbar to navigate through the code in this vertical display mode (with 1024×768 resolution), which is really annoying.

  10. Alex Lewis says:

    One of the first things I change is the 80 limit to 120, quite why I use 120 specifically I’m not sure but it seems to work. Possibly 120 has become the new 80 with current monitors, technology, etc. I’d agree that Eclipse should change this default value as in my opinion Eclipse is always including new technology, a place for creating new technology and thus raising the 80 limit to something more modern fits.

    Something to be aware of is that the 80 limit is recommended in the Sun Java Coding Standards (well at least for the Java Formatting).

    But there again I think the code conventions could do with a refresh, a lot has happened since 1999.

  11. Muks Dev says:

    120 chars is much more preferred…

  12. amsmota says:

    I think the 80 has to do with the 1928 IBM 80 column punched card format (from which only 72 were actually used like you can see in the Cobol coding sheets, where everything from 73-80 was ignored). And yes, I did wrote code in those sheets and I did punch those cards.

    I use 180 now because like that I just have to add a 1 in front of the 80 to save me some keystrokes… :)

  13. Henning Burdack says:

    First thing I do, is to set the line limit to 999. Yes 999, so no line limit at all for most cases.

    Why no limit? Because arbitrary line wrapping destroys the symmetry of code, which makes it harder to read.

    Yes, sometimes scrolling is required, but normally you first skim through code to understand it. In a second phase you read it in detail. Only in case of detailed evaluation you need to scroll horizontally.

    If you have code which would span more than your screen-width, these are most likely the results of combined statements. Use “Extract to local variable” in these cases.

    I would pledge to abandon the habit of line truncation completely in an IDE.

  14. Andrew says:

    I agree – it should be higher. Not fussed about the exact value – 120 characters would be fine. Sounds like the majority of people would prefer 120, and those who prefer 80 would still be able to change it back.

  15. Marc R. Hoffmann says:

    Well, is screen width actually the only reason for code formatting? What about code quality and readability? From my experience longer source lines encourage typical code smells like

    * “train wracks” (object.method1().method2().method3()…, better: try to follow the law of demeter)
    * complex and hard to understand expressions (better: use meaningful local variables)
    * deeply nested control structures (better: use smaller methods)

    I agree that declarations with generics often cause long lines. This issue has been adressed with the diamond operator in Java 7 (project coin).

    Just curious: Are you working with font default setting in Eclipse? I always turn the text editor forn size to 14pt which helps me a lot to write more compact code (beside helping my eyes to get though the day coding ;-)

  16. Darkness says:

    I working in Eclipse with my Ubuntu 15.6″ laptop, and standard 80 ch length is so comfortable for me.

  17. Mohamed El-Beltagy says:

    80 characters is definitely a short length that needs to be increased.
    But 80 characters is coming from the Java conventions document that could be found here:

    That said, I personally use a 150 characters line.. :)
    But I guess 120 as many suggested here is more perfect than 150 .. :)

  18. With 80 characters you get lots of ugly line wrapping. I tend to go for 160. Especially with method signatures it is nice if they fit on one line.

    What would be nicer still is “soft wrapping” that respects the semantics and formatting rules and your window size. I find it kind of silly that programmers still have to waste brain power on the positioning of tabs, spaces, and new lines.

    But I agree, long lines indicate design problems. Either you are violating the law of demeter, or you have some serious cohesiveness and dependency issues on a class or method. Method chaining with the builder pattern is one of the few exceptions to this and there you typically want to use newlines and indenting rather than just keep everything on one line.

    Code conventions are sort of nice to stick to but 80 characters for line length combined with the amount of verbosity in Java is not a happy combination. Especially if you use proper identifier names (i.e. ones that indicate meaning), you easily slip past 80 characters.

  19. Ufic says:

    Absolutely outdated.
    120-150 chars is preferred

  20. Dave Henderson says:

    Personally, I stick with 80… Even on my 22″ 1920×1200 monitor. When I’m just editing code, sure there is a lot of whitespace on the right side of the editor, however where I find it matters is when I’m comparing 2 files (either manually with side-by-side editors, or with the Compare editor). In that instance, it’s annoying to have to scroll horizontally to see what changed.

    I like having my Package explorer view on the left of my screen, and an Outline view on the right. With these two open, and 2 side-by-side editors in the middle, I honestly don’t see how anyone could effectively use 120ch lines.

    Just my 2 cents…

  21. I’m using 180 since I have dual-widescreen. I must agree with ‘Henning Burdack’ that line breaks destroy the symmetry of code.

  22. Kent says:

    I set to 160.
    Not only bigger screen but also code style which I prefer more longer then 80 lenth. The meanful naming is good practice for code style. Nowadays, most IDE have code completion (code assist) funciton. We have no need type short variable for saving typing.

  23. Ricardo says:

    I´m used to write code in netbeans where lines extension never is a problem. but now i´ve started programming Android and I´ve started using eclipse. I did not know about this issue but i think lines length should be longer, specially when programming Java.

  24. Alex Blewitt says:

    I’m going to buck the trend by saying it should stay at 80 characters. Yes, the line length is somewhat anachronistic as it was based on the size of TTYs when they were real pieces of hardware (and one of which I have in my garage…but that’s another story).

    However, most terminal emulators (e.g., xterm) will default to 80 characters wide. Lines longer than this can spill over to the next line which can get in the way of indenting.

    Git commit messages also recommend a max line length which is based around an 80 character terminal as well. The first line is encouraged to be shorter still (so a ‘git log’ can display the message along with the commit hash).

    There’s no doubt that some prefer longer lines; but then, there’s no problem with changing the default preference to something that you’re more comfortable with if that suits you.

    However, when you work with projects that may be used by many different people, you can’t guarantee that they’ve all got terminals (or editors) that they maximise. If you use the Java Browsing view in Eclipse, and fast views for support views like JUnit tests, then you can get away with much longer lines than if you are still using the Java view and have the other views docked on the right.

    So the problem is more to do with an out-of-the-box experience. For those new to Eclipse, using 80 is a safe bet. For those that want to adopt into the longer line conventions, that’s easy to do as well – even set on a per-project basis with the .settings (which is arguably superior since it can be stored in the version control system and ensure everyone uses the same, instead of individual workspaces using different lengths).

  25. Jens v.P. says:

    I’m still using 80. Simply because I always try to use the default settings in order to reduce problems with version control systems. But yes, I would agree, 80 seems so anachronistic today. How about a new feature: instead of 1 line setting, two of them: one to be used in the editor, and one used to communicate with version control systems…

  26. Lars Vogel says:

    Thanks for all your comments. I think the majority like the idea of increasing the default size. I think the usage of 80 char terminals is the exception and not the normal use case. IMHO Eclipse defaults should cover the 90% case not the least common doniminator. Terminal usage and using Eclipse is nowadays IMHO not the normal case for a new user.

    Please vote +1 or -1 for the bug:

  27. Andreas Zimmermann says:

    It it definitely a good idea to leave the past technical limits behind us and concentrate on platforms, on which developers work today.

  28. Alban says:

    I feel 80 boring, I’m using 130 :)

  29. JavaCoder says:

    We use 120 chars in our project too

  30. Justin says:

    Even with an old 19″ monitor, 150 chars is fine as I always expand the editor in Eclipse to full screen. I too hate 80 chars!

  31. peter says:

    We use 160 with “never join already wrapped lines”.

  32. Jared Fordham says:


  33. Christian Rataj-Weinreben says:

    Also +1 for 120

  34. Ted says:

    Please use 132 columns. It will make this aging geek happy.

  35. Alex says:

    I think 120 is a bit on the wide side, even in 2011. (I do write longer lines, sometimes, but I do feel bad about it!)

    Looking at raw code in my editor is not the only way we look at it. When you run your version control “blame” command, you get revision numbers next to each line. When you run grep (er, I mean ack!), you get filenames and line numbers added to each line. And so on. That means I need to run all these other tools in windows that are much wider than 120 characters, or whatever width you pick.

    On the display I’m using now (1920px across — a common size), with a medium-small font, I get 268 characters across in one window, or a few less if split into multiple windows. Two evenly-split windows have enough room for code + a bit of annotation at 100 characters, but not at 120. (Scrolling horizontally a bit won’t kill me, certainly, but then, does scrolling vertically?)

    I think going to 100 is a win all around. Going to 120, you start running into size tradeoffs again. And realistically, looking at some 100-char lines I have here, it’s hard to see how life would be better if I let them get much longer, anyway, even if I had no tools.

  36. Gotta Program says:

    Anything beyond 120 and I have to make the font too small for my old eyes to read. If I want to have a side-by-side diff of code even 120 is too much. I will admin that 80 is not enough for some Java code with generics filling up much of the line, so I split the difference and try to keep everything under 100 characters.

    I definitely do not want any horizontal scrolling. Any code that falls off the right side of the screen is just not visible when reading the code normally which makes it too easy to not see something important which might be ‘hiding’ over there.

  37. 80 is still preferred by me; I think it’s an excellent reminder to write code that is short and readable. It’s also a good length to have the views still visible around the code (outline view, package manager etc).

  38. 9000 says:

    Either 80 or over 9000.

  39. frankie says:

    I use 92 since I began programming because it still fits nicely on an A4, using a font that is still comfortable in size, in those cases that I want to print out a snippet for closer inspection.

  40. delor says:

    100 @work
    120 @home

  41. Michael says:

    How about you set your code line-length to a number similar to your blog line-length, for the same reason: readability.

  42. Flo says:

    I think switching to 120 is a good idea. However I would not reformat all legacy code to avoid “noise in version control system” (there is a typo in the post : “noice” instead of “noise”). The eclipse formatter option “Never join already wrapped lines” would help with legacy code.

  43. David says:

    Well, it seems 120 is the most popular.

    Personally I think no limit is the best default. If you have people trying to cram entire functions onto a single line, that is a different problem and setting a max line length won’t fix it, just sweep it under a particularly flimsy bit of carpet.

    Oh and most long lines seem to come from lots of method chaining, which causes big problems with readability and when the innevitable NullPointerException occurs you can’t work out what happened (at least in Java, though equivalent in most languages). So have at most one candidate for Null pointer exception; and do away with long lines, wrapping and hopefully unreadable code all in one go.

  44. I don’t think there should be *any* limit. An IDE should be smart enough to format the code on the screen however the user wants, without changing the underlying data.

    If I’m on a 27″ screen, I want to be able to use the whole width. If i’m on a 10″ netbook, I want the same code to look good too.

    (XCode does this smart wrapping, btw)

  45. Evil Otto says:

    Absolutely not outdated.

    80 characters is less about the size of the font/window/monitor and more about how many thoughts are expressed on a line, or more specifically for programs the number of expressions. If the lines are that long then there is probably too much to understand on each line. (Yes, that includes overly long identifier names)

Comments are closed.