7种过时的编码方式：告别陈旧观念，拥抱新兴趋势

1. 用m或this来表示成员变量

曾经的规则： 为了区分成员变量和局部变量，需要在成员变量前加上m或this前缀。

问题： 这种做法在小项目中可能还行，但在大型项目中，很容易导致代码的可读性和维护性下降。当项目中的类和成员变量数量不断增加时，这种命名方式会变得非常冗长和混乱。

替代方案： 使用更具性的变量名，清楚地表明变量的作用和所属的类。例如，可以将成员变量命名为firstName、lastName、age等，这样可以提高代码的可读性和可维护性。

2. 在变量名中使用下划线

曾经的规则： 在变量名中使用下划线来提高代码的可读性。

问题： 这种做法在某些情况下可能有用，但如果过度使用，反而会降低代码的可读性和可维护性。过多的下划线会使变量名变得冗长和难以记忆，尤其是当变量名本身已经很长的时候。

替代方案： 尽量使用驼峰命名法或匈牙利命名法来命名变量。驼峰命名法将每个单词的首字母大写，而匈牙利命名法则在变量名前加上一个前缀来表示变量的类型或作用。这两种命名方式都可以提高变量名的可读性和可维护性。

3. 在方法名中使用动词

曾经的规则： 在方法名中使用动词来清楚地表达方法的功能。

问题： 这种做法在某些情况下可能有用，但如果过度使用，反而会降低代码的可读性和可维护性。在某些情况下，使用动词作为方法名可能会导致方法名过于冗长，难以记忆。

替代方案： 尽量使用更具性的方法名，清楚地表明方法的功能和作用。例如，可以将方法名命名为calculateTotalCost、getEmployeeDetails等，这样可以提高代码的可读性和可维护性。

4. 在类名中使用形容词

曾经的规则： 在类名中使用形容词来描述类的属性或功能。

问题： 这种做法在某些情况下可能有用，但如果过度使用，反而会降低代码的可读性和可维护性。在某些情况下，使用形容词作为类名可能会导致类名过于冗长，难以记忆。

替代方案： 尽量使用更具描述性的类名，清楚地表明类的作用和功能。例如，可以将类名命名为Employee、Customer、Order等，这样可以提高代码的可读性和可维护性。

5. 使用复杂的继承层次结构

曾经的规则： 使用复杂的继承层次结构来组织代码。

问题： 这种做法在某些情况下可能有用，但如果过度使用，反而会降低代码的可读性和可维护性。复杂的继承层次结构会使代码难以理解和维护，尤其是在项目规模较大的时候。

替代方案： 尽量使用更简单的继承层次结构，或者使用组合或聚合的方式来组织代码。组合和聚合可以使代码更加灵活和易于维护。

6. 使用全局变量

曾经的规则： 在程序中使用全局变量来共享数据。

问题： 这种做法在某些情况下可能有用，但如果过度使用，反而会降低代码的可读性和可维护性。全局变量会使代码难以理解和维护，尤其是在项目规模较大的时候。

替代方案： 尽量使用局部变量或对象成员变量来存储数据。局部变量和对象成员变量可以提高代码的可读性和可维护性。

7. 使用过多的注释

曾经的规则： 在代码中使用过多的注释来解释代码。

问题： 这种做法在某些情况下可能有用，但如果过度使用，反而会降低代码的可读性和可维护性。过多的注释会使代码难以理解和维护，尤其是当注释本身已经过时或不准确的时候。

替代方案： 尽量使用更简洁和准确的注释来解释代码。注释应该清晰地解释代码的功能和作用，而不应该包含过多的细节或不必要的信息。