zoukankan      html  css  js  c++  java
  • 编码的道与禅

    该文章发布在github中,如果您觉得写的还不错的话,可以 star 一下进行支持,传送门:TechShare

    Bob 大叔在《代码整洁之道》一书的前言打趣着说,当你写的代码在经受代码审查时,如果审查者愤怒的吼道“What the fuck is this shit?”等言辞激烈的词语时,那说明你写的是 Bad Code;如果审查者只是漫不经心的吐出几个“What the fuck?”,那说明你写的是 Good Code。这就是衡量代码质量的唯一标准——每分钟骂出“What the fuck?”的频率。

    想写出整洁的代码很难,有一部分原因在于糟糕的代码太容易编写。想快点完成任务时,考虑不周全时,忽略安全时,随意命名时,参数过多时,嵌套太深时,未及时更改注释时,违反法则时,重复你自己时等等情形,我们有太多的机会来制造糟糕的代码。只有严肃对待自己的代码,了解哪些事情会使我们的代码变味,才有可能写出整洁的代码。

    写代码和写文章在某种程度上有相似之处,好的文章一定有好的可读性,写代码也一样,只有优美干净的代码才能具有良好的可读性。编写具有可读性的代码不光是保持有意义的命名就行,如果你想成为一名更好的程序员,写代码时你需要注意的有很多,比如:

    1. 规范本地变量的位置
    2. 使函数尽量短小
    3. 调用者尽可能放在被调用者上面
    4. 保持代码拥有良好的格式
    5. 编写只做一件事的函数
    6. 函数参数不要超过三个
    7. 暴露时序耦合
    8. 使用异常代替返回错误码

    除此之外,你还须牢记众多设计原则,如:

    1. 开放封闭原则(OCP)
    2. 迪米特法则
    3. 依赖倒置原则(DIP)
    4. 单一职责原则(SRP)
    5. 里氏替换原则(LSP)
    6. 不要重复(DRY)
    7. 你不会需要它(YAGNI)

    当然仅有这些是不够的,这不是骑自行车,学写整洁代码得花许多功夫,必须不断实践,从失败中提取代码的坏味道并从中得到启发。

    编写整洁代码,你需要牢记并遵守很多东西,但这并不是循规蹈矩和刻板,而是对简单之美、代码之美的追求。代码整洁之道,是编写优秀代码的一种方法,其核心是尽力使代码保持简单——Keep It Simple, Stupid。判断一个人写的代码的好坏,不是看它的代码写的有多复杂,而是看他有没有把复杂的事物抽象出来并用简单的方式去描述它,此外这个人对代码的态度也至关重要,大多数时候我们并不能从一开始就把代码写的很完美,当我们需要快速做出一个原型,或者一开始代码看起来不错,但新的需求使现有的设计无法满足,如果不对设计进行改动的话,那么代码就会变的丑陋,如果你热爱自己正在做的事情,崇尚代码之美,那么你就会有足够的动力去重构它、完善它,而不是破坏结构使代码腐烂。

    保持简单、追求简单,我想这就是编码之中的禅意,一种追求本真的境界。这种禅在 Python 的设计哲学中体现的淋漓尽致,让我们在 Python 解释器中输入“import this”,来看看经典的 Python 之禅。

    • Beautiful is better than ugly.
      优美胜于丑陋。
    • Explicit is better than implicit.
      显式胜于隐式。
    • Simple is better than complex.
      简单胜于复杂。
    • Complex is better than complicated.
      复杂胜于难懂。
    • Flat is better than nested.
      扁平胜于嵌套。
    • Sparse is better than dense.
      分散胜于密集。
    • Readability counts.
      可读性应当被重视。
    • Special cases aren’t special enough to break the rules. Although practicality beats purity.
      尽管实用性会打败纯粹性,特例也不能凌驾于规则之上。
    • Errors should never pass silently. Unless explicitly silenced.
      除非明确地使其沉默,错误永远不应该默默地溜走。
    • In the face of ambiguity, refuse the temptation to guess.
      面对不明确的定义,拒绝猜测的诱惑。
    • There should be one– and preferably only one –obvious way to do it.
      用一种方法,最好只有一种方法来做一件事。
    • Although that way way not be obvious at first unless you’re Dutch.
      虽然一开始这种方法并不是显而易见的,但谁叫你不是Python之父呢。
    • Now is better than never. Although never is often better than right now.
      做比不做好,但立马去做有时还不如不做。
    • If the implementation is hard to explain, it’s a bad idea.
      如果实现很难说明,那它是个坏想法。
    • If the implementation is easy to explain, it may be a good idea.
      如果实现容易解释,那它有可能是个好想法。
    • Namespaces are one honking great idea – let’s do more of those!
      命名空间是个绝妙的想法,让我们多多地使用它们吧!

    道着重于方法,禅着重于态度,让我们把这两者相结合,做一个有追求的程序员,为成为软件匠人而奋斗吧。

  • 相关阅读:
    【LeetCode】241. Different Ways to Add Parentheses
    【LeetCode】240. Search a 2D Matrix II
    【LeetCode】239. Sliding Window Maximum
    【LeetCode】238. Product of Array Except Self
    【LeetCode】237. Delete Node in a Linked List
    【Babble】批量学习与增量学习、稳定性与可塑性矛盾的乱想
    【LeetCode】233. Number of Digit One
    【LeetCode】236. Lowest Common Ancestor of a Binary Tree
    MySQL存储过程
    mysql远程连接/访问速度慢的解决方案
  • 原文地址:https://www.cnblogs.com/lcomplete/p/13169956.html
Copyright © 2011-2022 走看看