
代码坏味道
隐官城头坐
我有一个梦想,我写的代码可以像诗歌一样优美。
展开
-
代码坏味道:夸夸其谈通用性
夸夸其谈通用性指的是为了未来可能的扩展或复用,过度设计和实现了许多当前并不需要的功能或抽象。这种做法会导致代码复杂度增加,难以维护和理解,而这些所谓的“通用性”在未来很可能并不会被用到。原创 2024-05-27 23:04:50 · 345 阅读 · 0 评论 -
代码坏味道:循环语句
循环语句(如forwhile等)虽然是编程中常用的控制结构,但在某些情况下,循环语句可能会导致代码难以理解和维护。这种坏味道指的是循环语句包含复杂的逻辑、多个嵌套层次,或者可以用更高层次的操作(如集合操作、流操作等)来替代,以提高代码的可读性和可维护性。原创 2024-05-26 12:36:18 · 344 阅读 · 0 评论 -
代码坏味道:重复的switch
重复的switch指的是在代码的多个地方使用相同的switch (或if-else) 语句来做不同的操作。这种坏味道会导致代码的重复和难以维护。如果需要修改某个条件或添加新条件,就需要在每个switch语句处进行修改,容易引入错误和不一致。原创 2024-05-26 12:34:42 · 387 阅读 · 0 评论 -
代码坏味道:基本类型偏执
等)来表示复杂的数据,而不使用自定义的类型。这样会导致代码缺乏清晰的语义,难以维护和扩展。当基本类型的使用方式开始变得复杂或频繁时,通常意味着需要引入新的类型来封装这些基本数据。通过引入值对象和自定义类型,可以消除基本类型偏执的坏味道,增强代码的表达能力和可维护性。基本类型偏执指的是过度使用基本类型(如。原创 2024-05-26 10:06:16 · 573 阅读 · 0 评论 -
代码坏味道:数据泥团
数据泥团指的是多个数据项经常一起出现,并且在多个地方一起传递或处理。这种情况通常表明这些数据具有某种内在的关联,应该被封装成一个对象。数据泥团会导致代码的冗余和难以维护,因为每次修改都需要在多个地方进行相同的调整。通过引入对象将数据泥团封装起来,可以减少代码的冗余,提高代码的内聚性和可维护性。原创 2024-05-26 10:01:53 · 737 阅读 · 0 评论 -
代码坏味道:依恋情节
依恋情节指的是一个类频繁地访问另一个类的数据或方法,而不是使用自身的数据和方法。这通常表明功能实现可能放在了错误的类中。依恋情节会导致类之间的高度耦合,降低代码的可维护性和可读性。通过将方法移动到更合适的类中,可以减少依恋情节的坏味道,提高代码的内聚性和可维护性。原创 2024-05-26 09:59:48 · 503 阅读 · 0 评论 -
代码坏味道:散弹式修改
散弹式修改指的是对某一个功能的修改需要在多个不同的类或模块中进行小幅度的修改。这样的代码结构增加了维护的复杂性,因为一次简单的功能修改可能会涉及到多个类或模块的调整,容易出错并且难以追踪和测试。通常这也是违反单一职责原则(Single Responsibility Principle, SRP)的表现。通过将相关的功能聚合到一个类或模块中,可以有效减少散弹式修改的坏味道,提高代码的可维护性和可读性。原创 2024-05-26 09:53:29 · 387 阅读 · 0 评论 -
代码坏味道:发散式变化
发散式变化指的是一个模块需要因为多种不同的原因而发生变化。这通常意味着这个模块承担了过多的职责,违反了单一职责原则(Single Responsibility Principle, SRP)。当一个模块需要频繁地因为不同的原因进行修改时,维护起来会变得非常困难,增加了出错的可能性。通过遵循单一职责原则和模块化设计,可以有效减少发散式变化的坏味道,提高代码的可维护性和可读性。原创 2024-05-26 09:34:27 · 761 阅读 · 0 评论 -
代码坏味道:可变数据
通过使用不可变对象、减少共享状态和封装可变数据,可以提高代码的可读性、可维护性和安全性。可变数据指的是可以在程序运行过程中被修改的数据。原创 2024-05-26 09:30:29 · 339 阅读 · 0 评论 -
代码坏味道:全局数据
通过避免使用全局数据,可以提高代码的可维护性、可读性和可测试性。全局数据指的是在程序中定义的、可以被任意代码访问和修改的全局变量。原创 2024-05-26 09:26:26 · 375 阅读 · 0 评论 -
代码坏味道:过长的参数列表
过长的参数列表指的是函数或方法的参数数量过多,导致函数调用变得复杂和难以理解。过长的参数列表通常表明该函数承担了过多的职责,或是相关的数据没有很好地封装在一起。通过减少参数数量,可以提高代码的可读性和可维护性。通过引入参数对象、使用对象的属性或拆分函数,可以有效减少函数的参数数量,提高代码的可读性和可维护性。原创 2024-05-26 09:22:10 · 410 阅读 · 0 评论 -
代码坏味道:过长函数
过长的函数是指函数的代码行数过多,包含了太多的逻辑和细节,使得函数难以理解、维护和测试。过长的函数通常意味着函数承担了太多职责,违反了单一职责原则(SRP)。通过将过长的函数拆分为多个小函数,可以提高代码的可读性、可维护性和可测试性。通过将过长的函数拆分为多个小函数,可以提高代码的可读性和可维护性。原创 2024-05-26 09:19:24 · 431 阅读 · 0 评论 -
代码坏味道:重复代码
通过识别和消除重复代码,可以提高代码的可维护性和可读性。通过重构,可以将重复代码提取到一个公共函数或类中,减少重复,提高代码的可维护性。重复代码指的是相同或非常相似的代码出现在多个地方。原创 2024-05-26 09:17:07 · 478 阅读 · 0 评论 -
代码坏味道:神秘命名
神秘命名指的是代码中的变量、函数、类等命名不明确,不能清楚地传达其用途或意图。这样的命名会使代码难以理解和维护,因为开发者需要花费额外的时间去推测这些命名的含义。良好的命名应该清晰、简洁,并且能够准确反映其功能或用途。神秘命名会增加代码的认知负担,使得其他开发者(包括未来的自己)难以理解代码的意图和功能。通过采用有意义的、描述性的命名,可以显著提高代码的可读性和可维护性。原创 2024-05-26 09:11:13 · 300 阅读 · 0 评论