OP has a detailed rationale for going with semicolons. Feel free to counter those points, but you can't just dismiss the thing with a "doesn't look right" without any argument.
The first point is addressed in the article; you don't seem to address OP's counterpoint at all.
I don't get the second point: why is that a problem if a semicolon appears in a comment? From what I understand, comments run until the end of the line, so a second semicolon after the first does nothing.
The problem is when a config value includes a semicolon, and the rest of the line gets ignored unintentionally, especially because strings aren't quoted
Ah, I see, so the problem is not a semicolon "used in comments", it's a semicolon used outside them. But then which character would you suggest instead? The article notes that there is the same problem with # (e.g. in `black = #000000`) and // (`url = https://en.wikipedia.com`). And these are arguably more common.
I think this is something in some assembly formats too? I remember seeing it once and wondering if maybe that's where the idea of ending lines in C with semicolons came from since at least in the examples I saw in school, a large number of lines had trailing comments with a description of what the operation was doing.
IDA uses ; for comments in its disassembler view, but it looks like C-style // single-line comments and /* comment blocks */ are also accepted by certain tools: https://en.wikibooks.org/wiki/X86_Assembly/Comments
Comments
Be like:
- don’t mind the peculiarities of formats used for config
- create a format where semicolons denote comments (just… doesn’t look right)
OP has a detailed rationale for going with semicolons. Feel free to counter those points, but you can't just dismiss the thing with a "doesn't look right" without any argument.
Rationale: in the most popular modern langugues it is # or //.
In JS (well, its why we have JSON), it is //. In YAML, it is #.
Moreover - semicolon is a natural character used in comments (unlike // or #). It inferes with our human parsing.
The first point is addressed in the article; you don't seem to address OP's counterpoint at all.
I don't get the second point: why is that a problem if a semicolon appears in a comment? From what I understand, comments run until the end of the line, so a second semicolon after the first does nothing.
The problem is when a config value includes a semicolon, and the rest of the line gets ignored unintentionally, especially because strings aren't quoted
Ah, I see, so the problem is not a semicolon "used in comments", it's a semicolon used outside them. But then which character would you suggest instead? The article notes that there is the same problem with # (e.g. in `black = #000000`) and // (`url = https://en.wikipedia.com`). And these are arguably more common.
What about three simple rules to define comments:
1. If # is in the first column of the line.
2. If # is followed by a space.
3. The # only starts a comment when it’s outside of quotes.
That part looks fine to me, but then again I'm a lisp guy.
I think this is something in some assembly formats too? I remember seeing it once and wondering if maybe that's where the idea of ending lines in C with semicolons came from since at least in the examples I saw in school, a large number of lines had trailing comments with a description of what the operation was doing.
IDA uses ; for comments in its disassembler view, but it looks like C-style // single-line comments and /* comment blocks */ are also accepted by certain tools: https://en.wikibooks.org/wiki/X86_Assembly/Comments