想追我的话，代码写规范了吗？！
本帖最后由 鱼C-小师妹 于 2020-10-27 17:08 编辑https://www.bilibili.com/video/BV1Dc411876M
static/image/hrline/1.gif
各位师兄好，在下就是 B 站上小甲鱼老师说的小师妹（传送门）
是一名标准程序媛（希望不要脱发），负责 Web 开发，会 Python，对精通 C 的程序猿兄弟有格外好感{:10_297:}
好多人都在 B 站给偶留言，小师妹是单身，欢迎来追{:10_264:}
不过呢！
你们至少代码得写得美如画吧～
正好放假宅在家，总结总结自己对规范代码的一些看法，欢迎各位童鞋一起讨论。
这些好习惯如果你能养成，对于像我们这样的程序媛来说，超级加分！
static/image/hrline/5.gif
给变量、函数取个好名字
ITWorld 曾经发起了一个”程序员最头疼的事情“投票，结果非常有趣，近半数的程序员认为命名是最头疼的事情。
规范的命名对于阅读程序是如此重要，本文开篇就不得不提到它。
在阅读代码时，理解一个变量和函数都是从名字开始的。
它是什么？
它的职责是什么？
这些问题从名字就应该看出来，如果名称还需要注释来补充，那就不算是个好名字。
例如：
var test
毫无意义的一个名字对吧，可以使用驼峰法将其写清楚：
var printUserTel
一目了然，知道这个变量保存用户电话号。
宁可名字取长一点，也不要起个模糊的名字！
一个清楚的变量名还会带来可搜索的好处。
即使在写二分算法时，也尽量别用 l 和 r 来指代左右边界，换成 left 和 right 会更好哟~
不过，变量名也并非越长越好，去除变量名中的冗余也是一个好习惯。
Variable 一词永远不应当出现在变量名中，Table 一词永远不应当出现在表名中。
nameString 与 name 没区别，moneyAmount 与 money 没区别...
命名风格应该保持统一，每个概念对应一个词。如果一堆代码中既有 Controller，又有 Manager，还有 Driver，Presenter，就会令人困惑：
他们之间有什么区别？为什么不全用 Controller？
如果同一概念可被多个词语描述，请确定其中一个名字，并在你的代码中一以贯之。
总之，取一个精准的名字是一名优秀程序员的基本功！
从一开始学习编程时，每次取名都应仔细思考，切不可草草了事。
代码美观
先来静静地感受下两种代码风格吧。
风格一：
fun fib(N:Int):Int{
if(N==0)return 0
val f=IntArray(N+1),f=1,f=1
for(i in 2..N){f=f+f}
return f
}
风格二：
fun fib(N : Int) : Int{
if(N == 0) return 0
val f = IntArray(N+1)
f = 1
f = 1
for(i in 2..N){
f = f + f
}
return f
}
作为连口红都会买一大堆的生物（小仙女），猜我喜欢那种？
没错！
**** Hidden Message *****
同样的代码，仅仅是加上空格与缩进就能看起来更美观。
现代化的 IDE 都有代码格式化快捷键，在代码敲完后随时格式化。
并去掉多余的空行，是一个让代码保持美观的好习惯。
先想通逻辑，再写代码
不知道你们听说过“斐波那契程序员”嘛？
没听过的话，就要打屁屁啦。
哈哈，上面的代码是斐波那契数组发现了吗，这个称呼其实有点“真实”。
说的是：
每天都在修复昨天和前天的 bug
哈哈哈哈哈，是不是很真实呢！
你是否有过这样的经历：
代码删了又写，写了又删。
在敲代码之前，先问自己一个问题：
我写下的这行代码是真的能用上的吗？会不会有逻辑漏洞？
思考清楚业务流程之后再写代码，往往事半功倍。
以自己亲身经历过的一个项目为例，项目已经做了半年， 抛开第三方库。
代码量共有两万行，平均算下来，每天只需要写 100 行代码。
这样看来，每一天都差不多是”很闲的“，然而现实是每天都忙得不得了！
从早到晚都在码代码。
这些代码量如果纯粹敲出来，最多十个小时就可以完成。
我们应该用大部分的时间思考代码逻辑，不要花大量时间将代码删了又写，写了又删。
磨刀不误砍柴工，事先做好全面的考虑，争取让写下的每一行代码都有价值。
梳理代码逻辑是有一定方法的，记得小甲鱼老师有讲过。
这里只列关键点：
[*]通过画图工具先将逻辑画出来，流程图、UML 图、时序图、思维导图都能对你有所帮助。
[*]写接口之前先模拟出假数据，测试逻辑层没有问题之后再写接口，可以避免写出的接口不合适。
[*]善于写伪代码，将程序需要实现的每个步骤先用抽象的伪代码写出来。具体实现时再将伪代码细化。
[*]写代码之前先编写测试用例，将你期望的输入输出写在测试用例中
总之水平越高的程序员花在设计的时间就会越长。
勇于重构
推倒重来！
敢不敢？！
女朋友超讨厌，敢于说分手吗？！
程序员应该保持爱折腾的习惯！
不安于现状，才能做到与时俱进。
软件之所以叫软件，正是因为它是”软”的，需求随时在更新！
上星期的代码放在今天也许就不再合适。
也正因为软件是软的，我们可以很方便的通过重构改进它。
只要有良好的测试用例，就大胆的重构吧！
如果你遇到下面列出的点，敬请重构：
[*]当你需要添加一个新功能，突然发现程序耦合严重，导致新功能不是那么好添加，那就先将程序重构到可以方便的添加新功能
[*]当你阅读代码时，发现程序可读性低，导致理解上的困难，显然代码还不够清晰，先将其重构到一眼能够看出结构。
[*]你找到一种更好的实现方式，千万不要因为现有的代码仍然可用就置之不理。尝试将你的想法实现出来。即使失败了，你也会更能理解为什么代码是现在这个样子。
推荐 Martin Fowler 大神写的书：《重构改善既有代码的设计》，软件开发不朽的经典。
备份
还记得这个搞笑而又心酸的 gif 嘛：
如果程序中用到数据库操作，一定要记得定时备份！
数据库备份有诸多好处：
可以防止数据丢失，可以在程序出错时方便数据回滚。
而且它并不需要太多的成本，只需要写个脚本完成定时自动备份，并删除过老的备份数据即可。
如果数据库没有做备份，而数据库又被误操作删除了的话，那就是上面 gif 里的话。
同样，代码也需要及时备份，使用版本管理系统可以解决这个问题。
用上 Git，随时 commit，丢失代码的情况几乎不可能发生。
讲究的 README
全球最大的男性同性交友平台 github上有非常多的好项目，无一例外，他们都有一份完善的 README。PS：其实小仙女也是会去哒
README 是程序的门面，有助于别人及时发现你写的好项目。
（不要奢望每个人都有闲情逸致来阅读你的源码）
况且 README 文档的好处不止于此，它还可以帮助自己梳理逻辑，理清思路。
写好 README 之后，随着项目的演进及时更新它，不会花太多时间！·
但能让你随时都对项目有个整体的把握。
绝对值得一试。
代码注释也是同样的道理！
如果喜欢，别忘了评分
好优秀的小师妹{:10_279:} 不错！ 当然第二种 var printUserTel
这个变量名太长，不喜欢大小写混用的变量名 wp231957 发表于 2020-1-28 12:28
var printUserTel
这个变量名太长，不喜欢大小写混用的变量名
不一定偏用驼峰，自始至终统一就好啦{:10_256:} 不二如是 发表于 2020-1-27 21:47
好优秀的小师妹
还好还好，谢谢管理 zltzlt 发表于 2020-1-27 21:48
不错！
谢谢zlt斑竹{:10_254:} 好棒的程序员姐姐{:5_109:} 我写代码总是很规范的，和小姐姐一样规范 第二种好 {:5_90:} 小师妹我在龙湖等你过来玩哈哈哈 2 2 666666666666666666666666666666666 优秀的小师妹。 如果喜欢干脆和almight，可以选择C语言和asm，我喜欢C语言和asm 写代码的漂亮妹纸，稀有程度应该和熊猫差不多吧。 取名字是最头疼的事了{:10_269:}