So as you know there is a best practice saying

Limit a row of source code in 80 characters.

Here are 2 links:

Why is 80 characters the 'standard' limit for code width?

Is the 80 character limit still relevant in times of widescreen monitors?

And I am sure you can fine more if you search for this best practice.

But I find this extremely difficult, here is a sample example:

public class MyClass {

    public void myMethod() {

        final Map<String, List<MyInterfaceHere>> myReference

So you indent each class and each method and each statement.

And I am already at column 60 by the end of the last 'e' I have in 'myReference'.

I have 20 spaces left do actually call the constructor and assign the object to the reference I have.

I mean does this really look better:

public class MyClass {

    public void myMethod() {

        final Map<String, List<MyInterfaceHere>> myReference 
                = new HashMap<String, List<MyInterfaceHere>>(); 

What is the best practice here?

  • 7
    We make it 140. 80 might have been good in the days of smaller screens and smaller printers
    – tgkprog
    Mar 16, 2016 at 9:14
  • 7
    best practice unless you're on End-Of-Life versions like 5/6 would likely be final Map<String, List<MyInterfaceHere>> myReference = new HashMap<>(); (80 chars with indentation like in your example)
    – gnat
    Mar 16, 2016 at 9:16
  • 7
    A meta-best-practice is not to blindly use best practices from twenty years ago. Back when a 17" CRT sported 1280x1024 resolution, lower character limits made sense, but not today.
    – TMN
    Mar 16, 2016 at 12:38
  • 6
    Note that one benefit of using narrow columns of text rather than sprawling across all available space in your display, is the ability to easily view multiple pieces of code side by side. 80 chars * 7 pixels/char = 560 pixels per file. This allows two files (1120 px) to fit comfortably on a 1280 px wide screen, or three (1680 px) on a 1920 px screen, in both cases leaving some extra space for line numbers, scroll bars, sigils, and other UI elements. Or even the occasional slightly longer line.
    – 8bittree
    Mar 16, 2016 at 14:18
  • 5
    @8bittree I can view code side by side - on two monitors. Developing on a single monitor is like driving a car with only one wheel.
    – user22815
    Mar 16, 2016 at 16:40

7 Answers 7


The best practice should be "limit the length of a line so that you, all your colleagues, and all the tools that you are using are happy with it", plus some common sense. 80 characters seems to be very low and tends to reduce readability. I have once been totally tricked by a line like this:

/* Very long comment to the end of the line */ realCode ();

where the function call was not visible on the screen (neither was it visible on the screen of any colleague) with no indication.

I set my editor to display a 100 column margin, plus rewrapping the code on display, so everything is always visible while editing, and overly long lines tend to be manually split into two or sometimes more lines. Pray that your editor formats split statements nicely if it does auto formatting. Use a coding style that doesn't lead to deeply nested statements. (Some people create a nest of twenty if-statements followed by a tail of twenty else's which leads to 200 character deep indentation, and nobody can figure out which else belongs to which if).

In your particular case, Swift invented a way to avoid this: A "let" variable (which is about the same as "final" in other languages) must be assigned a value exactly once before it is used, but not necessarily in the declaration, so you could split your troublesome line into two independent statements.

PS. I have encountered lines, in real human-written code, that were over 400 characters. In other words, you'd have to scroll for ages to read the rest of the line, even on a 24 inch monitor. I was not amused :-(

  • 17
    Seems like /* Very long comment to the end of the line */ realCode (); ought to already break some other style rules. Mar 16, 2016 at 16:27
  • 5
    /* Very long comment to the end of the line */ realCode (); is one reason why IDEs have code formatters that automatically put the comment and code on separate lines.
    – user22815
    Mar 16, 2016 at 16:42
  • 2
    It came from the same source that wrote infamously "if (condition)\n\tgoto exit;\n\tgoto exit;". Just a few years earlier.
    – gnasher729
    Mar 17, 2016 at 9:08
  • 1
    I find that setting the max line length to 80 characters forces me to think in terms of functions and classes and OO, instead of writing a long line of text to do everything in a single shot. It makes me write programs that others can easily ready. Secondly, majority of the programemrs (In my experience) I have seen in SV work on their laptops, and dont have large screen displays available to them all the time. So writing in 80 character line limits helps everybody. Third, you can split your large monitor screen into multiple panes and view code simultaneously.
    – alpha_989
    Jan 31, 2018 at 18:10
  • What everyone should accept is that there are no prices handed out for “most complex statement in a single line”. Your compiled code won’t run any faster. Many debuggers only allow you to set breakpoints on the start of the first statement in a line.
    – gnasher729
    Feb 13 at 12:37

Yes, it does look better. That is why the "Don't use overlong lines!" maxim is so very strong.

As for best practice, I never, ever use these horribly long constructor expressions. I would always use

public class MyClass {

    public void myMethod() {

        final Map<String, List<MyInterfaceHere>> yReference = newMap();

for some suitably defined, statically imported value of newMap(). I consider it a grave defect in Java that it doesn't have built-in version.


The goal isn't "keep lines to 80 characters". The goal is "make your code easy to read and comprehend". The artificial 80 character limit helps in readability, but it isn't a hard and fast rule unless your team decides it is.

You asked for the best practice, and the best practice is "focus on making the code as readable as possible". If that requires more than 80 characters, so be it.


If you enforce line length/width of code, use a tool.

  • Resharper
  • Visual Assist
  • etc.

The developers decide what a reasonable length is (80, 120, 200, etc.), set that option in the tool.

After that, just write the code as you normally would without regards to how wide or long the line is. Once it is functional and finished, right click and choose Clean Up Code or similar option. The tool will format the code as you told it and break up long lines as indicated.

Mindless and easy and every source file will be formatted the same way.


Don't be afraid of hitting the Return key. Most modern languages (including Java as in your example) are quite happy with statements that run across several lines.

Just put a little thought about where you break the lines, and you can get something that fits into an 80 column limit and still remains perfectly readable. The official Java coding conventions even specify preferred places to break lines.

Done right, a neatly broken up line is a lot more readable than one that disappears off the side of the screen.


80 char limit may be a little too short these days, but it helps. I would agree with all those opinions that the code should be well formatted also. e.g. code

/* Very long comment to the end of the line */ realCode ();

may be within 80 chr but creates confusion as remarks and code options are on same single line.

To adhere to 80 chr limit or not to is individuals choice but if things are visible in single shot it will always give a comfortable view and feeling to programmers and other reviewers also.


For .NET you can use an analyzer (NuGet package LeetKean.Analyzers.LineLength) that will add a warning (code LK0080) into your warnings list for every line longer than 80 chars.

Not the answer you're looking for? Browse other questions tagged or ask your own question.