网站开发规格如何做百度竞价推广

我最近关注到有的项目使用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是一个很好的例子，有很多微妙的行为）。我真的没有时间-或兴趣-对所有的替代方案进行全面深入的审查。