Nodejs项目中如何权衡驼峰写法与SQL下划线写法的语言规范？

Nodejs项目中如何权衡驼峰写法与SQL下划线写法的语言规范？

作为一个强迫症患者，想两方面都满足…

我目前找到的这些方法：

  • 用 sequelizejs 这类 ORM ，在 ORM 内部实现驼峰与下划线之间的转换
  • 在语言内部用驼峰写法，然后涉及到下换线的地方都用 data['user_id'] 的形式

我个人是倾向于第二种方式的，不知道大家会怎么权衡？

42 回复

弱弱的问一句。为啥你的主题背景是全黑色的呢


node.js 下的节点都是这样的

这是 Node.js 节点的主题吧

语言规范是驼峰写法， python 表示不服

综合一下，
Fuck_Variable_1

所以我发到了 Node.js 节点…

这表情的背景好违和啊

V2EX plus 提供的表情在 Node.js 节点下都好违和

我感觉 语言规范什么的 都是为了让代码看起来更舒服更顺眼 所以我选择看起来更直观我看着也顺眼的“（大）驼峰式”
e.g. : UserName

因为总感觉“小驼峰式”看起来很奇怪 => userName

我司要求数据库命名用驼峰法，找谁评理去？

写惯了 Java ，现在变量命名都在用驼峰写法。

9 楼说的大驼峰式估计是 C# 带出来的吧


但这种形式的话，在 SQL 里面查询就要带上引号拉， SELECt “UserName” FROM Users;
这也是我纠结的一部分。

用了驼峰基本上都会用上 ORM 吧？

我们后端是 Python ， PEP8 规范，下划线命名好嘛！！！！

推荐一个带转换的 ORM ， https://github.com/XadillaX/Toshihiko

mybatis 一句配置完美解决

团队用什么就用什么，没什么好纠结的。
个人？那还不够你牛逼的。。随便搞。。反正只有自己看

咦， python 后端的话数据库用下划线命名很自然啊…还驼峰就搞不懂了

各种实体类转 SQL 语句,table 转实体类的工具都能自动转换吧

因为我喜欢用长名字，所以都用驼峰法，下划线太占地方了

下划线 lint 不会报错？

可以设置 linter 的规则啊…

node 直接搭配 mongodb 和 redis 吧，全驼峰不用管 mysql 下划线了，自动转驼峰其实挺烦人的，比如 vue 的组件名称

不是 C#带出来的，从入门编程开始我就感觉大驼峰顺眼 😂 所以不管什么语言我一般都这么命名。话说我写.Net 的时候 ReSharper 还一直提示我把大驼峰改成小驼峰，讨人嫌弃哈哈。

这就是我不喜欢 django 的原因，作为 Python 框架居然用着驼峰命名法

写好的驼峰看起来很舒服

如果是数据库字段变量就下划线，其他驼峰。

Django 哪里用到了驼峰？想不出来

数据库习惯表名小写，字段大写+下划线

我感觉驼峰写法好看，个人见解

驼峰写起来舒服啊。。。小写字母后面的基本靠自动补全，下划线明明还要打下划线。。。

如果是工作中的代码，肯定要按公司的规定来。如果是个人项目，喜欢怎么写就怎么写，我现在还用老掉牙的匈牙利命名法呢。

Resharper 应该是推荐用大驼峰的，估计是你记错了。。

我们的 dba 牛逼呗，不符合命名规范不让上线哦

前端如果对后台返回的数据中变量格式不爽的话，可以用 humps ，。
> humps - Underscore-to-camelCase converter (and vice versa) for strings and object keys in JavaScript.

因为这个表情不是透明的 233

不清楚是你们用什么样的技术栈， 但是：
1. sql 一般不区分大小写
2. 开发语言里不宜嵌入另一种语言， 如字段名不应该在开发语言中出现
3. 推荐 ORM 自动转换

Haskell 严格区分两种驼峰式😂😂😂

js 写数据传递都是下划线，当然参数命名都是驼峰。规范这个东西只要有个自己遵守的标准就行吧~

我觉得这个是有原因的， Java 里没有 Property 的概念，属性都是用 Getter/Setter 方法实现的，那么命名的时候都有个动词， getUserName/setUserName ，我觉得这样显然小驼峰比大驼峰好看多了。至于微软系的，完全没有必要弄个 GetUserName 的方法去设置属性，而单独的用 UserName = “xxxx”，比小驼峰好看多了。 Java 的方法名和老太太的裹脚布一样，又臭又长，我第一个看 Structs 的类名都蒙了， xxxxAndxxxxx 这个鬼名字都来了，都可以直接当作文档来看。通常 Java 方法名都是以一个动词开头然后接着名词，而 C#一类的几乎就是直接一个名词，或直接一个动词就没了。

参考 Java 引入 DO 层，这个问题就很好解决了。

在Node.js项目中，处理驼峰写法（camelCase）与SQL下划线写法（snake_case）的语言规范时，可以通过一些策略来权衡，确保代码的一致性和可读性。

1. 数据库模型映射

使用ORM（如Sequelize）时，可以在模型定义中明确字段的映射关系。例如：

const User = sequelize.define('User', {
  userName: {
    type: Sequelize.STRING,
    field: 'user_name' // 数据库中的字段名
  },
  // 其他字段
}, {});

2. 中间件转换

在Express应用中，可以使用中间件在请求和响应之间进行字段名的转换。例如，使用express-camelcase中间件：

const camelcaseKeys = require('express-camelcase');

app.use(camelcaseKeys()); // 将请求体中的下划线写法转换为驼峰写法
app.use(camelcaseKeys('response')); // 将响应体中的驼峰写法转换为下划线写法（可选）

3. 统一API文档

无论选择哪种命名规范，都应在API文档中保持一致。使用Swagger等工具可以自动生成文档，并确保前后端开发人员都遵循相同的字段命名规则。

4. 代码风格指南

在团队内部制定并遵守代码风格指南，明确数据库字段名、变量名、函数名等命名规范。这有助于减少沟通成本，提高代码的可维护性。

通过以上策略，可以在Node.js项目中有效地权衡驼峰写法与SQL下划线写法的语言规范，确保代码的一致性和可读性。

回到顶部