首先你要知道你写code的目的是什么。你要解决的问题是什么。 我个人认为，一个好的coding，根本不需要太多的documentation，应该是旁人（当然是懂行的人）一看就明白在干什么，function是什么，input，output，解决了什么问题，一目了然。我个人是很讨厌，花里胡哨，旁人花力气才能看懂，维护起来也很麻烦的那种code。 我的工作title是software engineer。我对engineer的理解是我是来解决问题的。写code只是解决问题的一个步骤。找出问题的根本，设计解决方案，最后测试自己的方案这个流程才是灵魂。 所以想要让人觉得自己professional，那就得你的思想有engineer的高度。我个人认为，一个好的engineer，一上来先要define，需要解决的问题是什么。搜集资料，做research。然后再设计如何解决这个问题。从不同角度思考。最后定方案的时候，需要知道我为什么选择这个方案。在交流的时候你得言之有物。比如这么做可以延续原有的设计思路，或者这么做节省memory，或者这么做容易maintain。总之一个engineer对于自己采用的方案是有想法的。 等想清楚了以后，那才是coding的部分。其实coding的部分并没那么重要。我工作中用c++，c#。去解决一个问题，可以有不同的方式。就拿loop来说，我可以while，可以for，可以用foreach，等等，方式很多。这个不重要，能实现功能，不要有bug就可以了。但是你写的function，你的设计意图是否清晰，你有没有solve the problem，meet the requriement，你写的东西是否easy to maintain在我看来才是更重要的。
一开始不要野路子乱来，养成了坏习惯不容易改的。
你是认真的吗
2 minutes?
It takes time. 多看别人写的代码。
我个人认为，一个好的coding，根本不需要太多的documentation，应该是旁人（当然是懂行的人）一看就明白在干什么，function是什么，input，output，解决了什么问题，一目了然。我个人是很讨厌，花里胡哨，旁人花力气才能看懂，维护起来也很麻烦的那种code。
我的工作title是software engineer。我对engineer的理解是我是来解决问题的。写code只是解决问题的一个步骤。找出问题的根本，设计解决方案，最后测试自己的方案这个流程才是灵魂。
所以想要让人觉得自己professional，那就得你的思想有engineer的高度。我个人认为，一个好的engineer，一上来先要define，需要解决的问题是什么。搜集资料，做research。然后再设计如何解决这个问题。从不同角度思考。最后定方案的时候，需要知道我为什么选择这个方案。在交流的时候你得言之有物。比如这么做可以延续原有的设计思路，或者这么做节省memory，或者这么做容易maintain。总之一个engineer对于自己采用的方案是有想法的。
等想清楚了以后，那才是coding的部分。其实coding的部分并没那么重要。我工作中用c++，c#。去解决一个问题，可以有不同的方式。就拿loop来说，我可以while，可以for，可以用foreach，等等，方式很多。这个不重要，能实现功能，不要有bug就可以了。但是你写的function，你的设计意图是否清晰，你有没有solve the problem，meet the requriement，你写的东西是否easy to maintain在我看来才是更重要的。
我很菜。打个简单的比方，比如有几million的rows， check 每个row的missing value，然后fill in xx，我写的loop是要run一会。
反而是那种fancy的syntax，什么lambda啦，recurrsive的东西啦，tree啦，这种东西并没那么重要。比如我上学学过tree这个结构。但是在实际工作中几乎没用过。因为根本用不到。function，class写的简洁明了才是王道。easy test，easy debug，easy review。好的interface，用起来就跟说话一样，逻辑鲜明，功能简单，不容易让用的人出错。这些才是反应真正水平的东西。
难得看到这种回复
我是真叫别人花里胡哨的function给看恶心了，然后一到presentation就叽叽歪歪啥都说不清楚，也不知道解决了什么问题，就反复唠叨自己的input 和各种乱七八糟function
看别人的code，最主要是structure，github上下人家的solution看对我有帮助，我们是一般的应用层小系统，对速度和资源占用要求都比不了那些分布，及时的大应用。
先好好找工作，去个大厂，进个好组，然后去看组里senior的code。 对于有的对code要求不严的组，看还不如不看
多刷题比什么格式更管用，真的
谢谢mm！ 听君一席话，胜读十年书！ 你说的很多地方正好是我的问题。特别是在开始coding之前先有详细的规划，确实是我没有做到的
真是直达我这个起名废的痛点
我们是传统公司，不是IT大厂，我们整个组都是从统计转DS的，coding都挺水的。 IT部门的code我们看不到
写好code进大厂好组，和进大厂好组写好code，互为因果
前者不需要你把code写整齐。。
至少看看系统里以前的CR的comments
这个我们内部也讨论过， 为啥ds的python code 写得那么烂？ 原因有几个吧：
大多数code 都是用完就扔的， 写完了弄出数据就好。 code review 都是pair program， 所以code里不需要太多的上下文。
要想提高，还是要多些production 的code， 需要维护的code 肯定要写的好一些。
Exactly！我们就是做完就扔， 而且基本是自己写自己用，不需要太多的合作，所以写得烂也能混。。。但也是限制自己发展的一个瓶颈，所以还是想突破一下
做完就扔也是有改进空间的，比如，这次做的和下次做的有没有相似的，可以抽象一下reuse的
是的，这些都是在改进的地方，所以需要学习
等想清楚了以后，那才是coding的部分。
-- 赞。
“现在公司” 里的要求是一天一变。。。写的model 出来还有去改，或者重新写。
所以很多coding 问题不是没有写好，而是没有时间去想， 然后写。 因为问题一直在变， 要求也在变。。