You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
JSON specifically doesn't allow for comments, since it's designed for data transfer not for configuration, and c8 crashes if the config file has any. This is currently expected, but isn't preferred.
Possible alternatives:
JSONC: Just JSON, but adding syntax support for C/C++ style comments. Probably the simplest fix as it merely involves either changing out JSON.parse for a library that supports comments in JSON or by DIY'ing it by pre-filtering the file contents,. though I DO NOT recommend that latter approach. This might need to be handled via also allowing the file to have the extension jsonc so that editors figure it out too.
YAML: used extensively by many projects, including nyc. Grammatically similar enough to JSON that there's almost no impedance mismatch.
This tells us nothing of the goals of the project or why things are the way they are vs the following, nor does it allow for easy in-code tracking of what needs to be changed:
{// 80% minimums per company standards."branches": 70/* TODO: Increase to at least 80 ASAP, was set to match status quo when coverage checking was added to the code. */,"functions": 75/* TODO: Increase to at least 80 ASAP, see above for why. */,"lines": 80,"statements": 80}
Yes, you can argue that issues should be tracked in an issue tracker and that historical notes could be handled by reviewing the comments in the git history. I agree, however there's nothing like having the problem noted and in your face every time you look at the relevant block of code. Or if you are on a jet disconnected from the internet and want to fix some low hanging fruit.
The text was updated successfully, but these errors were encountered:
JSON specifically doesn't allow for comments, since it's designed for data transfer not for configuration, and c8 crashes if the config file has any. This is currently expected, but isn't preferred.
Possible alternatives:
JSON.parse
for a library that supports comments in JSON or by DIY'ing it by pre-filtering the file contents,. though I DO NOT recommend that latter approach. This might need to be handled via also allowing the file to have the extensionjsonc
so that editors figure it out too.Consider the following:
This tells us nothing of the goals of the project or why things are the way they are vs the following, nor does it allow for easy in-code tracking of what needs to be changed:
Yes, you can argue that issues should be tracked in an issue tracker and that historical notes could be handled by reviewing the comments in the git history. I agree, however there's nothing like having the problem noted and in your face every time you look at the relevant block of code. Or if you are on a jet disconnected from the internet and want to fix some low hanging fruit.
The text was updated successfully, but these errors were encountered: