这是一个创建于 2365 天前的主题，其中的信息可能已经有所发展或是发生改变。
最近在公司写一些业务代码，功能虽然实现了，但是感觉自己写的代码很乱，过几天再去看可能自己都看不懂了更别说别人去看你的代码。各位有什么建议
 |
1
susecjh 2018-05-31 12:09:30 +08:00
公司代码有要求吧，比如我和外面的人做开源项目，代码怎么写，文件怎么放都是有严格的要求的
|
 |
2
eroko 2018-05-31 12:14:57 +08:00
为了防止自己忘，多写点注释呗
|
 |
3
qsnow6 2018-05-31 12:18:39 +08:00 via iPhone
多写点垃圾代码
|
 |
4
TheSpectre OP @qsnow6 别秀了
|
|
5
TheSpectre OP @susecjh 好多都是之前留下来的坑，现在一个一个补
|
|
6
susecjh 2018-05-31 12:46:29 +08:00
没有代码审查吗
|
 |
7
lamada 2018-05-31 13:07:48 +08:00
写注释
|
 |
8
recall704 2018-05-31 13:22:19 +08:00
重构
|
 |
9
Immortal 2018-05-31 13:27:41 +08:00  1
写代码和写作文没差别 都是写完一遍遍的在修改 慢慢才会使得整个项目质量提高
大佬和菜鸡的区别只是在于大佬写完后需要改的次数少,菜鸡的多而已 |
 |
10
boris1993 2018-05-31 13:31:05 +08:00 via Android
多写注释
去看看各种最佳实践 |
 |
11
kslr 2018-05-31 14:03:58 +08:00 via Android
不停的重构，晚上思考下业务逻辑优化。
|
 |
12
likuku 2018-05-31 14:07:45 +08:00
单元测试+重构，循环往复。
|
 |
13
yanaraika 2018-05-31 14:08:57 +08:00
无他，唯手熟尔
|
 |
14
Pyjamas 2018-05-31 14:10:21 +08:00
感觉自己写的代码很乱，可是到底是哪里乱呢，为什么乱呢，你觉得清晰的代码应该是什么样的
|
 |
15
zdcin 2018-05-31 14:18:38 +08:00 1
最小作用域
方法，属性，局部变量的作用域设定都应该遵守这个原则。 作用域越小影响的范围越小，出错的可能性越小。 对于应该设为私有的模块方法，模块变量，类方法，类变量，要加前下划线，但不要有后下划线，避免与语言内置的方法和变量冲突。 模块化 不要将代码过于集中，避免一个文件过度膨胀 减少副作用 无副作用是指一个方法执行过程中和执行之后都不会改变外部环境，无副作用的方法任何时候调用，只要输入确定，输出就不会改变。线程安全问题就是因为副作用引起的，有副作用的方法越少，程序越简单，越不容易出错。 使用合理的数据结构 list，set，dict，queue 都有自己的特点，要根据算法特点使用合适的数据结构，比如从一些名字中找重名，就不该用 list，而是用 set。 |
 |
16
yuanxj1024 2018-05-31 14:41:15 +08:00
尽量函数化，保证函数单一职责的原则，每个函数代码行数都不多，加上合理的函数命名，消灭大块代码
|
 |
17
wupher 2018-05-31 14:52:11 +08:00
多写
多看别人写 多让别人看你写 |
 |
18
tujin 2018-05-31 17:19:54 +08:00
写注释
|
 |
19
ben1024 2018-05-31 17:23:03 +08:00
多写
|
 |
20
noNOno 2018-05-31 17:24:56 +08:00 2
分享 wangyin 的编程的智慧-.-
http://www.yinwang.org/blog-cn/2015/11/21/programming-philosophy |
|
21
TheSpectre OP @noNOno 谢谢
|
 |
22
kinghui 2018-05-31 19:36:24 +08:00
把下面基本书多撸几遍
- 《程序员修炼之道：从小工到专家》 - 《重构：改善既有代码的设计》 - 《代码大全》 - 《代码整洁之道》 - 《设计模式》 |
|
23
kinghui 2018-05-31 19:40:14 +08:00
《代码整洁之道》里有提过，如果代码需要注释那就说明代码表达力不够，而且注释很容易不跟随代码更新从而误导读者（有可能是你自己）。如果你要为某段代码添加注释那么就应该考虑是不是应该换个名字或使用更加富有表达力的代码，如提取到单独的方法并起个好名称。
|
 |
24
cxbig 2018-05-31 20:18:59 +08:00
多写多练
备注写清楚就不会忘记代码是干什么的 至于结构的规划，是写一个方法做所有的事情还是写一堆可重用的库、应用层只做配置和调用，全凭经验积累。 |
 |
25
Foolt 2018-05-31 20:51:23 +08:00
@kinghui 表达力再好，几万行的项目里不可能没有注释，尤其是补丁类代码，不写注释后人翻半天才知道你这到底干嘛用，这种情况下阅读代码比翻阅屎山还恶心。
|
|
26
Foolt 2018-05-31 20:55:18 +08:00
最重要的是按编程规范写，PHP 比较流行的编程规范是 PSR 规范；
其次是鼓励冗长的命名，避免用缩写，如果非要缩写一定要在注释写出完整名称； 最后是不要忘了写注释，注释又长又臭没关系，不影响工作进度就可以。 |
 |
27
night98 2018-05-31 21:37:35 +08:00
@kinghui #23 要么变量名全称，否则不用注释真的看起来很难受，尤其类似 redis 缓存命名这种，不看注释你都只能靠猜。
|
 |
28
page470075640 2018-05-31 21:53:59 +08:00 via Android
一颗迭代的心
|
 |
29
qloog 2018-05-31 22:00:33 +08:00
命名一定要有意义，这样后期看起来就不那么费解了。
|
 |
30
monkeylyf 2018-05-31 22:03:36 +08:00
追求美
|
 |
31
misaka19000 2018-05-31 22:29:39 +08:00
重构，多思考，把组件按模块进行划分
|
 |
32
woscaizi 2018-05-31 22:32:59 +08:00 via iPhone
如果时间允许，多次重构。
|
|
33
kinghui 2018-06-01 10:01:20 +08:00
|
 |
34
429463267 2018-06-01 11:14:21 +08:00
|
Select Language