自定义博客皮肤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 132

原创 第十四章 逐步改进

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

2022-02-22 20:20:48 174

原创 第十三章 并发编程

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

2022-02-21 20:29:00 160

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

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

2022-01-05 20:00:19 200

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

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

2022-01-04 20:16:51 337

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

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

2021-12-22 20:45:45 378

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

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

2021-12-15 20:29:48 433

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

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

2021-12-08 20:25:06 353

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

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

2021-12-02 20:28:31 252

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

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

2021-11-24 19:41:09 341

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

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

2021-11-16 19:48:30 270

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

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

2021-11-09 20:46:16 288

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

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

2021-11-03 20:03:42 128

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

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

2021-10-27 19:56:35 138

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

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

2021-10-20 19:46:56 157

空空如也

空空如也

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

TA关注的人

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