北京哪家治疗白癜风正规 https://disease.39.net/yldt/bjzkbdfyy/大数据文摘作品
编译：傅一洋、汪小七、张南星、GAONing、夏雅薇
高级的编程是逻辑思维的流露，会编程只代表你懂了这门语言的语法，但是会写清晰简洁易懂可迭代的代码才是程序员该追求的境界。编程入门已经不容易，但是如果能够在早期树立一些正确的“代码观”，或许可以让你的编程之路升级得更快。作者苦口婆心地给出了25条建议，句句真言。
首先我要声明的是：如果你是编程新手，本文并不是要让你对自己犯的错误感到愧疚，而是要你对这些错误有更好的认知，并避免在未来再犯。
当然，这些错误我也经历过，但是从每个错误中都学到了一些新东西。现在，我已经养成了一些好的编程习惯，我相信你也可以！
下面是这些常见的错误，顺序不分先后。
写代码前缺少规划
一般来说，创作一篇高质量的文章不易，因为它需要反复推敲研究，而高质量的代码也不例外。
编写高质量代码是这样一个流程：思考、调研、规划、编写、验证、修改。（貌似没办法编成一个好记的顺口溜）
按照这样的思路走，你会逐渐形成良好的编程习惯。
新手最大的错误之一就是太急于写代码，而缺乏足够的规划和研究。虽然对于编写小程序而言是没多大问题的，但对于大项目的开发，这样做是很不利的。
为了防止代码写完之后发现重大问题，写之前的深思熟虑是必不可少的。代码只是你想法的流露。
生气的时候，在开口说话前先数到十。如果非常生气，就数到一百。——托马斯·杰斐逊
我把它改成针对写代码的版本：
审查代码时，重构每一行之前，先数到十。如果代码还没有测试，就数到一百。——SamerBuna
编程的过程主要是研读之前的代码，思考还需要修改什么，如何适应当前系统，并规划尽量小的改动量。而实际编写代码的过程只占整个过程时间花费的10％。
不要总认为编程就是写代码。编程是基于逻辑的创造，慢工出细活。
写代码之前规划过度
虽说写代码前充分规划是好，但凡事都有个度，还没开始做，就思考太多，也是不可取的。
不要期望世界上存在完美的规划，至少编程的世界中是不存在。好的规划可以作为起点，但实际情况是，规划是会随后续进行而改变的，规划的好处只是能让程序结构条理更清晰，而规划太多只会浪费时间。
瀑布式开发是一种系统线性规划的开发方法，它严格遵循预先计划的需求、分析、设计、编码、测试的步骤顺序进行，步骤成果作为进度的衡量标准。在这种方法中，规划是重中之重。如果只是编写小程序，也完全可以采用这种方法，但要对于大的项目，这种方法完全不可取。任何复杂的事情都需要根据实际情况随机应变。
编程是一个随时需要根据实际情况作出改变的工作。你后续可能会因为一些原因要添加或删除的某些功能，但这些情况瀑布计划中可能你永远也想不到。所以，你需要敏捷的开发模式。
但是，每一步之前是要有所规划的，只不过规划的过少或过多都会影响代码的质量，代码的质量非常重要。
低估代码质量的重要性
如果你无法兼顾代码的多项质量指标，至少要保证它的可读性。凌乱的代码就相当于废品，而且不可回收。
永远不要低估代码质量的重要性。你要将代码看作沟通的一种方式，作为程序员，你的任务是交代清楚目前任务是如何实施的。
我最喜欢一句编程俚语是：
写代码的时候可以这样想，维护你代码的家伙是一个知道你住在哪里的暴力精神病患者。——JohnWoods
很形象是不是？
即便是一些细节。例如，你的代码可能会因为排版问题或大小写不一致而不被认可。
tHISisWAYMOREimportantthanyouthink
还需要注意的是避免语句过长。任何超过80个字符的文本都是难以阅读的。你可能想在同一行放置长条件以便看到完整的if语句，这是不可取的，一行永远不要超过80个字符。
这种小问题可以通过linting工具或格式化工具轻松解决。比如在JavaScript中两个完美结合的优秀工具：ESLint和Prettier。多用它们，让工作更轻松。
还有一些与代码质量相关的错误：
任何超过10行的函数都太长了。一定不要出现双重否定句。使用简短的，通用的或基于类型的变量命名。尽量保证变量命名能清晰地表述变量。计算机科学领域只有两件难事：缓存失效和变量命名。缺乏描述地插入一些字符串和数字。如果要使用固定的字符串或数值，应该将其定义为常量，并命名。
“对于简单的问题，担心花费时间而草率地处理”。不要在众多问题中进行跳跃式选择，按部就班地来。认为代码越长越好。其实，大多数情况下，代码越短越好。只有在追求可读性的情况下可适当详细些。比如，不要为了缩短代码而使用很长的单行表达式或嵌套表达式，但也不要增加冗余的代码。最好的是，删去所有不必要的代码。过多使用条件语句。大部分你认为需要条件语句的情况都可以不通过它来解决。因此，考虑尽可能多的备选方案，根据可读性进行挑选。除非你知道如何测试代码性能，否则，不要试图优化。还有就是：避免Yoda条件或条件嵌套。
选择1号方案
当我刚开始编程时，一旦遇到问题，我会立刻寻找解决方案并重新运行我的程序。而不是先考虑我的头号方案复杂性和潜在的失败原因。
虽然1号方案极具诱惑性，但在研究了所有解决方案后，通常能发现更好的。如果无法想出多种方案，说明你对问题了解不够。
作为专业程序员，你的工作不是找到办法，而是找到最简捷的办法。“简捷”的意思是方案必须正确，可执行，且足够简单，易读，又便于理解和维护。
软件设计有两种方法。一种是设计的足够简单，没有瑕疵，另一种是设计的足够复杂，没人看得出明显瑕疵。——C.A.R.霍尔
吊死在一棵树上
这是我常犯的错误，即便确定了我的头号方案并不是最简单的解决方案，仍然不放手。这可能与我的性格有关。大多数情况下这是一种很好的心态，但不适用于编程。事实上，正确的编程心态是，将早期失败和经常性失败看成一种常态。
当你开始怀疑某个方案的时候，你应该考虑放下它并重新思考，不管你之前在它这里投入了多少精力。学会利用像GIT这样的源代码管理工具，它可以帮助你实现代码分支，尝试多种方案。
不要认为你付出了精力的代码就是必须采用的。错误的代码要摒弃。
闭门造车
很多次，在解决问题需要查阅资料时，我却直接尝试解决问题，浪费了很多时间。
除非你正在使用的是某种尖端技术，否则，遇到问题时，谷歌一下吧，因为一定会有人也遇到了同样的问题，并找到了解决方法，这样，能节省很多时间。
有时候谷歌之后，你会发现你所认为的问题并不是问题，你需要做的不是修复而是接受。不要认为你了解一切，Google会让你大吃一惊的。
不过，要谨慎地使用谷歌。新手会犯的另一个错误是，在不理解代码的情况下，原样照搬。尽管这可能成功解决了你的问题，但还是不要使用自己不完全了解的代码。
如果想成为一名创造性的程序员，就永远不要认为，自己对在做的事情了如指掌。
作为一个有创造力的人，最危险的想法是认为自己知道自己在做什么。——布雷特·维克多
不使用封装
这一点不只是针对使用面向对象语言的例子，封装总是有用的，如果不使用封装，会给系统的维护带来很大的困难。
在应用程序中，每个功能要与用来处理它的对象一一对应。在构建对象时，除了保留被其他对象调用时必须传递的参数，其他内容都应该封装起来。
这不是出于保密，而是为减少应用程序不同部分之间的依赖。坚持这个原则，可以使你在对类，对象和函数的内部进行更改时，更加的安全，无需担心大规模的毁坏代码。
对每一个逻辑概念单元或者块都应该构建对应的类。通过类能够勾画出程序的蓝图。这里的类可以是一个实际对象或一个方法对象，你也可以将它称作模块或包。
在每个类中，其包含的每套任务要有对应的方法，方法只针对这一任务的执行，且能成功的完成。相似的类可共同使用一种方法。
作为新手，我无法本能地为每一个概念单元创建一个新类，而且经常无法确定哪些单元是独立的。因此，如果你看到一套代码中到处充斥着“Util”类，这套代码一定是新手编写的。或者，你做了个简单的修改，发现很多地方也要进行相应地修改，那么，这也是新手写的。
在类中添加方法或在方法中添加更多功能前，兼顾自己的直觉，花时间仔细思考。不要认为过后有机会重构而马虎跳过，要在第一次就做对。
总而言之，希望你的代码能具有高内聚性和低耦合性，这是一个特定术语。意思就是将相关的代码放在一起（在一个类中），减少不同类之间的依赖。
试图规划未知
在目前项目还正在编写的时候，总是去想其他的解决方案，这是忌讳的。所有的谜团都会随着代码的一行行编写而逐一解开。如果，对于测试边缘案例进行假设，是件好事，但如果总想要满足潜在需求，是不可取的。
你要明确你的假设属于哪一类，避免编写目前并不需要的代码，也不要空想什么计划。
仅凭空想，就认为未来会需要某种功能，因而尝试编写代码，是不可取的。
根据目前的项目，始终寻求最少的代码量。当然，边缘情况是要考虑的，但不要过早落实到代码中。
为了增长而增长是癌细胞的意识形态。——EdwardAbbey
错误使用数据结构
在准备面试的时候，新手往往太过于
