The nph branch shows the formatted language sources - similarly, here's a commit from another project: https://github.com/status-im/nimbus-eth2/commit/2836af94fe320255648de1e0d87f157ed757ac3b
Although , by far is the most popular choice for parameter separator, some people have mentioned a preference for ; as parameter separation for clarity, which to a certain extent I can agree with - one thing of note is that nph will format complex or long proc parameter lists with newlines, thus providing a different way of making complex proc's readable - here's an example:
Original:
proc getNullValueAuxT(p: BProc; orig, t: PType; obj, constOrNil: PNode,
result: var Rope; count: var int;
isConst: bool, info: TLineInfo)
Formatted:
proc getNullValueAuxT(
p: BProc,
orig, t: PType,
obj, constOrNil: PNode,
result: var Rope,
count: var int,
isConst: bool,
info: TLineInfo,
)
This long-form style still groups parameters of the same type (orig, t) but with a newline instead of ; - it is of course a matter of taste to use this many lines, but hey - it's also a good sign that some refactoring is due.
As noted previously, we can have any two of happy ; users, happy , users and opinionation - nph chooses the latter two - not that I think ; is a bad choice necessarily - it does, as was pointed out in the v0.2 thread, have a venerable history of several now extinct languages behind it and one could argue it fits the AST structure slightly better - that said, implementation concerns and popularity (smaller format-existing-code-diff) tipped the scales here - if someone wants to go on a crusade here and rework the grammar to be less ambiguous, nph will follow - until then...
Anyway, what's nice about this release is that apart from the comma, things have settled down quite a bit with actual formatting changes - still a few fixes to do, in particular around inline expressions (to make simple ones less clunky), but given how well it works already (hey, we're still at 0.3..) with most source code I'm testing it on, hopefully we're at a structurally good point and there's now time to focus on polish.
In other news, the proposal to "bless" hanging indent (over vertical alignment) in NEP1 got accepted meaning that the nph output by and large is in line with community guidance on this subject which is nice ;)
Past threads:
Error: Unsatisfied dependency: nim (2.0.0)
👑 v2.0.2
I had a set of chained replaces that were set out as a vertical list
.replace(x1, y1)
.replace(x2, Y2)
.replace(X3 ,Y3)
.replace(x1,y1).replace(
X2,Y2).replace(X3,Y3) etc....
let mySwaps = @[(x1,y1),(x2,y2),(x3,y3]....[(x10, y10)]
let
mySwaps =
@[
(x1,Y1),
(x2,Y2),
....
(x10,y10)
]
I'm struggling to understand why, in a language that uses indentation to enforce structure, the 'of' in case statements is aligned with the 'case' rather than being indented.
The extra indentation would be redundant because an of block has to belong to a case statement.
The tongue in cheek response to that observation is that it illustrates the 'if, elif else' structure is smelly. and would be better replaced with a 'case' like structure which branches on the first 'true'.
E.g
If
of Expression1:
of Expression2:
of Expression3:
else:
But what would I know,being an amateur programmers whose previous playground was VBA <big smiley>
The tongue in cheek response
It's a reasonable response and opinion but it's far less effort to just accept the status quo. :P
Quite a few people have provided feedback that 1 .. 3 and 1 ..< 3 should have spaces to match all the other operators while NEP1 says they shouldn't.
I've seen both styles in the wild but obviously because nph removes the spaces, those wanting their spaces back have been more vocal. Who cares about this, and why?
What you are learning is that nph should not be enforcing a style but rather a view. i.e. nph can take nim however it is written and then present it in the ide in a format preferred by the user.
Using this approach it does not matter how much people disagree on a specific format because everyone can have a view that suits their preferences and because nph presents a view rather than restructuring the original code it makes it easier to maintain library code in the standard 'library' view.
Possibly more of a challenge than you were looking for.....
What you are learning is that nph should not be enforcing a style but rather a view. i.e. nph can take nim however it is written and then present it in the ide in a format preferred by the user.
I'd recommend https://prettier.io/docs/en/option-philosophy to better understand what nph aims to achieve.
The IDE of a single developer is but one place where code lives - nph solves a different problem than you seem to be thinking about.
Since 0.3, nph changes
let x = [long expression that takes multiple lines
to
let
x = [long expression that takes multiple lines]
What is the point of this? It just seems to take up more space without any apparent benefit.