Please increase max-len to something useful

[reindernijhoff]

My editor can easily handle lines with over 200 characters. Setting an arbitrary limit reminiscent of my old 286 with a Hercules screen is quite frustrating. The main issue is:

It reduces the readability of my code.

Restricting the number of characters per line significantly increases the total number of lines in my code. This not only looks unappealing (for example, calling the same constructor twice with different arguments can result in one initialization fitting on a single line while the other spans five lines), but it also diminishes the clarity of my code.

I typically design my functions and classes to fit within my screen, allowing me to read and follow the entire logic without scrolling. However, adding line breaks everywhere causes my screen to overflow, making it much harder to follow.

So please trust the programmer.

I will format my lines in a way that maximizes readability. I do not need a maximum line length for that.

[ReneDrie]

I think the max-len is there also to keep the readability for Git diffs and Code Reviews, where you have the 2 next to each other (but I might be wrong). Since you guys don't do that, it makes sense for you, but most projects should have that.

[ThaNarie]

I presume this is more of an issue for our prettier config?

prettier-config/main.json

Line 3 in d4c85d4

"printWidth": 100,

I'm happy to transfer the issue to that repo instead :)

---

My editor can easily handle lines with over 200 characters.

My editor can handle 100~120 :)
So having to view your 200+ long lines and having to constantly scroll horizontally would be quite frustrating :(

The reason I'm saying that, is that everyone's setup is different, and we like to cater to most users and usages.

I typically design my functions and classes to fit within my screen, allowing me to read and follow the entire logic without scrolling. However, adding line breaks everywhere causes my screen to overflow, making it much harder to follow.

This really sounds like you're writing your code just for you, and you like to have formatting rules that only work for you and your screen.

However:

• some people have big screens, some have smaller screens
• some use higher resolutions, some lower
• some zoom in or have a larger font size
• some use a AI chat window on the right side that takes 30% of the screen
• some use other panels like code lens, file structure, etc on the right
• some like to have 2 editors next to each other (one JS one CSS, or code and unit test file)
• some like to view side-by-side diffs, either in their editor (when reviewing what to commit, or what changes are made), or in online tools like Github / Bitbucket
• some rotate their screen 90 degrees, so they see more lines of code at the same time – maybe this is a good solution for you :)
• some use online editors that have a live preview on the right side.

So it's unlikely this will be increased much, or at least to the level you want to have it (i.e. disabled).

If you are indeed working on code that only you read and write (or maybe another person with the same setup),
I would suggest that you override the rule/config for that specific project / subfolder.

[reindernijhoff]

Ha, yes: please move this to the prettier configuration repository :)

TLDR; you don't have to worry too much about horizontal scrolling when reading my code.

In my opinion, writing readable code is quite challenging and often subjective. I believe that readable code should clearly express your logic while maintaining clarity. This means avoiding overly compact code, writing too much logic on one line, or inserting unnecessary line breaks. For example, spreading the arguments of a function call over six lines does not enhance readability; rather, it thins out the code and can lead to vertical overflow and pushing relevant elements of your code away from each other.

I do my best to avoid excessively long lines in my own code. I just looked at the code of my favorite WebGL framework, and I find that only about 1% (max) of the lines exceed 120 characters (by just a bit), and most lines containing logic are between 30 and 110 characters long.

Therefore, setting the maximum line length to 120 characters would be a significant improvement. Simply removing this restriction would provide complete freedom, which I also value.

[ThaNarie]

For example, spreading the arguments of a function call over six lines does not enhance readability

In your opinion 🙂

In that case, a function call either receives too many unnamed parameters, or it's already using option objects.

---

Here a fictive example:

// bad 🔴
someFictiveFunction(true, 'my-label', someOtherVar, false, true, 50);

// also bad 🔴 
someFictiveFunction(
  true,
  'my-label',
  someOtherVar,
  false,
  true,
  50
);

Named option parameters make it more readable, and yes, it won't fit on 1 line in most of those cases, but a "definition list" is often more readable like this.

// good ✅ 
someFictiveFunction({
  doSomething: true,
  label: 'my-label',
  initialValue: someOtherVar,
  retry: false,
  failOnError: true,
  timeout: 50,
});

---

Same with function parameters, especially when they are typed, containing generic, callbacks, return types, all on a single line. (even in github this gets horizontal scrolls :( )

// bad 🔴
export function loadText(urlOrText: string | Object | Promise<any>, callback: (text: string) => void, onProgress?: (progress: number) => void) {}

Having each param on a separate line makes it more clear to see how many parameters there are, what their names is, and how they are typed:

// good ✅ 
export function loadText(
  urlOrText: string | Object | Promise<any>,
  callback: (text: string) => void,
  onProgress?: (progress: number) => void,
) {}

---

Extreme example (set to max 80), but if you'd pass another loadShader in there, and/or your the init function contains 2 extra parameters, you'd get similar results.

// decent 🔴
Promise.all([loadShader(`${shaderName}.vs.glsl`), loadShader(`${shaderName}.fs.glsl`)]).then((shaderAssets) => {
  loadIncludes(shaderAssets, (textsWithIncludes: string[]) => {
    this.init(shaderName, textsWithIncludes[0]!, textsWithIncludes[1]!, callback);
  });
});

Personally I find the below more readable

// better ✅ 
Promise.all([
  loadShader(`${shaderName}.vs.glsl`),
  loadShader(`${shaderName}.fs.glsl`),
]).then((shaderAssets) => {
  loadIncludes(shaderAssets, (textsWithIncludes: string[]) => {
    this.init(
      shaderName,
      textsWithIncludes[0]!,
      textsWithIncludes[1]!,
      callback,
    );
  });
});

---

In my opinion, writing readable code is quite challenging and often subjective.

Exactly, that's why we have a formatter and a line length, to remove the subjective discussion.
If we didn't have this rule, and you and I would work on the same codebase, we'd constantly be re-formatting each other's code, because we have a different opinion on what's readable.

It might also be slightly different in that you are mostly working in your own code. You're reading code that you've already written. And you might be looking at (searching for) different things in your code. It's different when you have to read completely new and unfamiliar code.

---

Besides opinion, there's another aspect at play here. Time saved by not having to manually format code. I can't imagine where I would have to go back to manually adding or removing line breaks, or even having to think about wether I even want to add or remove them.

Of course, there are always exceptions, but (I quote):

Even if Prettier does not format all code 100% the way you’d like, it’s worth the “sacrifice” given the benefits.

---

Simply removing this restriction would provide complete freedom, which I also value.

As mentioned earlier, this is likely not going to happen. But again, feel free to disabled it in the projects you work solo on, or in the specific sub-folders you work in on your projects.

Therefore, setting the maximum line length to 120 characters would be a significant improvement.

This is something that can be discussed, or even tried out on a few projects first, or applied to the projects you work on if those teams agree.

[reindernijhoff]

This is something that can be discussed, or even tried out on a few projects first, or applied to the projects you work on if those teams agree.

Perfect and thank you, 120 set as max-len would be really nice.