自定义博客皮肤VIP专享

*博客头图:

格式为PNG、JPG,宽度*高度大于1920*100像素,不超过2MB,主视觉建议放在右侧,请参照线上博客头图

请上传大于1920*100像素的图片!

博客底图:

图片格式为PNG、JPG,不超过1MB,可上下左右平铺至整个背景

栏目图:

图片格式为PNG、JPG,图片宽度*高度为300*38像素,不超过0.5MB

主标题颜色:

RGB颜色,例如:#AFAFAF

Hover:

RGB颜色,例如:#AFAFAF

副标题颜色:

RGB颜色,例如:#AFAFAF

自定义博客皮肤

-+
  • 博客(15)
  • 收藏
  • 关注

原创 第十七章 味道与启发

1、注释 不好的注释:不恰当的信息;废弃的注释;冗余注释;糟糕的注释;注释掉的代码; 2、环境 需要多步才能实现的构建;需要多步才能做到的测试 3、函数 避免过多的参数;输出参数;标识参数;死函数 4、一般性问题 一个源文件中存在多种语言;明显的行为未被实现;不正确的边界行为;忽视安全;重复;在错误的抽象层及上的代码;基类依赖派生类;信息过多;死代码;垂直分隔;前后不一致;混淆视听;人为耦合;特性依恋;选择算子参数;晦涩的意图;位置错误的权责;不恰当的静态方法;使用解释性变量;函数名称应该表达

2022-02-23 20:20:09 97

原创 第十四章 逐步改进

要编写整洁代码,必须要先写肮脏代码,然后清理他。就像写作文,要先写草稿,再写二稿,一次又一次的草撰,直至写出终稿。 毁坏程序最好的方法之一是借改进之名大动其结构。为了避免这种状况发生,采用测试驱动开发规程,这种方法的核心原则之一是保持系统始终能运行。 ...

2022-02-22 20:20:48 151

原创 第十三章 并发编程

并发是一种解耦策略,帮助我们把做什么和何时做分开。解耦目的和时机能明显的改进应用程序的吞吐量和结构。 单一权原则认为,方法、类、组件应当只有一个修改的理由。 避免共享数据的还方法之一是,从开始就避免共享数据。 让每个线程在自己的世界中存在,不与其他线程共享数据。 ...

2022-02-21 20:29:00 131

原创 《代码整洁之道》--第十二章 迭进

关于简单设计的四条规则 ·运行所有测试 ·不可重复 ·表达了程序员的意图 ·尽可能减少类和方法的数量

2022-01-05 20:00:19 167

原创 《代码整洁之道》--第十一章 系统

将系统的构造与使用分开,方法之一是将全部构造过程搬迁到main或被称之为main的模块中,设计系统的其余部分时,假设所有对象都以正确构造和设置。 有一种强大的机制可以实现分离构造与使用,那就是依赖注入。控制反转在依赖管理中的一种应用手段。控制反转将第二权责从对象中拿出来,转移到另一个专注于此的对象中,从而遵循了单一权原则。 ...

2022-01-04 20:16:51 307

原创 《代码整洁之道》-- 第十章 类

遵循标准的java约定,类应该从一组变量列表开始。如果有公共静态常量,应该先出现。然后是私有静态变量,以及私有实体变量。很少会有公共变量。 类应该短小。 单一权原则:类或模块应该有且只有一条加以修改的理由 类应该只有少数实体变量,类中的每个方法都应该操作一个或多个这种变量,保持内聚性就会得到许多短小的类。 ...

2021-12-22 20:45:45 350

原创 《代码整洁之道》--第九章 单元测试

TDD三定律 第一定律:在编写不能通过的单元测试前,不可编写生产代码 第二定律:只可编写刚好无法通过的单元测试,不能编译也算不通过 第三定律:只可编写刚好通过当前失败测试的生产代码 单元测试可以让代码可扩展、可维护、可扩用 整洁测试三要素:可读性,可读性。。。还是可读性(皮),在单元测试中可读性甚至比在生产代码中更重要。如何才能做到可读:明确,简洁,并有足够的表达力。 每个测试一个断言,每个测试一个概念 ...

2021-12-15 20:29:48 384

原创 《代码整洁之道》--第八章 边界

在接口提供者和使用者之间,存在与生俱来的矛盾。第三方程序包和框架提供者追求普适性,这样就能在多种环境中工作,从而吸引广泛用户。 建议不要将map在系统中传递。如果使用类似map这样的边界接口,就把他保留在类或近亲类中。 避免从公共api中返回边界接口,或将边界接口作为参数传递给公共api。 学习型测试:不要在生产代码中实验新东西,而是编写测试来遍览和理解第三方代码。 边界上的代码需要清晰的分割和定义了期望的测试。应该避免我们的代码过多的了解第三方代码中的特定信息。 ...

2021-12-08 20:25:06 317

原创 《代码整洁之道》--第七章 错误处理

使用异常而不是返回码。遇到错误时,最好抛出一个异常,这样调用代码会很整洁,其逻辑不会被错误处理搞乱。 异常的妙处之一是,他们在程序中定义的范围。 你抛出的每个异常,都应当提供足够的环境说明,以便判断错误的来源和位置。 对异常的的分类有很多方式,可以依其来源分类,也可依其类型分类。 创建一个类或配置一个对象,用来处理特例。 避免返回null值,避免传递null值 ...

2021-12-02 20:28:31 216

原创 《代码整洁之道》--第六章 对象和数据结构

隐藏实现并非只是在变量之间放上一个函数层那么简单,隐藏实现关乎抽象。这并不意味只是用接口或赋值器、取值器就万事大吉。随意乱加赋值器和取值器是最坏的选择。 过程式代码(使用数据结构的代码)便于在不改动既有数据结构的前提下添加新函数;面向对象代码便于在不改动现有函数的前提下添加新类。 得莫忒耳律:模块不应了解它所操作对象的内部情形。 最为精炼的数据结构,是一个只有公共变量,没有函数的类。 ...

2021-11-24 19:41:09 318

原创 《代码整洁之道》--第五章 格式

格式的目的:增强代码的可维护性和可扩展性,在代码的不断迭代中,保证风格和律条。 1、垂直格式。 1.1向报纸学习,源文件要像报纸一样,简单且一目了然。 1.2垂直方向上的区隔,用和空行作为代码组的区隔 1.3垂直方向上的靠近,紧密相关的代码应互相靠近而不是用空行区分 1.4垂直距离,变量声明应尽可能靠近其使用位置、实体变量应该在类的顶部声明、相关函数,调用者应尽可能放在被调用者上面、概念相关的代码应放在一起 1.5垂直顺序 2、横向格式 2.1水平方向上的区隔与靠近,用空格字符将紧密相关的食

2021-11-16 19:48:30 231

原创 《代码整洁之道》--第四章

什么也比不上放置良好的注释有用。什么也比不上乱七八糟的注释更有本事搞乱一个模块。什么也不会比陈旧、提供错误信息的注释更有破坏性。 带有少量注释的整洁而有表达力的代码,要比带有大量注释的零碎而复杂的代码像样的多。 有些注释是必须的,不过要记住,唯一真正好的做法是想办法不写注释。 好注释包括:法律信息、提供信息的注释、对意图的解释、阐释、警示、todo注释、放大某种看起来不合理之物的重要性、公共api中的javadoc 大多数注释都是坏注释,都是糟糕代码的支撑或借口,或是对错误决策的修正,例如:误导性注

2021-11-09 20:46:16 263

原创 《代码整洁之道》--第三章

函数的第一条规则是要短小,月简短的函数越好。 函数应该做一件事,做好这件事,只做一件事。 每个函数一个抽象层级。自顶向下读代码:向下规则。这是保持函数短小,确保只做一件事的要诀。 使用具有描述性的名称,函数越短小,功能越集中,就越便于起个好名字。别害怕长名称,长而具有描述性的名称,要比短而令人费解的名称好。 ...

2021-11-03 20:03:42 94

原创 《代码整洁之道》-第二章

名副其实 代码段的命名应赋予代码本身应有的意义,这并不影响代码的整洁度,而是模糊度。一个好的命名,是不会触及到代码整洁度的 避免误导 程序员必须避免留下掩藏代码本意的错误线索,应当避免使用与本意相悖的词。例如字母I和O,常被误认为是1和0 做有意义的区分 不能为了满足编译器的需要而进行命名,要以读者能鉴别不同之处的方式来区分 使用读的出来的名称 使用可搜索的名称 长名称的搜索度要优于短名称 ...

2021-10-27 19:56:35 108

原创 《代码整洁之道》-第一章

糟糕的代码会毁了一家公司,为了赶进度,追时间,造成的代码混乱与收益成反比,得不偿失 首先程序员应具有守卫意识,应该以项目经理护卫进度同等的热情护卫代码。在追进度或实现需求的同时,充分考虑技术可行性。 赶上进度,做得更快的唯一办法,就是保持代码整洁。 --------------------“让营地比你来时更干净”...

2021-10-20 19:46:56 126

空空如也

空空如也

TA创建的收藏夹 TA关注的收藏夹

TA关注的人

提示
确定要删除当前文章?
取消 删除