在此我并不会就具体的命名规范进行阐述，只是就我个人的前端开发经历，谈谈对命名规范的感想。
首先需要说明的是，我从事前端开发的经历不是特别美好，在一个某软的外包干了有四年多，基本都在收拾烂摊子，而且平均每年达到三个以上。入职第一项目是个react项目，已经面临崩溃，整个项目80%的代码集中一个文件里面，基本没有规范可言，面对如此局面基本只能重做了。经过一个月的奋斗总算是完成目标，将正个项目服上正轨，可以正常开发迭代了。虽然说这个过程并不好受，但最后能获得一个较好的结果，得到领导和同事的认可，也算是不幸中的万幸。万万没想的是这只是个开始，当然这就是后话了，现在还是回归正题-命名规范。
写代码的人都知道，要想取好名称并不容易。我们有文件名、函数名、类名、变量名、属性名、字段名等等，如何把他们的名称取得即有区分度又易于理解、见名知意，还不能过长以及拼写正确，这确实是一个不小的考验。事实上，很多开发并不会花太多时间和精力在命名上，都觉得业务都写不完，那有时间浪费在取名上。这样想也是可以理解，毕竟很多公司都要求工作量饱和。这也算是特定环境下形成的开发价值理念。但有句古话说得好，名不正则言不顺。好的命名必然会提高代码可读性，而好的可读性必然会提高代码的可维护性，而项目的维护时间必然比开发时间长。在开发期做好规范，为项目代码打下良好基础，绝对是收益远大于付出（开发时投入时间和精力）的。
不过话又说回来，在一个外包公司，项目又不稳定，刚刚把一个项目整利索了，还没来得及摸鱼呢，就又被安排到另一个项目，所以我为提高项目代码质量所做的努力基本都给别人做嫁衣了。显然这么想太消极了，换个想法：这样的努力要是能影响他人，让他人也写出命名规范的代码，这样传播下去，是不是将来我们遇到垃圾项目的情况就会少很多呢。 偶尔也会自问：你一个干外包多年的人，写个代码哪儿来这么多规矩？可能是遇到太多的垃圾代码，跟他们杠上了，励志要与它们势不两立，统统消灭。哎，人力有穷时，垃圾无止境。愿君且行且珍惜！
二零二二年四月十四日
