这篇文章主要讲了JSON
作为配置文件的缺点:
我最近目睹了使用JSON
作为配置文件的趋势。我认为这不是一个好做法。
这不是JSON
的设计目标,也不是它擅长的东西。
JSON
旨在成为一种“轻量级数据交换格式”,并声称它“易于人们读写”和“易于机器解析和生成”。
作为数据交换格式,JSON
非常好。
人们可以相对容易地读取和写入它,并且对于机器来说解析也很容易(尽管存在问题)。
这是机器可读和人类可读之间的良好折衷,对于许多用例来说,它是对XML
的一个很好的改进。
将它用于其他目的有点类似于说“嘿,这把锤子非常适合驾驶钉子!我喜欢它!
为什么不用它来敲击这个螺丝!“当然,它有点工作,但这是工作的错误工具。
到目前为止,最大的问题是你无法添加评论。偶尔的JSON
解析器支持它,但大多数不支持它,它不在标准中。
有充分理由明确从JSON中删除了评论支持。
您想要添加注释的原因有很多:记录为什么配置中为它们设置值,添加助记符或描述警告,警告过去的配置错误,在文件本身保留基本的ChangeLog
,或者只是注释掉一个部分/
Debug
时的值。
一个建议的解决方法是使用一个新密钥(例如{“__ comment”:“a comment”,“actual_data”:“......”}
,但这让我非常难看。
其他人已经指出你可以使用提交日志,但谁会仔细阅读提交历史记录,那里隐藏着一些重要的消息?
一些JSON
方言 - 例如JSON5
,Hjson
和HOCON
- 添加了对注释的支持,一些JSON
解析器也是如此。
这很好,我鼓励你使用它,但这不再是JSON
而是JSON
方言。
这篇文章是关于JSON
,而不是JSON
方言。
我还发现JSON
的用户界面对于手动编辑来说相当不理想:你需要用尾随逗号来搞定,引用的语义很烦人,而且它缺乏使用多行字符串的能力。
这些属性适用于JSON
的预期用途,但不太适合编辑配置文件。它可行吗?当然。好玩吗?不。我也发现它不是特别易读,因为它有过多的引用和其他语法噪音,我承认这是一个品味问题。
JSON
是一种声明性配置语言。声明性配置(DC
)适用于某些问题,但对其他问题则不太好。特别是,使用DC
来控制逻辑通常不是一个好做法。促使我写这篇文章的是MediaWiki
的新扩展系统。
旧系统使用一个简单的PHP文件来挂接核心MediaWiki
代码,加载所需的依赖项等。这在新系统中被替换为JSON
文件。丢失的是能够巧妙地解决与其他插件兼容或其他逻辑的问题。
它实现起来要复杂得多,以前只需要('plugin / foo / plugin.php')
;现在它需要解析一个JSON
文件并对其内容做一些事情。这要复杂得多,因此难以调试。
虽然使用JSON
文件获取基本元数据是有意义的(更容易在网站上解析和显示),但使用它来描述代码的工作方式对我来说是滥用DC
。毕竟,这就是代码的用途。
很多人都问我有关使用什么的建议。这不是一个容易回答的问题,因为它取决于您的用例,编程语言,库环境和社交因素。除了“最简单的满足您的所有要求”之外,没有单一的“正确答案”。我实际上写了一篇关于它的文章。
一个很好的选择可能只是使用命令行标志。有一些JSON方言专为人类编辑而设计:JSON5,Hjson和HOCON。所有这些看起来都是普通JSON的合理步骤,尽管我自己没有使用过它们。
特别是JSON5似乎是一个不错的选择,因为它对JSON的改动最少。我不愿意提出其他选择,因为我没有对所有格式(YAML除外)进行深入评估;只是看一眼规范可能并不明显潜在的缺点(YAML就是一个很好的例子,有很多微妙的行为)。
我没有时间 - 或者有兴趣 - 对所有替代方案进行全面深入的审查。
原文链接:https://arp242.net/json-config.html
作者:Martin Tournoij
译者:lee