命名规范
取名过于简单，无法清晰表达含义。
可能在自己编写代码的时候可以理解，但是别人第一眼看到这样的命名时，是完全不知道它具体表达了什么含义的，很难阅读。
// 单字符，剪短单词作为变量名 let flag = false; for(f in markedFiles){ //handler each marked file }
命名风格不一，影响代码阅读
他们都是对判断性函数的命名，但是使用了不同的命名风格。
我们应该尽量养成一个固定的命名思路或者命名风格。
//多种风格的方法名 isProcessRunning() checkIfPageClosed()
建议
- 可以适当参照
现有代码的命名风格。 命名要能够清晰展现有关的含义(好的命名的基本要求)
-较长而清晰的命名优于简短而模糊的命名，不要过于追求简短。
-为一个好的命名花费的思考是值得的。- 命名技巧学习：
-多阅读书籍、教程、知名源码等等，学习命名思路和技巧。
注释不合规
修改代码不更新注释,造成误导
//do something about A Function() { // do some actions about B }
无意义的注释(如日志型注释,废弃的代码)
这类注释对于代码逻辑没有任何的理解上的帮助，相反还增加了篇幅，随着现代项目管理工具越来越强大，已经不需要了。
/* * Date: 1 Jan * Author: Hy * Change: Update this function for fixing bug : ... * ........ */ Function(){ /* OldFlow(); */ NewFlow(); }
过多篇幅的注释
别人不一定有耐心去读我们的注释，如果代码不够清晰，注释再多，也不利于后期的修改和维护。
所以过多篇幅的注释出现在了我们代码中，我们要考虑是不是可以让代码更清晰
/* multi-lines */ Function(){ ...... }
建议：
- 避免写出
坏注释：
-不达意的注释
-含有误导的注释
-与逻辑无关的注释 及时更新注释清晰的代码是不需要太多注释说明的
函数封装和复用
不使用团队封装的工具库，自己重新实现
公司封装这些工具库、组件的目的是让所有人使用或调用的时候可以在同一个规范上使用同样的代码，便于后续问题的排查，保证我们代码的质量。
自己重新实现容易带来一些阅读、后期维护等问题。
函数过长，缺乏提炼
Function() { // do A ... // do B ... // do C ... ... }
三次及以上重复代码不做复用
重复两次时可做可不做，一旦到达三次，一定要封装。
修改公共库时只考虑到自身业务逻辑
只顾及自己的业务实现，不兼容他人使用场景。
建议：
使用组件时，先看看是否被团队进行过封装。- 按照职责设计和提炼函数,尽量做到
函数单一职责 - 相同逻辑的代码
积极复用
不合理的变量定义
变量定义不考虑解耦
例子中，此种域名如果我们定义多个，就没有做到解耦以及复用
//方法体中的整型/字符串定义 let loginUrl = "www.xxx.com/login" let helpUrl = "www.xxx.com/help"
根据使用场景判断是否应该动态生成内容
const systemPath = "C:\";
例如Windows的操作系统一般是C盘，但这个可以手动更改
如果代码中我们设置为C盘，那后续如果用户本身系统盘并不是C盘，那就会出问题，应通过API或其他方式进行获取、
