There we go, v0.5 of the nph formatter released.
The release comes slightly earlier than I was planning but is also fairly small, cleaning up a few inconsistencies found while applying it to fluffy, one of our P2P data sharing projects as well as serde, yet another entry in the never-ending story of turning things into JSON.
The dot-stacking logic stopped counting post-expressions (something.postExpr: ...) as regular calls and allowed calls to start on the same line as an assignment - post-expressions are a big part of ergonomics when using Result.valueOr and this change helps keep the code using it tight:
let value = someFunction().valueOr:
warning "someFunction failed", error
return
The other notable change is that all long lists, simple or not, now receive a trailing comma similar to how prettier does it, like in this example taken from the docs:
const values = [
10000000, 2000000000, 3000000000,
40000000, 5000000000,
]
Enjoy and check out the previous version announcement for the background story of how we got here :)
I know nph is opinionated and I like the general approach. One minor issue to me is the impossibility to control vertical spacing via empty lines between procs.
I tend to separate different sections within a single proc with a space, and nph lets me do that, but then to visually separate different procs I tend to use two or even three empty lines between them, but here nph brings back to 1 space separation. This makes somewhat harder to visually identify when proc starts and ends. On the other hand, this is driving me into using the "outline" vscode windows more and more.
What's the idea behind not going more than 1 empty line?
I don't have problems seeing the separation between procs even with one single indentation. Sometimes use more to separate different parts of the program, but more often than not it can be seen as simple inconsistency. Real separation is best done using comments or separate files anyway.
Another thing that can help visually identify the start and end are indentation guides. They make a more visible gap between two top level procs. Keeping procs simpler and shorter should help too.
I have to say, everytime I'm looking at a project which has two lines between functions, I like it. It is easier for the eye, with no apparent downside.
Most languages even have already one line more between functions compared to Nim, because usually they have the empty line and then above also the line with just a closing }.
vscode extension updated to format nims and nimble too: https://marketplace.visualstudio.com/items?itemName=arnetheduck.vscode-nph
A few projects I know of that migrated to nph 0.5.1, in case you're curious about what it looks like in the wild:
Regarding lines between proc's, some like 1, some like 2 and some like 3 - this is something that you can spend endless cycles discussing - 1 was chosen in nph because that's what caused the smallest diff in the projects whose code I looked at when seeking a majority opinion that would lead to the smallest diff to how nim is used in the wild.