关键词：
1.勒布朗法则：later equals never
对于我来说：很多事如果往后拖的话，再重拾的几率就很小，所以要逼迫自己捉住现在，把手头的事情尽可能的做到尽善尽美，否则，日后只会越拖越远。
2.糟糕的代码所带来的深痛影响在于将来他会使你深陷泥沼
刚开始写的代码比较简单，但是后面要不断的添加功能，如果以前的代码写得十分冗余，以后再添加新功能所带来的麻烦将是不可估量的。所以代码一开始就要写的简单有效，为以后做铺垫。
3.态度：作为一个程序员，态度很重要：要以专业的态度来对自己的代码负责
4.命名：命名费时间，但是选个好名字省下来的时间比花掉的多，一旦发现更好的名字，就把旧的换掉，这样不仅读代码的人，自己也更开心
好的名字也有注释的功能。
命名：简单粗暴+不与其他命名产生冲突+能让人读懂
5.作者经验的结果：函数要短小
函数只做一件事+做好一件事
函数的参数越少越好，三个或三个以上可能要采用IntroduceParameterobject（引用参数对象）
使用异常代替返回错误码
抽离try/catch代码块
减少重复
6.注释：
注释的目的是为了日后自己或别人能够更加直接的读懂代码，所以注释中应是函数中的解释，一些个人的习惯或者无用的废话以及注释掉的代码都应该删除。
7.格式：
写代码应该有一定的规律，保持全篇的整洁及规范，让人感觉舒服
8.对象和数据结构：
平常我们写TO类的时候非常顺手的定义一些private类型的成员变量，然后各自定义他们的getXXX()和setXXX()方法。这样的写法体现了Java的封装性，虽然实现还是暴露了，外部类可以使用这些私有属性，但是我们可以在get和set方法中添加一些权限，来保证数据的安全性。而且有些框架是强制使用get和set方法来给对象赋值和取值
数据对象的反对称性
对象把数据隐藏于抽象之后，暴露操作数据的函数；数据结构暴露其数据，没有提供有意义的函数。
过程式的代码可以很方便的添加函数，其他的形状类不会受影响，但是添加另一个形状类就需要修改函数来实现该新加类的操作。
面向对象的代码就会通过继承来实现多态，area()方法就是多态的。如果多一个新的形状类很简单，但是当添加一个函数的时候，所有的形状类都需要修改。
过程式代码(使用数据结构的代码)便于在不改动既有数据结构的前提下添加新函数。面向对象代码便于在不改动既有函数的前提下添加新类。
在实际工作中经常会遇到这种两难的情况，设计模式——可以参考访问者模式(Coming out...)。
迪米特法则
law of demeter, LKP最少知道原则：一个对象应当对其他对象又尽可能少的了解，不和陌生人说话。也即是方法不应该调用由任何函数返回对象的方法。
例子：类C的方法f只应该调用一下对象的方法：1) C 2) 由f创建的对象 3) 作为参数传递给f的对象 4) 由C的实体变量持有的对象.
数据传送对象
最为精炼的数据结构是一个只有公共变量、没有函数的类。称之为DTO，经常用于数据库通信、解析套接字传递的消息之类场景。
9.异常处理：
每个软件系统都避不开异常处理，需要防止它搞乱我们的逻辑。
1. 利用异常处理代替返回异常编码，返回异常编码会是的代码中充满了if/else，switch/case扰乱我的代码流转。
2. 对于特定异常扑捉，可以面向异常编程，编写特定的异常类，使得对异常封装转化，更容易捕善后获处理。
3. 避免返回null，在软件系统中最常见头疼的就是NullReferenceException。在非特定场景下，我们应该极力的避免返回null。面对这种场景我们可以采用null object Pattern（空对象模式）返回特例对象，如c#类库中的Guid.Empty，string.Empty；对于集合类型我们可以返回长度0的空集合而非null；
10.类
面向对象的特征：封装、继承、多态、抽象。
1. 类第一原则应是是小并足够的小。但与函数不同的是函数以代码行数统计，而类以权责统计。
2. 单一原则（SRP），体现了类只应该做一件事，并且做好它，这样变化修改的理由只有他所做的事。良好的软件设计中系统是由一组大量的短小的类和他们之间功能协作完成的，而不是几个上帝类。
3. 内聚：高内聚低耦合：提出与结构化编程，内聚表述模块内部功能不同操作逻辑之间的距离，如果一个类的每个变量都被每个方法所使用为最大的内聚；耦合描述模块之间的依赖程度；高内聚低耦合以简单的方式表述就是功能完备（高内聚）对象之间是通过稳定的接口（低耦合）交互的。
4. 依赖倒置（DIP）：描述组件之间高层组件不应该依赖于底层组件。依赖倒置是指实现和接口倒置，采用自顶向下的方式关注所需的底层组件接口，而不是其实现。DI模式很好的就是应用IOC（控制反转）框架，构造方式分为分构造注入，函数注入，属性注入；.net平台流行的IOC框架有Unity，Castle windsor，Ninject，Autofac等框架支持，
11.并发编程：
并发是一种时间(When)和目的(What)的解耦,提供应用程序的吞吐量，提高cpu利用率；但是并发编码不是那么容易，再加上临界资源竞争死锁。在并发编程的时候我们必须尽量遵守一些原则：
1. 并发已经足够复杂，我们更需要代码分离，分离线程相关代码和非线程相关代码，单一权责，尽可能降低其复杂度。
2. 限制临街资源的作用域，为临界资源加锁是防止并发的策略，但是必须正确的加锁，如果形成等待环，就导致死锁。
3. 利用数据副本（值对象或者克隆）在线程之间传递数据，避免线程之前操作的并发影响；线程独立，使其在自己的环境中运行，不能其他线程共享数据。
4. 对于临界资源加锁应尽量保持加锁范围尽可能的小。
第九次读书笔记——读《代码整洁之道》有感
第九次读书笔记——读《代码整洁之道》有感“相对于任何宏伟景愿，对细节的关注甚至是更为关键的专业的基础。首先，开发者通过小型实践获得可用于大型实践的技能和信用度。其次，宏伟建筑中最细小的部分，比如关不紧... 查看详情
读《cleancode代码整洁之道》之感悟(代码片段)
盲目自信，自认为已经敲了几年代码，还看什么整洁之道啊。我那可爱的书架读懂了我的心思，很明事理的保护起来这本小可爱，未曾让它与我牵手最近项目中的bug有点多，改动代码十分吃力，每看一行代码都带一句“这是什么... 查看详情
前端阅读——《代码整洁之道》摘记之整洁代码命名函数注释
这本书提出一种观念：代码质量与其整洁度成正比。干净的代码，既在质量上较为可靠，也为后期维护、升级奠定了良好基础。（作者认为书可以有另一个名字：《如何在意代码》）读这本书，促使我思考代码中何谓正确，... 查看详情
代码整洁之道(代码片段)
有意义的命名1名副其实2避免误导3做有意义的分区废话都是冗余。Variable永远不应出现在变量名中，Table一词永远不应出现在表名中。当缺少明确约定：变量moneyAmout与money没区别，customerInfo与customer没区别，accountData与account没区别... 查看详情
代码整洁之道(代码片段)
有意义的命名1名副其实2避免误导3做有意义的分区废话都是冗余。Variable永远不应出现在变量名中，Table一词永远不应出现在表名中。当缺少明确约定：变量moneyAmout与money没区别，customerInfo与customer没区别，accountData与account没区别... 查看详情
《代码整洁之道》读书笔记
...这句话的浓缩。 本书的第一章是关于什么是整洁代码的讨论，引用了Bjarne 查看详情
读《代码整洁之道》-函数名称应该表达其行为(代码片段)
...码的”，让我非常吃惊。我一直也是认为，好的代码应该是看到函数名就应该知道含义，看到参数和返回值就应该可以放心使用，而不是非要去读源码才不会误用。今天重读《代码整洁之道》，看到书中提到&#... 查看详情
读c#代码整洁之道笔记02_类对象和数据结构及编写整洁函数
...职责就是类所具备的功能3. 从注释生成文档3.1. 源代码文件的顶部都应当包含版权声明3.2. 命名空间、接口、类、枚举、结构体、方法和属性都应当包含注释4. 内聚4.1. 高内聚4.1.1. 代码应恰当分组4.2. 低... 查看详情
《代码整洁之道》
代码整洁之道代码猴子(CodeMonkey):低水平编码者.童子军规.技艺(craftsmanship):知和行.学写整洁代码,掌握原则和模式,并付出行动.整洁代码代码呈现了需求的细节.这些细节无法被忽略或抽象,必须要严谨,精确,规范和详细.糟糕的代码... 查看详情
代码整洁之道(cleancode)读后感(代码片段)
第二次读代码整洁之道（CleanCode）了，在少许开发经验加持下，没有第一次那么晦涩后，整体对本书也有了共鸣，这本书应该作为指导手册，平时可以多翻一翻，说不定会有新的不同感悟，当然... 查看详情
代码简洁之道
...要详细了解的建议去看更优质的详细讲解。本书主要站在代码的可读性上讨论。可读性？顾名思义，代码读起来简洁易懂，让人心情愉悦，大加赞赏。在N年以后，自己或者他人仍然能够稍加阅读就能明白其中的意思。什么是整... 查看详情
整洁之道如何写出更整洁的代码(上)
如何写出更整洁的代码 代码整洁之道不是银弹，不会立竿见影的带来收益。 没有任何犀利的武功招式，只有一些我个人异常推崇的代码整洁之道的内功心法。它不会直接有效的提高你写代码的能力与速度，... 查看详情
typescript代码整洁之道
干净整洁的代码，不但质量更可靠，也为后期升级、维护打下了良好的基础。那么，整洁代码的衡量标准是什么？本文将RobertC.Martin的CleanCode思想融入到TypeScript，一起探讨研究代码整洁之道。 WTFs/Minute 1.命名的艺术计算... 查看详情
代码整洁之道
文章目录代码整洁之道定义变量名字的时候常用的单词有意义的命名怎样写简洁的，别人一眼可以看的懂的方法方法参数越少越好注释格式别给方法返回null值我们该提炼方法中的变量还是不提炼方法中的变量？代码整洁之道定... 查看详情
读c#代码整洁之道笔记05_使用工具改善代码和单元测试
1. 高品质的代码1.1. 性能（Performance）1.1.1. 只执行需要的操作，而且执行迅速1.1.2. 不会使系统陷入停顿1.2. 可用性（Availability）1.2.1. 持续在所需的性能水平上保持可用1.2.2. Topic11.3. 安全性（Security）... 查看详情
读c#代码整洁之道笔记04_重构c#代码识别代码坏味道
1. 应用程序级别代码坏味道1.1. 布尔盲点1.1.1. 由于函数使用布尔值而导致的信息缺失1.1.2. 解决方案是将布尔替换为枚举类型1.2. 组合爆炸1.2.1. 不同的代码使用不同的参数组合来执行同一件事情的产物1.2.2.&n... 查看详情
读c#代码整洁之道笔记01_c#的编码标准和原则
1. 编码原则1.1. SOLID原则1.1.1. 单一职责原则（SingleRespon-sibilityPrinciple）1.1.1.1. 类和方法应当仅具备单一职责。所有组合为单一职责的元素应当组合在一起并进行封装。1.1.2. 开闭原则（Open-ClosedPrinciple）1.1.2.1.&nbs... 查看详情
代码整洁之道-函数
函数参考书籍：《代码整洁之道》，语言：Python1.函数要短小1）每个函数只做一件事，并且每个函数都依次把你带到下一个函数，这就是函数应该达到的短小程度。2）if,else,while等语句的代码块应该只有一行，该行大概是一个函... 查看详情