马上注册,结交更多好友,享用更多功能^_^
您需要 登录 才可以下载或查看,没有账号?立即注册
x
本帖最后由 鱼C-小师妹 于 2020-10-27 17:08 编辑
各位师兄好,在下就是 B 站上小甲鱼老师说的小师妹(传送门)
是一名标准程序媛(希望不要脱发),负责 Web 开发,会 Python,对精通 C 的程序猿兄弟有格外好感
好多人都在 B 站给偶留言,小师妹是单身,欢迎来追
不过呢!
你们至少代码得写得美如画吧~
正好放假宅在家,总结总结自己对规范代码的一些看法,欢迎各位童鞋一起讨论。
这些好习惯如果你能养成,对于像我们这样的程序媛来说,超级加分!
给变量、函数取个好名字
ITWorld 曾经发起了一个”程序员最头疼的事情“投票,结果非常有趣,近半数的程序员认为命名是最头疼的事情。
规范的命名对于阅读程序是如此重要,本文开篇就不得不提到它。
在阅读代码时,理解一个变量和函数都是从名字开始的。
它是什么?
它的职责是什么?
这些问题从名字就应该看出来,如果名称还需要注释来补充,那就不算是个好名字。
例如:
毫无意义的一个名字对吧,可以使用驼峰法将其写清楚:
一目了然,知道这个变量保存用户电话号。
宁可名字取长一点,也不要起个模糊的名字!
一个清楚的变量名还会带来可搜索的好处。
即使在写二分算法时,也尽量别用 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[0]=1,f[1]=1
for(i in 2..N){f[i]=f[i-2]+f[i-1]}
return f[N]
}
风格二:
fun fib(N : Int) : Int{
if(N == 0) return 0
val f = IntArray(N+1)
f[0] = 1
f[1] = 1
for(i in 2..N){
f[i] = f[i-2] + f[i-1]
}
return f[N]
}
作为连口红都会买一大堆的生物(小仙女),猜我喜欢那种?
没错!
同样的代码,仅仅是加上空格与缩进就能看起来更美观。
现代化的 IDE 都有代码格式化快捷键,在代码敲完后随时格式化。
并去掉多余的空行,是一个让代码保持美观的好习惯。
先想通逻辑,再写代码
不知道你们听说过“斐波那契程序员”嘛?
没听过的话,就要打屁屁啦。
哈哈,上面的代码是斐波那契数组发现了吗,这个称呼其实有点“真实”。
说的是:
哈哈哈哈哈,是不是很真实呢!
你是否有过这样的经历:
在敲代码之前,先问自己一个问题:
我写下的这行代码是真的能用上的吗?会不会有逻辑漏洞?
思考清楚业务流程之后再写代码,往往事半功倍。
以自己亲身经历过的一个项目为例,项目已经做了半年, 抛开第三方库。
代码量共有两万行,平均算下来,每天只需要写 100 行代码。
这样看来,每一天都差不多是”很闲的“,然而现实是每天都忙得不得了!
从早到晚都在码代码。
这些代码量如果纯粹敲出来,最多十个小时就可以完成。
我们应该用大部分的时间思考代码逻辑,不要花大量时间将代码删了又写,写了又删。
磨刀不误砍柴工,事先做好全面的考虑,争取让写下的每一行代码都有价值。
梳理代码逻辑是有一定方法的,记得小甲鱼老师有讲过。
这里只列关键点:
- 通过画图工具先将逻辑画出来,流程图、UML 图、时序图、思维导图都能对你有所帮助。
- 写接口之前先模拟出假数据,测试逻辑层没有问题之后再写接口,可以避免写出的接口不合适。
- 善于写伪代码,将程序需要实现的每个步骤先用抽象的伪代码写出来。具体实现时再将伪代码细化。
- 写代码之前先编写测试用例,将你期望的输入输出写在测试用例中
总之水平越高的程序员花在设计的时间就会越长。
勇于重构
推倒重来!
敢不敢?!
女朋友超讨厌,敢于说分手吗?!
程序员应该保持爱折腾的习惯!
不安于现状,才能做到与时俱进。
软件之所以叫软件,正是因为它是”软”的,需求随时在更新!
上星期的代码放在今天也许就不再合适。
也正因为软件是软的,我们可以很方便的通过重构改进它。
只要有良好的测试用例,就大胆的重构吧!
如果你遇到下面列出的点,敬请重构:
- 当你需要添加一个新功能,突然发现程序耦合严重,导致新功能不是那么好添加,那就先将程序重构到可以方便的添加新功能
- 当你阅读代码时,发现程序可读性低,导致理解上的困难,显然代码还不够清晰,先将其重构到一眼能够看出结构。
- 你找到一种更好的实现方式,千万不要因为现有的代码仍然可用就置之不理。尝试将你的想法实现出来。即使失败了,你也会更能理解为什么代码是现在这个样子。
推荐 Martin Fowler 大神写的书:《重构改善既有代码的设计》,软件开发不朽的经典。
备份
还记得这个搞笑而又心酸的 gif 嘛:
如果程序中用到数据库操作,一定要记得定时备份!
数据库备份有诸多好处:
而且它并不需要太多的成本,只需要写个脚本完成定时自动备份,并删除过老的备份数据即可。
如果数据库没有做备份,而数据库又被误操作删除了的话,那就是上面 gif 里的话。
同样,代码也需要及时备份,使用版本管理系统可以解决这个问题。
用上 Git,随时 commit,丢失代码的情况几乎不可能发生。
讲究的 README
全球最大的男性同性交友平台 github上有非常多的好项目,无一例外,他们都有一份完善的 README。PS:其实小仙女也是会去哒
README 是程序的门面,有助于别人及时发现你写的好项目。
(不要奢望每个人都有闲情逸致来阅读你的源码)
况且 README 文档的好处不止于此,它还可以帮助自己梳理逻辑,理清思路。
写好 README 之后,随着项目的演进及时更新它,不会花太多时间!·
但能让你随时都对项目有个整体的把握。
绝对值得一试。
代码注释也是同样的道理!
如果喜欢,别忘了评分
|