Consistency / Ease of refactoring / Commit lines discussion

This is expanding on #74. Sorry if this is bike-shedding or if this has already been discussed in-depth. Feel free to close for any reason.

I think priority should be given to consistency (no surprises / reading and understanding code is “easier”), ease of refactoring, and reduced git-commit lines at the expense of what initially could be viewed as “looking” better.

Some of the changes below are probably too strict and / or out of scope.

Here are some examples / proposed changes.

1. Always expand objects / arrays. it is easier and more consistent to add/remove/update fields when objects are forced into always being on a new line. Similar to the reason to always include a trailing comma, it reduces commit messages making changes cleaner to review.

2. Do not omit parens with single input arrow functions. Added for consistency / ease of refactoring. It required when used with Flow / Typescript to add types and also hinders refactoring to add fields / change to deconstructing.

3. Ternary always on their own line

4. Deconstructed exports

5. If statements with && or || operators split into multiple lines

Exceptions (possible bike-shedding?): The following would, I think, get in the way of reading and writing code.

1. import deconstructing
2. Function params
3. if statements without && / || operators

Given the following input (default prettier options + trailingComma):

import SomeModule, { test } from 'some-module';

const arr = ['printWidth', 'tabWidth'];

const obj = { first: 'one' };

const arrObj = [{ second: 'two' }, { third: 'three' }];

const otherObj = [
  { other: 1 },
  { o: 1 },
  { other: 1 },
];

const arrowFn = one => { return one };

function fn(one) {
  return one;
}

if (false) {
  console.log('never');
}

if(true && 'false' === 'false') {
   console.log('true');
}

const tern = obj ? '1' : '2';

export { otherObj };
export default arrowFn;

Would output:

import SomeModule, { test } from "some-module";

const arr = [
  "printWidth",
  "tabWidth",
];

const obj = {
  first: "one",
};

const arrObj = [
  {
    second: "two",
  },
  {
    third: "three",
  },
];

const otherObj = [
  {
    other: 1,
  },
  {
    o: 1,
  },
  {
    other: 1,
  },
];

const arrowFn = (one) => {
  return one;
};

function fn(one) {
  return one;
}

if (false) {
  console.log("never");
}

if (
  true &&
  "false" === "false"
) {
  console.log("true");
}

const tern = obj
  ? "1"
  : "2";

export {
  otherObj,
};
export default arrowFn;

[lydell]

For reference, here is a diff example (although for objects, not for arrays): http://eslint.org/docs/rules/object-property-newline

[chrisblossom]

I think priority should be given to consistency (no surprises / reading and understanding code is “easier”), ease of refactoring, and reduced git-commit lines at the expense of what initially could be viewed as “looking” better.

@jlongster You used the words “much nicer” a couple times. This is exactly what I was trying to address with this issue. I think stylistic choices should decided on what is best for long-term code quality / maintenance instead of what is easier to initially write / nicer to initially look at.

There are too many cases where collapsed objects/array are much nicer, and I don’t buy the argument that’s easier to add elements if they are on their own line. It’s easy to go into the same line, add a comma, and add a new element. And with prettier, you never have to care if it gets too long; if it does it will automatically be broken up.

You are right, adding an element is just as easy. What is more difficult is:

1. Commenting out / removing a single element

• It is easier to select entire code blocks over line positions
• For shortcuts, either you have to learn yet another shortcut to do an inline-comment (/* */), or you have to modify the element to be on a separate line.

1. Reviewing git changes

• Going from single line to multiline object will now consist of a much larger git diff than would be if it was just the element that was changed/added/removed.
• See exactly what changed. Less mental filtering.

1. Code review

• Consistency is easier to understand / look over
• Less mental filtering

I think that is a lot to give up when the only reason to keep it one line is so it initially looks better, which is subjective / personal preference / whatever you are used to.

I want to avoid only applying rules to exceptional cases. We want you to write code and generally know how it’s going to be formatted – the syntactical context doesn’t matter. Why expand exports, but not imports? It gets way too subjective, and it’s better to be fully consistent.

I agree. The majority of exceptional cases should be avoided.

For why expanded exports and not imports: I think it is much more likely for an export to be added/removed/changed/commented than an import. I think import lines are typically static, and aren’t exactly considering the “meat” of the javascript file. But this was an initial response and possible “bike-shedding” / personal preference / experience.

Single-arg arrow functions are also extremely common and I don’t think it’s worth adding parens just to make it easier to add args later. It’s really nice to just have arr.map(x => …).

It is marginally “nicer” to look at, which is really just personal preference. It is confusing for people that are unfamiliar with arrow functions.

It is not consistent / easier to change later. Every other way to write that function requires parens. If parens were added, you can still write the function without parens. Less keys to start, and have prettier add them when formatting. Win-win

To recap, I think stylistic choices should be made to promote consistency, refactoring, and code sharing/reviewing over what could be considered as looking nicer.