在node.js中的Snake_case或camelCase

所以我有node.js应用程序公开一些API到客户端,并连接到一些SQL数据库。 首先介绍一些前提:

  1. 客户端必须使用snake_case API(请求正文中发送的JSON对象中的键在snake_case中)。
  2. 数据库列名也是snake_case

问题是因为JavaScript标准/惯例正在使用我想保留的camelCase

所以我看到有3个解决scheme:

  1. 根据需要,将蛇(API)中的数据转换为骆驼(应用程序)以实时(蛇)数据库。 这会给系统带来一些新的层面,所有这些都不会比其他解决scheme复杂。
  2. 在node.js应用程序中使用snake_case。 但是不pipe是否使用蛇,我所使用的所有其他的依赖关系仍然是在解决整个问题的骆驼。
  3. 在node.js应用程序中混合使用snake_case和camelCase。 这是我想避免的:)

所以你有什么build议? 我最喜欢的是第一个解决scheme,但如果你有其他一些聪明的想法没有提到这里请随时告诉:)

谢谢,伊万

正如奥卡姆的剃刀原理所说,最简单的解决scheme是最好的解决scheme。

如果你一方面有客户的需求,另一方面是node.js代码风格指南 。 我会采取最简单的解决scheme来满足这两个。 外部的API应该是蛇的情况,在内部你可以使用骆驼的情况。 如果你坚持一致,你可以在任何地方使用蛇情况,因为我认为客户的要求具有更高的优先级。

我真的会避免任何额外的层次来转换案件,因为它会给最终的解决scheme带来额外的复杂性,可能会有额外的错误,并且将来还需要额外的维护。

就个人而言,当我必须在JavaScript中处理蛇情况时,我只用方括号来使用它:

data['user_id'] = 1; 

所以,从技术上讲,我不违反任何风格规则:这些只是string,而不是标识符

问题是因为JavaScript标准/惯例正在使用我想保留的camelCase。

没有这样的标准做法。 这取决于一种风格。 Node.js本身使用骆驼的情况下,我们内部坚持一个蛇案,因为它更可读。 随便你怎么做。

但是,如果你的API使用蛇的情况下,它是自己坚持蛇案的非常好的理由。 所以我build议坚持select2。

选项1没有问题,因为使用不同风格的SAME标识符容易出错。 选项3是有点可以接受的。