可读性和可维护性的一般规则：
尽量拆分长/大的东西。这包括文件，文件夹，方法和模板。拥有许多行/文件/部分表明某些事情做了太多事情，这使得理解，维护和适应变得困难。寻找可以进行拆分的抽象和责任。
避免添加偷渡性代码。要想想新代码的目标是应该去哪里。通过在现有方法/类中添加几行/方法，有时可以很方便地完成任务。也许添加一些“标志”参数来跳过某些方法的某些部分。但是，仅仅因为某个地方是放置这段代码的便利地点并不意味着它就应该在那里 ，要考虑是否应该创建新的方法/类。进一步阅读：Michael Feathers的“ 检测重构勤奋”
避免使用非平凡的嵌套函数/ lambdas。通过将代码提取到顶级或成员函数，通常可以使代码更清晰。
努力只依赖于亲密/相关的事情。改变远程代码/行为不应该破坏事物。在不可避免的情况下，记录这种关系。
分离和封装责任
避免在同一类/方法中混合不同类型的职责。每个人通常都应该承担一种责任。例如，避免将数据结构操作与业务逻辑混合，或者将UI行为逻辑与执行它的DOM操作混合在一起。
避免破坏层的分离。几乎总有一种方法可以实现所需，而不需要求助于此。每层中的概念应该保持抽象（即根本不可见）到更低或更高的层。例如，数据层不了解HTTP请求或响应代码，并且服务层不了解JDBC。请参阅错误处理。
避免违反或绕过应用的设计模式。当模式或其他设计特征到位时，避免绕过，颠覆或拆除它们。
封装应用程序范围的约定。复制看似微不足道的约定性代码会使得它们难以识别、一致地应用和修改。约定可以是功能相关的（例如数字/日期的显示），或代码相关的（例如我们用于实现X的模式）。一些技术可以应用于单个位置（例如，串行器配置），而其他技术可以在单个位置定义，但需要由程序员在相关的地方使用/应用（例如，组件，实用程序功能）。
顺序
一般来说，想一想事情的顺序。以经过深思熟虑的方式对事物（例如方法，配置文件）进行排序，可以更快，更轻松地找到您要查找的内容。这包括确定它是否存在。它还可以帮助您注意到您不想要的相关内容，但应该注意这些内容。大多数事情的最佳顺序不是它们被添加的时间。有些事情需要个人判断，而有些事情需要部分/完全明确（例如字母，生命周期方法）。
按照调用它们的顺序对生命周期方法进行排序。使用一个已经建立和熟悉的顺序是直观的。
将相关方法放在一起。当不需要对文件进行大量导航时，更容易遵循代码正在执行的操作。
将重要代码放在顶部，将不太重要的代码放在底部。这被称为“报纸代码结构”; 从重要（标题）开始，然后按重要性的降序继续阅读（摘要段落，完整文章文本）。它允许读者快速了解文件的关键内容，而无需扫描所有文件。以此为例，构造函数将接近顶部，辅助方法和getter / setter将位于底部。