Nodejs 写后端 Express API 你们会遵循 换行编写规范吗？感觉换行太多了

发布于 1周前 作者 sinazl 来自 nodejs/Nestjs

因为有一些变量命名很长，导致经常一个 if 条件里面，超过 2 个条件就会被换行掉，导致看逻辑非常乱。

vs code 内置的 pretiter+ 的格式化默认是 80 个字符就换行了。

前端的工程师有时候会修改后端的 api ，结果他们的 vs code 配置，是自动格式化的。

也就是经过他们编辑的文件，全部格式都变了样了。 我是后端的额，看到后面的代码，感觉被格式化之后就无法看了了。。（我自己也用 pretitter+格式化，不过我的换行字符设置到 200 个才换行的）

弱弱问下，这个规模大部分 node.js 的后端工程师都会按照规模编写的吗？
Nodejs 写后端 Express API 你们会遵循 换行编写规范吗？感觉换行太多了


Harmonyos Next教程
14 回复

统一风格就行，没什么好说的


团队协作设定统一的 eslint 规范就可以了

一个项目内的格式化配置文件应该是一样的吧，要么都换，要么都不换，要么都 80 ，要么都 120 ，都 200

团队规范和工程规范问题，每个项目都应该有自己的.prettierrc 配置文件,所有人的编辑器里 prettier 的配置文件路径都设置成一样,比如’./.prettierrc’,所有人的编辑器默认格式化工具都是 preettier. 这样就没问题了.

如果没统一配置 肯定不会轻易动别人格式的…

把 pretiter eslint 统一起来，不让瞎改，特别是多少字符换行，我一般用 160/180

#6 感谢~

prettier+eslint ，增加一些默认的编辑器配置，editorconfig+vscode 之类的，保证工程打开时大家的行为保持一致，最后就是 precommit 时做 eslint 检查，不合规直接 abort 。

OP 头像好评。
我司就没啥统一风格和规范的，我的代码就经常被同事格式化，虽然我不会去格式化他的代码（笑哭）。

nodejs 不是应该由前端工程师开发吗

#10 前端对数据操作太菜，只能由其他后端接手。。

git commit 的时候会触发代码 eslint 检查 和 自动格式化代码 如果不手动跳过的话 基本可以保证代码风格都是统一的

pretiter 过于独断。我是用 eslint 插件，设定行宽 180

在Node.js中使用Express框架编写后端API时，遵循良好的代码格式和换行规范确实能够提高代码的可读性和可维护性。尽管换行可能看起来多了一些，但它们对于组织代码、提高可读性非常重要。

以下是一个遵循换行编写规范的Express API示例：

const express = require('express');
const app = express();
const port = 3000;

// Middleware
app.use(express.json());

// Route handlers
app.get('/', (req, res) => {
    res.send('Hello World!');
});

app.post('/data', (req, res) => {
    const data = req.body;
    // Process data
    res.status(201).json({ message: 'Data received', data });
});

// Error handling middleware
app.use((err, req, res, next) => {
    console.error(err.stack);
    res.status(500).send('Something broke!');
});

// Start server
app.listen(port, () => {
    console.log(`Server running at http://localhost:${port}/`);
});

在这个示例中，每个中间件和路由处理器都独立成块，并通过空行分隔，这有助于快速识别不同的代码段。同时，对于复杂的路由处理器，你可能还需要进一步细化代码结构，比如使用函数或模块来组织逻辑。

总的来说，遵循换行编写规范是良好的编程实践，特别是在团队协作时，它能显著提升代码的可读性和可维护性。

回到顶部