Multiple variable declaration per line code style

I’ve found when reading the source code that there’s two styles of variable declarations:

One per line:

let top = where
let active = []

Multiple per line:

let pos = startPos + offset, dom = this.renderNode(node, pos, offset)
let dom = this.doc.createElement(structure[0]), attrs = structure[1], start = 1

I’ve found that it’s mentally hard to parse, as in my mind there’s no consistency across the code base. I realise it’s just a style issue that might only affect me, but thought it was worth asking about anyway.

But perhaps there is a pattern I’m just missing it? I’ve considered these but they don’t seem to correlate:

  • 80 characters per line wrapping
  • declarations vs declarators
  • I feel like I’ve considered others but can’t think of any more…

My personal preference would be to spread them out to be one per line, without commas, as I find this the most simple and easy to read form.

Enforcement via editorconfig and/or eslint would be nice too.

There isn’t a hard rule I use for when to put declarations on a single line. There also isn’t a hard rule I use for when to make conditionals or loops single line, or when to insert a blank line, etc. It’s just whatever looks okay to me when I’m writing the code. And I think that’s okay – the language is well-defined, you can read code even if its style isn’t 100% mechanically predicable.

I had to source dive the ProseMirror code recently to get a few things working on my current project, and I have to say that the code style certainly made things harder to follow than I’m used to.

I typically adhere strictly to an eslint config—airbnb’s is good, I personally use Standard where possible. Coming from one of these code styles, which is common across most of the libraries I use, it made ProseMirror’s source much more difficult to follow.

I don’t want to get into anything deeply or be contrary, I just wanted to provide a data point. :slight_smile: If you’re considering enforcing some style for the project in the future, I do think it would be very beneficial based on my experience with large codebases that do so.

1 Like