Recently I started to use ruff and yamllint, and these tools share a common feature: there are two space before a comment after some content, instead of one space.
I think that this increase the readability.
I hacked zig.render and was able to make it work.
Example:
// Test 1
const _ = 10; // test 2
One drawback is that this change will generate many diff.
What do you think?
P.S: I’ curious why usually a comment in programming languages is not a token. Does it make the implementation more complex?
I’m not a language designer, but tokenizing is the process of turning source code into a simpler stream of tokens to then parse. since comments shouldn’t affect the program, they can be safely ignored, and including them just adds processing time for no benefit.
I just want to note that Zig does tokenize doc comments and container doc comments, but treats the ordinary kind as whitespace. For several reasons, including that they’re structurally allowed only in certain places, it’s the parser which verifies this, and so they need to be tokens in order to allow that.
The reason I was curious about why a normal comment is not a token is because, looking at the render.Comments function in zig.render, the code seems more complex then I expected.
Of course, since I have never create a tokenizer and parser, I may be wrong.
The problem is not at the tokenizing and parsing level, where the overhead of including comments is modest.
The problem is that comments can be anywhere whitespace is allowed, so use of the parse tree has to constantly look for and ignore comments while trying to find what it really wants to find. That would be a continual sand in the gears. Since doc comments show up in only specific places, and container doc comments in only one place, keeps a slot for them when present and always ignoring that slot is not going to pose the same problems.
So rendering (I’m looking at this code for the first time, but presumably for document generation? Edit: zig fmt looks like) needs to find whitespace which is comments, to put the comments back.
These are almost certainly the right tradeoffs. It also makes life more difficult for someone who wants to do ‘magic string’ things using the Zig parser, and while that’s a mixed bag, magic strings in comments is not a good habit to get into. I do hope Zig gets some annotation capability which isn’t magic string comments at some point, because well, magic string comments are the alternative, and they’re Bad, actually.