![](https://developer.qcloudimg.com/http-save/yehe-1209475/18bf0bd4c0fac3cfaa66dce37002ead4.jpg)
## 一、前言


你好，我是喵喵侠，一名前端开发。

当了这么多年程序员，我发现一个有趣的现象——写代码其实不难，难的是**保持良好的编程习惯**。同样的需求，有人一天写完，后续维护一地鸡毛；有人两天写完，半年后依然稳得像山。区别往往不在技术，而在习惯。今天我想分享一些我在日常工作中养成的好习惯，希望能给你一些启发。

### 二、好习惯分享


### 1. 开始写代码前，先想清楚实现思路


拿到需求时，我不会立刻打开编辑器。

我会先问自己三个问题：


- **这个功能的核心流程是什么？**

- **哪些逻辑是可复用的？**

- **会不会影响现有模块？**


比如做一个多选筛选框功能，很多人第一反应是直接写事件绑定逻辑。但我会先想，这个功能以后会不会复用？是否可以抽象成一个组件？如果上游和下游是联动的（例如“省份”选择影响“城市”选项），那我就提前规划数据流和依赖，避免后面返工。

这种“写前先想”的习惯让我在后期重构时几乎不用推翻逻辑，只需要微调实现。

### 2. 代码一定要有注释，尤其是“非直观逻辑”


注释不是给别人看的，是给**未来的自己**看的。

我有过一次血的教训——三个月前写的逻辑，三个月后我完全看不懂。那一刻我深刻体会到注释的价值。

我一般遵循以下三条规则：


- **解释“为什么”，而不是“做了什么”**。
	比如下面这样写：
	```
	// 根据上一个下拉框的选项动态请求下一级数据（省市联动）
	watch(selectedProvince, async (val) => {
	  cityList.value = await fetchCityList(val)
	})
	```
	而不是：
	```
	// 监听省份变化
	```
	因为后者虽然准确，但没有告诉未来的自己“为什么要监听”。

- **写 TODO 时加具体说明**
	不要只写 `// TODO: 优化`，而要写清楚**优化方向或原因**。
	例如：
	```
	// TODO: 这里后续要加防抖，否则快速点击会导致重复请求
	```

- **为枚举值、接口返回做注释**
	比如一个 tab 切换逻辑：
	```
	// tabType: 1-实时监控，2-历史记录，3-报警日志
	const tabType = ref(1)
	```
	这种注释让别人立刻明白每个数字代表什么，不用翻文档。


----

### 3. 养成规范命名的习惯


命名是最容易被忽视、但最能体现思维清晰度的细节。

我给自己的原则是：**能让别人读懂逻辑，不需要解释。**

例如：

```
const userList = ref([]) // 所有用户列表
const selectedUserIds = ref([]) // 当前勾选的用户ID
```
而不是：

```
const list = ref([])
const check = ref([])
```
这种命名虽然短，但完全丢失了语义。

我喜欢在写函数时也保持一致，比如：

```
function fetchUserDetailById(id) { ... }
function validateFormBeforeSubmit() { ... }
```
一眼就能看出“做什么 + 针对什么”，比 `getData`、`doCheck` 清晰太多。


----

### 4. 代码 Review：及时、客观、带思考


我习惯在每次发完版本后做一次自我 review。

很多人觉得 review 是团队行为，但我认为**自检同样重要**。

我会浏览一遍 diff，看看有没有临时写的测试代码忘删、命名是否一致、逻辑是否能抽取为函数。

有时候我还会写上复盘注释，比如：

```
// REVIEW: 下次类似接口请求可以抽成 useFetch Hook
```
这样未来有类似功能时，我能回头看到自己的思考过程，持续改进。


### 5. 写文档，不是加班行为，而是沟通捷径


我遇到过最典型的场景是：别人接手我的项目，一脸茫然地问“要怎么跑起来？”

从那以后，我都会为每个项目写一个简单的 `README.md`，内容包括：


- **项目简介**：干什么的

- **启动命令**：`npm install && npm run dev`

- **配置项说明**：环境变量、依赖 API

- **注意事项**：例如接口限频、版本兼容等


我甚至会在复杂逻辑的模块里写一份简短的说明，比如：

```
/**
 * 表单验证逻辑
 * 1. 用户名：不能为空
 * 2. 密码：需包含大小写和数字
 * 3. 手机号：正则校验，错误提示“请输入正确的手机号”
 */
```
这样的文档和注释结合，别人接手几乎不用问问题。


### 6. Git 提交信息要规范


Git 提交日志是团队协作的“时间线”，混乱的 commit 会让人抓狂。

我坚持用简洁的格式，比如：

```
feat: 新增用户信息导出功能
fix: 修复表单验证错误提示未显示的问题
refactor: 抽离通用请求封装
docs: 更新README项目说明
```
好处是两点：


- 看 changelog 就能知道这次版本改动范围

- 回滚或 cherry-pick 时能更精准地定位提交


如果一次提交改动太多，我会拆成多次 commit，保持单一职责，方便日后追溯。



### 7. 表单验证：提示语要友好


表单错误提示往往决定了一个产品的“温度”。

比如，不要写：

>“手机号格式错误”


而是写：

>“请输入正确的手机号（11 位数字）”


甚至可以加点贴心提示：

>“请输入常用手机号，用于接收验证短信”


这种细节能提升用户体验，也让前端代码更贴近“产品思维”。



### 8. 删除无用代码，而不是注释掉


我以前常常把旧逻辑注释起来“以防万一”，结果两个月后我根本不敢动那坨注释。

现在我改成直接删掉，如果真的怕丢，就让 Git 帮我记着。

版本控制的意义就是——**敢删敢改，无需保留尸体代码**。



### 三、总结


编程不只是逻辑堆叠，更是一种思维的训练。

良好的习惯能让代码更干净、项目更稳、团队更默契。

我的习惯也在不断演化，但有一点始终没变：

>写出自己半年后依然能读懂的代码。


如果你正在写代码，不妨问问自己：

“半年后的我，看得懂现在这段逻辑吗？”

——如果答案是肯定的，那你已经在走向成熟的开发者之路。

当了这么多年程序员，我发现一个有趣的现象——写代码其实不难，难的是保持良好的编程习惯。同样的需求，有人一天写完，后续维护一地鸡毛；有人两天写完，半年后依然稳得像山。区别往往不在技术，而在习惯。今天我想分享一些我在日常工作中养成的好习惯，希望能给你一些启发。

作为前端开发，分享下我在编程中的好习惯

编程语言

前端

前端开发喵喵侠分享8个提升代码质量的编程习惯：写代码前先规划思路、添加详细注释、规范命名、定期自我代码Review、编写清晰文档、规范Git提交、优化表单提示语、及时删除无用代码。这些习惯让代码更易维护，半年后依然清晰可读。

数据流

短信

国内短信0.038元/条起，接入便捷，稳定可靠


文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

作为前端开发，分享下我在编程中的好习惯-腾讯云开发者社区-腾讯云

作为前端开发，分享下我在编程中的好习惯

作为前端开发，分享下我在编程中的好习惯

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐