写男主重生做网站的小说,美声广告网站建设,厦门网站建设xm37,网络网站建设的意义我最近关注到有的项目使用JSON作为配置文件。我觉得这不是个好主意。 这不是JSON的设计目的#xff0c;因此也不是它擅长的。JSON旨在成为一种“轻量级数据交换格式”#xff0c;并声称它“易于人类读写”和“易于机器解析和生成”。 作为一种数据交换格式#xff0c;JSON是…我最近关注到有的项目使用JSON作为配置文件。我觉得这不是个好主意。 这不是JSON的设计目的因此也不是它擅长的。JSON旨在成为一种“轻量级数据交换格式”并声称它“易于人类读写”和“易于机器解析和生成”。 作为一种数据交换格式JSON是很好的。人类可以相对容易地读取和写入它并且对于机器来说也很容易解析尽管存在一些问题。 这是机器可读和人类可读之间的一个很好的折衷对于许多用例来说它是对XML的一个很好的改进。 使用它用于其他目的有点类似于说“嘿这个锤子工程真的很好驱动钉子我爱死它了为什么不用它把这个螺丝钉钉进去呢“当然它有点工作但它不是工作的工具。 到目前为止最大的问题是你不能在JSON中添加注释。偶尔的JSON解析器支持它但大多数都不支持而且它不在标准中。出于充分的理由JSON中明确删除了注释支持。 有很多原因您要添加注释文档设置设置为值的原因、添加助记符或描述注意事项、警告过去的配置错误、在文件本身中保留基本的ChangeLog或者只是在调试时注释掉一个部分/值。 一个建议的解决方法是使用新密钥例如{comment: a comment, actual_data: ...}这让我觉得这样很实用。
还有人已经指出你可以使用提交日志但是谁会仔细阅读提交历史记录如果有一些重要的信息隐藏在其中呢 一些JSON方言如JSON 5、Hjson和HOCON添加了对注释的支持一些JSON解析器也是如此。这很好我鼓励你使用它但它不再是JSON而是JSON方言。这篇文章是关于JSON而不是JSON方言。 我还发现JSON的UX对于手工编辑来说是次优的你需要在后面加上逗号引号的语义很烦人而且它缺乏使用多行字符串的能力。这些属性对于JSON的预期用途来说很好但对于编辑配置文件来说就不那么好了。可行吗当然可以了。好玩吗不我不知道 我也不觉得它特别可读因为它遭受了过多的引用和其他语法噪音我坦率地承认这是一个品味问题。 JSON是一种声明性配置语言。声明性配置DC对某些问题很有效但对其他问题就不那么有效了。特别是使用DC来控制逻辑通常不是一个好主意。
促使我写这篇文章的是MediaWiki的新扩展系统。旧系统使用一个简单的PHP文件来连接核心MediaWiki代码加载所需的依赖项等。这在新系统中被替换为JSON文件。这样做所失去的是在与其他插件或其他逻辑的兼容性方面聪明的能力。
它的实现也要复杂得多以前它只是 require(plugin/foo/plugin.php); 现在它需要解析JSON文件并处理其中的内容。这要复杂得多因此更难调试。
虽然使用JSON文件作为基本元数据是有意义的更容易解析和显示在网站上但使用它来描述代码的工作方式让我觉得这是对DC的滥用。毕竟这就是代码的作用。 很多人问我该用什么。这不是一个容易回答的问题因为它取决于您的用例、编程语言、库环境和社会因素。没有一个“正确的答案”也许只有“最简单的满足你所有要求”。我写了一篇关于这件事的文章。
一个好的替代方法可能是只使用命令行标志。
有一些JSON方言是专门为人类编辑设计的JSON5、Hjson和HOCON。所有这些看起来都是常规JSON的合理提升尽管我自己还没有使用过它们中的任何一个。JSON5似乎是一个很好的替代方案因为它对JSON的更改最少。
我不太愿意提出其他的替代方案因为我还没有对所有格式除了YAML做过深入的评估;仅仅浏览一下规范潜在的缺点可能并不明显YAML是一个很好的例子有很多微妙的行为。我真的没有时间-或兴趣-对所有的替代方案进行全面深入的审查。
