大学计科狗，老师基本上只教编程的方法，很少教代码的格式，我喜欢用c，可写出的程序每次都被老师嘲讽说代码像小学生写的。。额，可能列为大牛都经历过代码的格式问题，可否分享下微单开群机器人经历。
补充：贴出来曾经写的一个用A*解决八数码的代码，后来没写完弃坑了，然后现在补完了。
再补充：大三才从食品专业转到计算机系的，写的代码很少，不过一直记得无机化学老师说的，不要把习惯搞坏了。我想开始写代码就养成一个好习惯，习惯很重要，这样以后也不用改了，所以想多了解下真正的代码是什么样子的，或许问题题目应该是优美的或实用的代码是什么样子的。
我司代码注释比例极低(除非是库接口)，因为不实用。
大工程中，要求所有程序员改代码同时记得改注释不现实。过时的注释不但起不到效果，反而会误导。
保证代码可维护性，主要通过严格的函数和变量命名。命名必须达到通过名字基本可看懂其作开群飞单软件用的程度。
代码就是最好的注释。
大多数公司都是10%非常优质底层架构代码+10%优质核心业务代码+80%小学生业务代码
注释率非常低，但会在一些很trick或者hack的地方写几笔注释，防止未来自己看到想不起来，其他人一般是看不懂的。
业务逻辑代码基本上撸起袖子就干，没时微单开群软件间去规划抽象搞设计模式，因为大概率第二天就改需求了；一个正常命名的函数里面会有奇怪的逻辑，一般都来自于产品一个莫名其妙的紧急需求，等接手人想再研究的时候，可能最早的产品和程序都不在项目组了，基本就删掉重写。
系统大了之后，底层的东西一行代码都不敢改，即使错了，也选择外面包一层绕开错误，因为你改动这一行代码真的会影响几亿用户，需要巨量的测试成本，从工程角度有其他影响面更小的方法就不必去修改底层。
有一些很优雅可靠的创新实现，也是针对某种特定业务问题的，很难抽出来复用，只能学思路。
去看著名的开源代码，会学到比较多的好的做法，不要想着公司的代码，绝大部分公司的代码都写的很屎，完全被开源代码吊打。
公司代码和开源代码的比较就是会有很多业务逻辑写入到基础组件里面，俗称：业务逻辑下沉。
公司代码很多缺乏注释文档和上下文，单元测试也没，什么merge request，需求文档，东一摊西一摊，要用的时候都是派不上用处的。
写起业务来百分之四十的时间都是在帮上下游熟悉业务，那为啥不写文档？首先，自己也不懂整个全貌，其次，写了也没人看啊
以上都是吐槽，刚刚添加了几百个单元测试和一堆文档的我表示我不是这么干的。
