如何写出漂亮的代码? 非正规军应该怎么正规化? 让代码“优雅”起来?

大量的阅读优秀的开源项目，多写，多思考。

先从对优秀开源项目的模仿开始

代码大全 读一遍

Google 代碼風格規範、代碼簡潔之道、設計模式
另外需要好好學英語

先学好英语

java 有阿里巴巴 的 java 开发手册 😘

正规军写优雅是被逼的，老板可以方便的把代码交给未来取代或者淘汰你的人。非正规军有啥优雅不优雅的？注释写清楚了就是好样的，写优雅了给偷你代码的人看吗？

@mamahaha 自己回头看 /复用自己的代码不难受吗......

@mamahaha 问题是写的不优雅，过半年，自己看不懂了，这可如何是好。

优雅有毛用，在老板下面，能说是关键，不会说，干再多活，都卵用。

相反，会说，不是你做的也没关系。

消除重复、命名。没了。不信？那我也没办法。

问题是多数人第一点都做不到。

安装 Sonarlint

第一步，学会自己看书、看文档、看官方教程。

第二步，经过第一步之后还是遇到不懂的地方，到论坛提问，问具体的问题。

《代码整洁之道》

@noqwerty
@th1nk
我觉得多写几行注释，在复用的时候比代码优雅的帮助不会低太多，如果退化到借助注释都看不懂了，估计代码优雅也救不了。
说句题外话，为啥现在程序员闹中年危机？老程序员的代码人家新人很容易就拿走去用了，然而精力又比不上新人，当然会被淘汰。
##总之，没有注释的帮助你就看不懂，新人看了一脸懵逼，这才是好代码😈

学习 OOA OOD ADT DDD，比学怎样 get set 更漂亮有用

两方面啊，第一，你用一门写起来比较漂亮的语言，比如 kotlin 就比 java 漂亮一百倍；另一个，多看设计模式啊，然后就优雅了。我觉得并不是别人逼的，你水平到了，写的代码自然就优雅。

学校又不教优雅代码，软工还学点设计模式，代码优雅是看人的

天天默念 don't repeat yourself 20 遍就行了

@mamahaha 说的好，
http://blog.jobbole.com/80241/
把这篇文章修成，就没这问题了（

每人提《重构》？

多看，多写

给时间就可以优雅,否则免谈

用规范的工具 校验

@yuankui 建议你买一本《程序员的职业素养》仔细阅读一下

@yuankui 能说有卵用，赚不到钱，说再多都卵用。这么浮躁的嘛

c# 推荐 codemaid

学习面向对象

譬如下面这个图

https://d3c33hcgiwev3.cloudfront.net/imageAssetProxy.v1/_378261654f7e71fc7355bb8aa5d67853_UML-Class-Diagram-Contacts.png?expiry=1553990400000&hmac=FsDEVNWvwW1o92_0tdBk4TkJ3U3p9lXhpmgCx7nIoQc

谷歌代码风格规范，有汉化版本的

风格方面可以直接使用相应的 fmt 或 lint 工具，比如写 JS 用 ESLint，Go 和 Rust 都自带 fmt 工具。
但是其他方面就没那么容易了，代码的可靠性和性能都依赖于经验，可读性依赖于表达能力，Code Review 可以在明显的程度上改善这个问题。

可以参考一下我们团队的一个开发手册，忽略其他主题直奔 Coding 部分： https://github.com/guanghetv/our-dev-handbook/blob/master/README.md

关于 Python 的可以多看看源码，可以参考这个：[Requests 源码分析]( https://zhangslob.github.io/docs/requests/request_source_code/)

java 推荐：《 Effective Java 》《重构：改善既有代码的设计》《代码整洁之道 》《设计模式之禅》 。可能其它语言也有相似之处，欢迎其他 V 友补充

用代码质量管理工具：Sonar

不建议直接去看上面的书

如果你不再是学生的话,心态、时间、记忆力都不适合直接看书

优秀源码光读没用, 要模仿着写, 你真正模仿优秀源码实现自己的需求的时候
并在模仿过程中删减增加,才能理解到哪些设计和写法的作用

到一定阶段后再看上面提到的书效果会更好

1、花时间写几年代码
2、结合以上书反思，对我个人帮助比较大的是《代码整洁之道》

@sadhen 深受其害。

@qleroooo 那请问优雅和赚钱又有什么关系？

代码写得再漂亮，还不是民工。。

与其好好学习如何优雅地用 Java 面向对象编程，还不如好好学习，怎么优雅的用人类高级语言，面向下属，面向员工编程。。

@yuankui

程序员的职业素养不只是将怎么写代码的 see https://book.douban.com/subject/11614538/

目　录
第 1 章　　专业主义　　 1
1.1 　　清楚你要什么　　 2
1.2 　　担当责任　　 2
1.3 　　首先，不行损害之事　　 4
1.3.1 　　不要破坏软件功能　　 4
1.3.2 　　不要破坏结构　　 7
1.4 　　职业道德　　 8
1.4.1 　　了解你的领域　　 10
1.4.2 　　坚持学习　　 11
1.4.3 　　练习　　 11
1.4.4 　　合作　　 12
1.4.5 　　辅导　　 12
1.4.6 　　了解业务领域　　 13
1.4.7 　　与雇主 /客户保持一致　　 13
1.4.8 　　谦逊　　 13
1.5 　　参考文献　　 14
第 2 章　　说“不”　　 15
2.1 　　对抗角色　　 17
2.2 　　高风险时刻　　 20
2.3 　　要有团队精神　　 22
2.3.1 　　试试看　　 24
2.3.2 　　消极对抗　　 25
2.4 　　说“是”的成本　　 27
2.5 　　如何写出好代码　　 34
第 3 章　　说“是”　　 37
3.1 　　承诺用语　　 39
3.1.1 　　识别“缺乏承诺”的征兆　　 40
3.1.2 　　真正的承诺听起来是怎样的　　 41
3.1.3 　　总结　　 43
3.2 　　学习如何说“是”　　 43
3.2.1 　　“试试”的另一面　　 43
3.2.2 　　坚守原则　　 44
3.3 　　结论　　 47
第 4 章　　编码　　 48
4.1 　　做好准备　　 49
4.1.1 　　凌晨 3 点写出的代码　　 50
4.1.2 　　焦虑时写下的代码　　 51
4.2 　　流态区　　 53
4.2.1 　　音乐　　 54
4.2.2 　　中断　　 55
4.3 　　阻塞　　 55
4.4 　　调试　　 57
4.5 　　保持节奏　　 60
4.5.1 　　知道何时应该离开一会　　 60
4.5.2 　　开车回家路上　　 61
4.5.3 　　洗澡　　 61
4.6 　　进度延迟　　 61
4.6.1 　　期望　　 62
4.6.2 　　盲目冲刺　　 62
4.6.3 　　加班加点　　 63
4.6.4 　　交付失误　　 63
4.6.5 　　定义“完成”　　 64
4.7 　　帮助　　 64
4.7.1 　　帮助他人　　 64
4.7.2 　　接受他人的帮助　　 65
4.7.3 　　辅导　　 66
4.8 　　参考文献　　 66
第 5 章　　测试驱动开发　　 67
5.1 　　此事已有定论　　 69
5.2 　　 TDD 的三项法则　　 69
5.3 　　 TDD 的优势　　 70
5.3.1 　　确定性　　 70
5.3.2 　　缺陷注入率　　 71
5.3.3 　　勇气　　 71
5.3.4 　　文档　　 72
5.3.5 　　设计　　 72
5.3.6 　　专业人士的选择　　 73
5.4 　　 TDD 的局限　　 73
5.5 　　参考文献　　 74
第 6 章　　练习　　 75
6.1 　　引子　　 75
6.1.1 　　 10 的 22 次方　　 76
6.1.2 　　转变　　 77
6.2 　　编程柔道场　　 79
6.2.1 　　卡塔　　 80
6.2.2 　　瓦萨　　 81
6.2.3 　　自由练习　　 81
6.3 　　自身经验的拓展　　 82
6.3.1 　　开源　　 82
6.3.2 　　关于练习的职业道德　　 82
6.4 　　结论　　 83
6.5 　　参考文献　　 83
第 7 章　　验收测试　　 84
7.1 　　需求的沟通　　 84
7.1.1 　　过早精细化　　 86
7.1.2 　　迟来的模糊性　　 87
7.2 　　验收测试　　 89
7.2.1 　　“完成”的定义　　 89
7.2.2 　　沟通　　 91
7.2.3 　　自动化　　 92
7.2.4 　　额外工作　　 93
7.2.5 　　验收测试什么时候写，由谁来写　　 93
7.2.6 　　开发人员的角色　　 94
7.2.7 　　测试的协商与被动推进　　 95
7.2.8 　　验收测试和单元测试　　 96
7.2.9 　　图形界面及其他复杂因素　　 97
7.2.10 　　持续集成　　 98
7.3 　　结论　　 98
第 8 章　　测试策略　　 99
8.1 　　 QA 应该找不到任何错误　　 100
8.1.1 　　 QA 也是团队的一部分　　 100
8.1.2 　　需求规约定义者　　 100
8.1.3 　　特性描述者　　 100
8.2 　　自动化测试金字塔　　 101
8.2.1 　　单元测试　　 101
8.2.2 　　组件测试　　 102
8.2.3 　　集成测试　　 103
8.2.4 　　系统测试　　 104
8.2.5 　　人工探索式测试　　 104
8.3 　　结论　　 105
8.4 　　参考文献　　 105
第 9 章　　时间管理　　 106
9.1 　　会议　　 107
9.1.1 　　拒绝　　 107
9.1.2 　　离席　　 108
9.1.3 　　确定议程与目标　　 109
9.1.4 　　立会　　 109
9.1.5 　　迭代计划会议　　 109
9.1.6 　　迭代回顾和 DEMO 展示　　 110
9.1.7 　　争论 /反对　　 110
9.2 　　注意力点数　　 111
9.2.1 　　睡眠　　 112
9.2.2 　　咖啡因　　 112
9.2.3 　　恢复　　 112
9.2.4 　　肌肉注意力　　 112
9.2.5 　　输入与输出　　 113
9.3 　　时间拆分和番茄工作法　　 113
9.4 　　要避免的行为　　 114
9.5 　　死胡同　　 115
9.6 　　泥潭　　 115
9.7 　　结论　　 116
第 10 章　　预估　　 117
10.1 　　什么是预估　　 119
10.1.1 　　承诺　　 119
10.1.2 　　预估　　 120
10.1.3 　　暗示性承诺　　 121
10.2 　　 PERT 　　 122
10.3 　　预估任务　　 125
10.4 　　大数定律　　 127
10.5 　　结论　　 127
10.6 　　参考文献　　 128
第 11 章　　压力　　 129
11.1 　　避免压力　　 131
11.1.1 　　承诺　　 131
11.1.2 　　保持整洁　　 132
11.1.3 　　危机中的纪律　　 132
11.2 　　应对压力　　 133
11.2.1 　　不要惊慌失措　　 133
11.2.2 　　沟通　　 133
11.2.3 　　依靠你的纪律原则　　 133
11.2.4 　　寻求帮助　　 134
11.3 　　结论　　 134
第 12 章　　协作　　 135
12.1 　　程序员与人　　 137
12.1.1 　　程序员与雇主　　 137
12.1.2 　　程序员与程序员　　 140
12.2 　　小脑　　 142
12.3 　　结论　　 143
第 13 章　　团队与项目　　 144
13.1 　　只是简单混合吗　　 144
13.1.1 　　有凝聚力的团队　　 145
13.1.2 　　如何管理有凝聚力的团队　　 146
13.1.3 　　项目承包人的困境　　 147
13.2 　　结论　　 148
13.3 　　参考文献　　 148
第 14 章　　辅导、学徒期与技艺　　 149
14.1 　　失败的学位教育　　 149
14.2 　　辅导　　 150
14.2.1 　　 DIGI-COMP I, 我的第一台计算机　　 150
14.2.2 　　高中时代的 ECP-18 　　 152
14.2.3 　　非常规辅导　　 154
14.2.4 　　艰难的锤炼　　 155
14.3 　　学徒期　　 156
14.3.1 　　软件学徒期　　 158
14.3.2 　　现实情况　　 159
14.4 　　技艺　　 160
14.5 　　结论　　 161
附录　　工具　　 162

一昧的追求优雅代码都是工作太闲造成的

@masker 不要为垃圾代码找借口

我等野路子就不用啥优雅了吧，把注释写的明明白白的才是王道！

算法导论 tex 源码，计算机程序与艺术。真程序员大佬的代码

@yuankui 就是啊 你说的本来就是两个问题，说话和代码优雅有啥冲突？

@a570295535 哈哈，我觉得也是，

经过几年的开发，代码会越来越优雅。
高效的架构，就是优雅的代码。
对于多年开发的有经验者，面对巨量的开发，只要完成，就是优雅的代码。

首先找一个好的 lint-style. 例如前端开发就很推荐 airbnb 的, c 就用 google 的. 先把格式养成习惯, 不开 lint 也能保持一样的格式再说其余的好不好看.

引用所有空间
注释上写小说
一个 cs 不低于 500m
i++一下不低于 100 行。
在保持高速响应的前提下，能多繁琐就多繁琐，跑路的时候就不用删库了，反正每个两三天我也看不懂，没准会被小说吸引的看俩星期

注释上写推广广告，写联系方式，写银行卡号

想省事，给钱，在第一时间把跑路预备最好，再干正经事😆😽

将你的程序在心中写好，
然后在心中执行一遍，
然后用伪代码写一遍，
然后用代码填充好伪代码。
每当我这样写代码，
可以写上几十到几百行基本没有 BUG。

代码大全等书籍确实需要看一遍，程序员分为两种，看了软件工程书籍的和没看的。