`
xmou
  • 浏览: 5894 次
  • 性别: Icon_minigender_1
  • 来自: 成都
最近访客 更多访客>>
社区版块
存档分类
最新评论
文章列表
  Ruby看起来与众不同,基于一组精心设计的接口方法和作用域理论,形成了其优雅的语义模型。但是万变不离其宗,了解了Ruby的对象模型,也就了解了其魔幻般的动态元编程原理。[消息机制]Ruby很好的继承和发扬了Smalltalk的面 ...
记得高中学英语的时候特别喜欢记单词,高一记完了所有高中的单词,到高三的时候把六级的单词也全都记完了。 记忆的方式比较土,就是不断的重复。简单的单词可以很快记住,比较复杂的,就直接在单词书的空白地方不停的写。有时候一个单词可能会写上20-30遍,就是为了加深大脑皮层的记忆。 那个时候对自己的单词量特别有信心,有时候写作文就故意卖弄一些复杂的单词,以至于老师有时候都看不懂,很是得意。 后来高中毕业上了大学,宽松的环境造就了一个放纵的自我。举着60分万岁的大旗,每学期每周每天不断的翘课,但得除了辅导员的形式教育课(这个你懂的)。不过凭借高中的英语基础,大一下学期和大二上学期裸考顺利通过了CE ...
忙或者说懒了很久,虽然书看到10多章了,但是却一直没来得及更新。来看看第四章吧。 陈旧、提供错误信息的注释最有破坏性。当然,跟不上变化的文档也是如此。 只有代码才能作为真正正确的信息来源。好的代码也许根本不需要注释。 让代码来表达意图,让代码来讲故事,让注释越少越好。 为什么注释如此的让人讨厌? 因为注释不一定会随着代码的更新而一同改变,到最后注释也许就会变得完全错误。 4.1 注释不能美化糟糕的代码 为糟糕的代码写注释不如对这些代码进行改善。程序员应该以代码为本,本末倒置是会付出代价的。 4.2 用代码来阐述
今天是第三章:函数 开篇的函数确实很长,虽然命名还较得体,但总不能让人瞻前顾后。另外,其中还有较多重复的代码。 进行重构以后,把细节隐藏起来,让骨骼框架先展示出来确实能让逻辑更清晰。 3.1 短小: 看了开篇的例子,让函数保持短小精干的风格,对大家来说应该是没有异议的。 就好像英语单词,短的总是比长的好记。同样,小函数要表达的意思肯定比长函数要清晰。 小函数只做一件事,能依序把你带到下一个函数,不需要前后对照就能一目了然。 3.2 只做一件事: 函数无非完成特定的功能,即“要到达什么目的,就需要做什么”。如果能一言以蔽之,那函数就在同一抽象层上只做一件事。
今天来到Clean Code 的第二章。     2.1 介绍: 到处都需要命名   2.2 名副其实: 取个好名字需要时间,但能让维护更省心;好的名称能明确体现上下文   2.3 避免误导: 不要使用与本意相悖的名称,要保持名称之间的区分度(注意不要单独使用l和O) 联想到Captcha 中最好不要出现的字符更多,比如 Z-2, O-0, l-1, I-l, S-5     2.4 做有意义的区分: 不要出现数字后缀,也不要废话 有个疑问,为什么不能用klass或者clazz呢?比如我就是想取单个对象的Class。   2.5 使用能 ...
  这几天开始看Robert C.Martin(鲍勃大叔)所著的Clean Code,看得很慢,看了好几天才看了前2章。   慢的原因有几个方面的原因: 1、才疏学浅,需要好好咀嚼才能理解大牛们几十年来总结的经验和准则 2、需要结合自身以前的一些编码习惯好好的反思一下,希望可以去伪存真 3、阅读过程中有些小节有疑惑,在未继续阅读本书获得解答前,需要时间进行思考 4、时间不够用,每天能静下来看书的时间可能就一到两个小时,有时候甚至都没有时间   不过我想,既然慢,那就争取慢中出细活,希望将书中内容熟稔在心,也希望借此时时鞭策我向整洁代码靠近。   在这个系列中,我会把对每个小 ...
Global site tag (gtag.js) - Google Analytics