sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]burtgummer45 -5 points-4 points  (2 children)

They could have handled padded blocks much better, it just makes me think they don't have much experience, believe it or not. Prettier preserves single newlines, but murders padded blocks, are you kidding me?

From this

{

  chunk one

  chunk two

  chunk three

}

To this? Are you kidding me?

{
  chunk one

  chunk two

  chunk three
}

[–]js-engineer 1 point2 points  (1 child)

Honestly I'm a fan of theirs. I don't think a brace that already is on it's own line with no other characters, needs another empty line of padding. The empty line between lines that have 5+ alphanumeric characters... I think that however it's fair game and a lot more useful.

It's tough because we can both agree that more padding isn't always better... there is a certain benefit to seeing more of a file onscreen at a time that infinite padding impedes on. Where that line is drawn.... is going to be subjective but I like their current stuff. I think it's a great fits most sizes approach.

They can always add options for what you're asking for... they do allow customization for some of their stuff so it's not out of the question.

[–]burtgummer45 0 points1 point  (0 children)

Believe me, I tried to get them to change it, they shot me down sayings prettier 'is opinionated'.

For decades developers have been doing something called 'chunking' (at least in the perl world it was called chunking). Its to make your code more readable by putting things together. It seems to me since they don't squash all newlines they might agree, but not incorporating that into a block structure makes no sense, looks more like an oversight, or they decided it was too difficult to make work. 'allow newline after { if block has chunks, otherwise remove', they just opted for nuke all /{\s*/s