项目组里的代码审查员要我把代码写的很啰嗦，怎么办？
遇到这种情况确实让人头疼，代码审查员要求写“啰嗦”的代码，这与我们通常追求的简洁、高效的代码风格背道而驰。然而，在某些特定场景下，审查员可能有他们的考虑。作为项目组的一员，我们需要理解并找到一个平衡点。以下我将详细地分析这种情况，并提供应对策略：
首先，理解审查员为什么会要求“啰嗦”的代码
在直接给出应对方法之前，我们必须尝试去理解审查员的“啰嗦”指令背后可能的原因。这有助于我们更有针对性地解决问题。以下是一些常见的可能性：
新手保护/易读性极高：
原因： 项目组可能有新加入的开发者，或者项目本身对新成员的上手要求非常高。审查员可能认为，将所有逻辑都写得非常明确，避免过多的抽象和简写，有助于新人更快地理解代码的流程和意图。
“啰嗦”表现： 详细的变量命名，详尽的注释，拆分成非常小的函数，使用更通俗的语言描述逻辑，避免使用简写（如 `i++` 可能被要求写成 `i = i + 1`）。
调试和维护的便捷性：
原因： 审查员可能更看重代码的后期可维护性和调试的便利性。过于简洁的代码，尤其是在没有足够文档或单元测试的情况下，可能会让未来的维护者（包括自己）感到困惑。
“啰嗦”表现： 添加大量的日志输出，明确地检查每一个潜在的错误或异常情况，将复杂的逻辑拆分成更小的、有明确职责的单元，即使某些代码块可能看起来有点重复。
特定框架或团队规范要求：
原因： 有些框架或团队可能有一套非常严格的代码规范，其中就包含了对代码详尽程度的要求。这可能是历史遗留问题，也可能是为了统一风格而强制执行的。
“啰嗦”表现： 强制性的命名规则，大量的代码模板，要求使用特定的代码模式，即使有更简洁的替代方案。
审查员个人偏好或经验：
原因： 有些审查员可能有自己的编码习惯和偏好，他们可能更倾向于自己熟悉的风格，或者他们过去遇到的问题让他们对某种代码风格产生了执念。
“啰嗦”表现： 纯粹的个人喜好，可能并不一定基于客观的技术考量。
对某些抽象或魔法值的规避：
原因： 审查员可能不希望看到过多的“魔法值”（直接写在代码中的字面量，如数字、字符串）或者过于复杂的抽象（如设计模式的过度使用）。
“啰嗦”表现： 要求将魔法值提取成常量并添加注释，或者将复杂的抽象分解成更易于理解的步骤。
如何应对审查员要求“啰嗦”代码
理解了原因之后，我们就可以有针对性地采取行动了。以下是一些详细的应对策略：
1. 积极沟通，理解具体要求
这是最重要也是最直接的步骤。不要猜测，直接找审查员进行沟通。
如何做：
主动约谈或发起讨论： 不要只通过代码审查工具的评论来回应。可以找个时间，或者在团队的日常会议上，主动询问审查员对“啰嗦”的具体定义和期望。
举例说明： 准备一些你认为“不啰嗦”的代码片段，并向审查员展示，询问他们希望如何修改。同时，也可以让他们举例说明他们期望的“啰嗦”风格。
询问“为什么”： 在了解他们的要求后，一定要追问“为什么”这样写。例如：“您希望我在这里添加更多的日志，是为了方便以后跟踪问题吗？”或者“您希望将这个函数拆分成更小的单位，是为了提高代码的可读性，还是为了降低耦合度？” 了解背后的原因才能更好地满足需求。
记录反馈： 将审查员的明确要求和理由记录下来，这不仅有助于你本次修改，也能为今后团队的编码风格提供参考。
沟通示例：
“您好 [审查员名字]，关于您之前提出的代码风格建议，我希望能更详细地了解一下。您提到的‘啰嗦’，具体是指希望我增加更多注释吗？还是希望将函数拆得更细？或者在变量命名上更具体？我这边有一段代码（展示代码片段），您看是希望像这样（修改后的代码片段）写吗？我希望能更好地理解您的意图，确保代码符合团队的规范和您的期望。”
2. 针对性地调整代码，满足审查员的期望
根据沟通结果，有针对性地修改代码。
增加详细的注释：
何时使用： 当代码逻辑比较复杂、非显而易见，或者可能包含一些特殊的处理逻辑时。
如何做：
解释“是什么”和“为什么”： 不要只描述“做什么”，更要解释“为什么这么做”，尤其是在有一些“黑魔法”或非直观的解决方案时。
关键变量的含义： 如果有含义比较抽象或重要的变量，添加注释说明其用途和可能的取值范围。
复杂算法的说明： 如果使用了复杂的算法或设计模式，可以用注释简要说明其原理。
临时的解决方案或TODO： 如果是临时的解决方案，或者有未来需要重构的计划，用 `// TODO:` 或 `// FIXME:` 标记清楚。
“啰嗦”示例：
```java
// 这是一个临时的解决方案，用于绕过 XXX 服务的bug。
// 待 XXX 服务修复后，此代码块可以移除并使用标准的 API 调用。
// 临时的 bug 修复逻辑，处理 YYY 参数为 null 的情况
if (params.getYyy() == null) {
// 当 YYY 参数为空时，我们假定其值为默认值 'default_value'
// 这是为了兼容老版本API，老版本API在某些情况下会发送 null 值
String yyyValue = "default_value"; // 设定默认值
// ... 处理 yyyValue ...
} else {
// ... 标准处理 ...
}
```
相比之下，不啰嗦的代码可能是：
```java
String yyyValue = params.getYyy();
if (yyyValue == null) {
yyyValue = "default_value";
}
// ... 处理 yyyValue ...
```
拆分函数/方法：
何时使用： 当一个函数承担了过多的职责（Violates Single Responsibility Principle），或者函数过长难以阅读时。
如何做： 将复杂的逻辑拆分成更小、更具内聚性的函数，每个函数只做一件事情。
“啰嗦”示例：
一个包含数据获取、数据处理、数据验证、数据存储的函数，可以拆分成：
`fetchData()`
`processData(data)`
`validateData(processedData)`
`saveData(validatedData)`
然后在一个新的函数中按顺序调用它们：
```java
public void executeDataProcess() {
// 1. 获取数据
DataModel data = fetchData();
// 2. 处理数据
ProcessedData processedData = processData(data);
// 3. 验证数据
if (!validateData(processedData)) {
// 错误处理
return;
}
// 4. 保存数据
saveData(processedData);
}
```
相比之下，不啰嗦的代码可能是一个大函数直接完成所有事情。
明确的变量和函数命名：
何时使用： 当变量或函数的意图不明确时。
如何做： 使用更具描述性的名字，避免使用单个字母的变量名（除非是标准的循环变量如 `i`, `j`）。
“啰嗦”示例：
将 `usr` 改为 `currentUser` 或 `loggedInUser`。
将 `proc` 改为 `processUserData`。
将 `processData(data)` 改为 `processUserDataAccordingToBusinessRules(userData)`。
显式检查和错误处理：
何时使用： 在关键路径、可能出现异常的地方，或者对外部输入的处理。
如何做： 对方法的返回值进行检查，对可能抛出异常的代码块使用 `trycatch`，并且在 `catch` 块中提供详细的错误信息。
“啰嗦”示例：
```java
// 不啰嗦
String result = service.doSomething();
// ... 使用 result ...
// 啰嗦
String result = null;
try {
result = service.doSomething();
if (result == null) {
// 记录日志，因为服务返回了null，这可能不是预期的行为
logger.warn("Service returned null unexpectedly.");
// 考虑抛出异常或使用默认值
// throw new BusinessException("Service returned null");
}
} catch (ServiceUnavailableException e) {
// 记录详细的异常信息和上下文
logger.error("Failed to execute doSomething due to service unavailability.", e);
// 抛出更通用的业务异常，或者返回错误码
throw new MyBusinessOperationException("Service unavailable", e);
} catch (TimeoutException e) {
logger.error("Request to service timed out.", e);
throw new MyBusinessOperationException("Service timed out", e);
}
// ... 使用 result ... (此时需要确保 result 不是 null，或者根据上一步的逻辑处理)
```
避免使用语言特性带来的“捷径”：
何时使用： 当审查员对某些高级语言特性不熟悉，或者认为这些特性降低了可读性时。
如何做： 比如，如果允许使用 Lambda 表达式，但审查员认为不直观，可以要求写成传统的匿名内部类或者独立的实现类。如果允许使用装饰器模式，但审查员觉得难以理解，可以要求直接将功能合并。
“啰嗦”示例：
使用 `foreach` 循环可能被要求改成带有索引的 `for` 循环，以便于在循环中访问索引。
使用 Streams API 的一些复杂操作，可能被要求改成传统的循环迭代。
引入常量和配置：
何时使用： 当代码中存在直接写死的数值（魔法值）或字符串时。
如何做： 将这些值提取到常量类中，并为常量添加注释说明其含义。
“啰嗦”示例：
将 `if (status == 2)` 改为 `if (status == UserStatus.ACTIVE.getCode())`，并且 `UserStatus` 是一个定义了常量和对应含义的枚举类。
3. 建立清晰的团队规范或达成共识
长期来看，解决这类问题需要建立清晰的团队规范。
如何做：
推动制定编码规范： 如果团队还没有明确的编码规范，可以尝试推动大家一起制定一套，其中可以包含关于代码详尽程度的说明，例如：在什么情况下需要添加注释，函数长度的最大限制，是否推荐某些简洁的语法等。
引入代码风格检查工具： 使用 SonarQube, ESLint, Checkstyle 等工具，并配置好规则，可以自动化的强制执行团队的编码风格。
团队内部讨论： 对于一些存在争议的风格问题，可以在团队内部进行讨论，达成一致。
4. 在必要时进行“优雅的妥协”与“适度的坚持”
这是一个艺术性的平衡。
优雅的妥协： 如果审查员的要求在技术上合理，或者仅仅是个人偏好但影响不大，并且能够帮助项目团队的整体效率，那么适当的妥协是值得的。将他们的反馈视为一种成长的机会。
适度的坚持： 如果审查员的要求明显违背了通用的最佳实践，或者会显著降低代码的可读性、可维护性，甚至引入新的bug，那么你需要适当地坚持自己的观点，并提供充分的理由和证据。
如何坚持：
提供对比和数据： 如果你认为你的方案更优，可以准备一些实际的对比例子，说明你的方法在可读性、性能、可维护性方面的优势。
引用权威资料： 引用业界公认的编程书籍、技术博客或标准，来支持你的观点。
寻求第三方意见： 如果团队内无法达成一致，可以请一位经验丰富、中立的资深开发者或架构师来仲裁。
关注点在“为什么”： 再次强调，理解审查员的“为什么”非常重要。如果他们是为了项目的长期健康，那么适当的“妥协”是值得的。如果仅仅是个人喜好，那么适度的“坚持”更有必要。
5. 持续学习和反思
将这次经历作为一个学习和反思的机会。
反思： 为什么我的代码会引发这样的反馈？我的代码是否存在一些我没有意识到的问题？
学习： 学习审查员的优点，理解他们为什么会这样写，将这些优点融入自己的编码习惯中。同时，也反思自己的编码风格是否还有提升空间。
总结
当代码审查员要求你写“啰嗦”的代码时，最关键的是积极沟通，理解其背后的意图。一旦理解了原因，就可以有针对性地进行调整，比如增加注释、拆分函数、使用更明确的命名等。同时，也要思考如何建立更清晰的团队规范来避免此类沟通成本。在处理过程中，要学会优雅的妥协与适度的坚持，最终目标是写出既符合团队要求，又易于理解和维护的高质量代码。
这是一个挑战，但也是一个提升你沟通能力、理解需求以及提升编码技巧的机会。祝你顺利解决这个问题！
首先，理解审查员为什么会要求“啰嗦”的代码
在直接给出应对方法之前，我们必须尝试去理解审查员的“啰嗦”指令背后可能的原因。这有助于我们更有针对性地解决问题。以下是一些常见的可能性：
新手保护/易读性极高：
原因： 项目组可能有新加入的开发者，或者项目本身对新成员的上手要求非常高。审查员可能认为，将所有逻辑都写得非常明确，避免过多的抽象和简写，有助于新人更快地理解代码的流程和意图。
“啰嗦”表现： 详细的变量命名，详尽的注释，拆分成非常小的函数，使用更通俗的语言描述逻辑，避免使用简写（如 `i++` 可能被要求写成 `i = i + 1`）。
调试和维护的便捷性：
原因： 审查员可能更看重代码的后期可维护性和调试的便利性。过于简洁的代码，尤其是在没有足够文档或单元测试的情况下，可能会让未来的维护者（包括自己）感到困惑。
“啰嗦”表现： 添加大量的日志输出，明确地检查每一个潜在的错误或异常情况，将复杂的逻辑拆分成更小的、有明确职责的单元，即使某些代码块可能看起来有点重复。
特定框架或团队规范要求：
原因： 有些框架或团队可能有一套非常严格的代码规范，其中就包含了对代码详尽程度的要求。这可能是历史遗留问题，也可能是为了统一风格而强制执行的。
“啰嗦”表现： 强制性的命名规则，大量的代码模板，要求使用特定的代码模式，即使有更简洁的替代方案。
审查员个人偏好或经验：
原因： 有些审查员可能有自己的编码习惯和偏好，他们可能更倾向于自己熟悉的风格，或者他们过去遇到的问题让他们对某种代码风格产生了执念。
“啰嗦”表现： 纯粹的个人喜好，可能并不一定基于客观的技术考量。
对某些抽象或魔法值的规避：
原因： 审查员可能不希望看到过多的“魔法值”（直接写在代码中的字面量，如数字、字符串）或者过于复杂的抽象（如设计模式的过度使用）。
“啰嗦”表现： 要求将魔法值提取成常量并添加注释，或者将复杂的抽象分解成更易于理解的步骤。
如何应对审查员要求“啰嗦”代码
理解了原因之后，我们就可以有针对性地采取行动了。以下是一些详细的应对策略：
1. 积极沟通，理解具体要求
这是最重要也是最直接的步骤。不要猜测，直接找审查员进行沟通。
如何做：
主动约谈或发起讨论： 不要只通过代码审查工具的评论来回应。可以找个时间，或者在团队的日常会议上，主动询问审查员对“啰嗦”的具体定义和期望。
举例说明： 准备一些你认为“不啰嗦”的代码片段，并向审查员展示，询问他们希望如何修改。同时，也可以让他们举例说明他们期望的“啰嗦”风格。
询问“为什么”： 在了解他们的要求后，一定要追问“为什么”这样写。例如：“您希望我在这里添加更多的日志，是为了方便以后跟踪问题吗？”或者“您希望将这个函数拆分成更小的单位，是为了提高代码的可读性，还是为了降低耦合度？” 了解背后的原因才能更好地满足需求。
记录反馈： 将审查员的明确要求和理由记录下来，这不仅有助于你本次修改，也能为今后团队的编码风格提供参考。
沟通示例：
“您好 [审查员名字]，关于您之前提出的代码风格建议，我希望能更详细地了解一下。您提到的‘啰嗦’，具体是指希望我增加更多注释吗？还是希望将函数拆得更细？或者在变量命名上更具体？我这边有一段代码（展示代码片段），您看是希望像这样（修改后的代码片段）写吗？我希望能更好地理解您的意图，确保代码符合团队的规范和您的期望。”
2. 针对性地调整代码，满足审查员的期望
根据沟通结果，有针对性地修改代码。
增加详细的注释：
何时使用： 当代码逻辑比较复杂、非显而易见，或者可能包含一些特殊的处理逻辑时。
如何做：
解释“是什么”和“为什么”： 不要只描述“做什么”，更要解释“为什么这么做”，尤其是在有一些“黑魔法”或非直观的解决方案时。
关键变量的含义： 如果有含义比较抽象或重要的变量，添加注释说明其用途和可能的取值范围。
复杂算法的说明： 如果使用了复杂的算法或设计模式，可以用注释简要说明其原理。
临时的解决方案或TODO： 如果是临时的解决方案，或者有未来需要重构的计划，用 `// TODO:` 或 `// FIXME:` 标记清楚。
“啰嗦”示例：
```java
// 这是一个临时的解决方案，用于绕过 XXX 服务的bug。
// 待 XXX 服务修复后，此代码块可以移除并使用标准的 API 调用。
// 临时的 bug 修复逻辑，处理 YYY 参数为 null 的情况
if (params.getYyy() == null) {
// 当 YYY 参数为空时，我们假定其值为默认值 'default_value'
// 这是为了兼容老版本API，老版本API在某些情况下会发送 null 值
String yyyValue = "default_value"; // 设定默认值
// ... 处理 yyyValue ...
} else {
// ... 标准处理 ...
}
```
相比之下，不啰嗦的代码可能是：
```java
String yyyValue = params.getYyy();
if (yyyValue == null) {
yyyValue = "default_value";
}
// ... 处理 yyyValue ...
```
拆分函数/方法：
何时使用： 当一个函数承担了过多的职责（Violates Single Responsibility Principle），或者函数过长难以阅读时。
如何做： 将复杂的逻辑拆分成更小、更具内聚性的函数，每个函数只做一件事情。
“啰嗦”示例：
一个包含数据获取、数据处理、数据验证、数据存储的函数，可以拆分成：
`fetchData()`
`processData(data)`
`validateData(processedData)`
`saveData(validatedData)`
然后在一个新的函数中按顺序调用它们：
```java
public void executeDataProcess() {
// 1. 获取数据
DataModel data = fetchData();
// 2. 处理数据
ProcessedData processedData = processData(data);
// 3. 验证数据
if (!validateData(processedData)) {
// 错误处理
return;
}
// 4. 保存数据
saveData(processedData);
}
```
相比之下，不啰嗦的代码可能是一个大函数直接完成所有事情。
明确的变量和函数命名：
何时使用： 当变量或函数的意图不明确时。
如何做： 使用更具描述性的名字，避免使用单个字母的变量名（除非是标准的循环变量如 `i`, `j`）。
“啰嗦”示例：
将 `usr` 改为 `currentUser` 或 `loggedInUser`。
将 `proc` 改为 `processUserData`。
将 `processData(data)` 改为 `processUserDataAccordingToBusinessRules(userData)`。
显式检查和错误处理：
何时使用： 在关键路径、可能出现异常的地方，或者对外部输入的处理。
如何做： 对方法的返回值进行检查，对可能抛出异常的代码块使用 `trycatch`，并且在 `catch` 块中提供详细的错误信息。
“啰嗦”示例：
```java
// 不啰嗦
String result = service.doSomething();
// ... 使用 result ...
// 啰嗦
String result = null;
try {
result = service.doSomething();
if (result == null) {
// 记录日志，因为服务返回了null，这可能不是预期的行为
logger.warn("Service returned null unexpectedly.");
// 考虑抛出异常或使用默认值
// throw new BusinessException("Service returned null");
}
} catch (ServiceUnavailableException e) {
// 记录详细的异常信息和上下文
logger.error("Failed to execute doSomething due to service unavailability.", e);
// 抛出更通用的业务异常，或者返回错误码
throw new MyBusinessOperationException("Service unavailable", e);
} catch (TimeoutException e) {
logger.error("Request to service timed out.", e);
throw new MyBusinessOperationException("Service timed out", e);
}
// ... 使用 result ... (此时需要确保 result 不是 null，或者根据上一步的逻辑处理)
```
避免使用语言特性带来的“捷径”：
何时使用： 当审查员对某些高级语言特性不熟悉，或者认为这些特性降低了可读性时。
如何做： 比如，如果允许使用 Lambda 表达式，但审查员认为不直观，可以要求写成传统的匿名内部类或者独立的实现类。如果允许使用装饰器模式，但审查员觉得难以理解，可以要求直接将功能合并。
“啰嗦”示例：
使用 `foreach` 循环可能被要求改成带有索引的 `for` 循环，以便于在循环中访问索引。
使用 Streams API 的一些复杂操作，可能被要求改成传统的循环迭代。
引入常量和配置：
何时使用： 当代码中存在直接写死的数值（魔法值）或字符串时。
如何做： 将这些值提取到常量类中，并为常量添加注释说明其含义。
“啰嗦”示例：
将 `if (status == 2)` 改为 `if (status == UserStatus.ACTIVE.getCode())`，并且 `UserStatus` 是一个定义了常量和对应含义的枚举类。
3. 建立清晰的团队规范或达成共识
长期来看，解决这类问题需要建立清晰的团队规范。
如何做：
推动制定编码规范： 如果团队还没有明确的编码规范，可以尝试推动大家一起制定一套，其中可以包含关于代码详尽程度的说明，例如：在什么情况下需要添加注释，函数长度的最大限制，是否推荐某些简洁的语法等。
引入代码风格检查工具： 使用 SonarQube, ESLint, Checkstyle 等工具，并配置好规则，可以自动化的强制执行团队的编码风格。
团队内部讨论： 对于一些存在争议的风格问题，可以在团队内部进行讨论，达成一致。
4. 在必要时进行“优雅的妥协”与“适度的坚持”
这是一个艺术性的平衡。
优雅的妥协： 如果审查员的要求在技术上合理，或者仅仅是个人偏好但影响不大，并且能够帮助项目团队的整体效率，那么适当的妥协是值得的。将他们的反馈视为一种成长的机会。
适度的坚持： 如果审查员的要求明显违背了通用的最佳实践，或者会显著降低代码的可读性、可维护性，甚至引入新的bug，那么你需要适当地坚持自己的观点，并提供充分的理由和证据。
如何坚持：
提供对比和数据： 如果你认为你的方案更优，可以准备一些实际的对比例子，说明你的方法在可读性、性能、可维护性方面的优势。
引用权威资料： 引用业界公认的编程书籍、技术博客或标准，来支持你的观点。
寻求第三方意见： 如果团队内无法达成一致，可以请一位经验丰富、中立的资深开发者或架构师来仲裁。
关注点在“为什么”： 再次强调，理解审查员的“为什么”非常重要。如果他们是为了项目的长期健康，那么适当的“妥协”是值得的。如果仅仅是个人喜好，那么适度的“坚持”更有必要。
5. 持续学习和反思
将这次经历作为一个学习和反思的机会。
反思： 为什么我的代码会引发这样的反馈？我的代码是否存在一些我没有意识到的问题？
学习： 学习审查员的优点，理解他们为什么会这样写，将这些优点融入自己的编码习惯中。同时，也反思自己的编码风格是否还有提升空间。
总结
当代码审查员要求你写“啰嗦”的代码时，最关键的是积极沟通，理解其背后的意图。一旦理解了原因，就可以有针对性地进行调整，比如增加注释、拆分函数、使用更明确的命名等。同时，也要思考如何建立更清晰的团队规范来避免此类沟通成本。在处理过程中，要学会优雅的妥协与适度的坚持，最终目标是写出既符合团队要求，又易于理解和维护的高质量代码。
这是一个挑战，但也是一个提升你沟通能力、理解需求以及提升编码技巧的机会。祝你顺利解决这个问题！
网友意见
我有时也会写成这样
boolean flag = getMboValue().isNull(); if (flag) { this.getMboValue("vendor").setReadOnly(false); } else { this.getMboValue("vendor").setReadOnly(true); } 原因是这样方便下断点调试，比如 flag是true为正常，false是异常情况需要调试。写成一行断点就不好下了。
我也不反对这种情况直接写成一行，只要命名合理逻辑清晰可读就好
我反对以下这样一行的写法：
foo.setDisable( ! (bar.isEnable() && this.getValue().isNull()) ); 肯定、否定、并且、取反来回兜几个圈后我脑子就冒烟了，智商欠费。
首先，很显然的代码审查员的建议写法除了增加代码量之外，在可读性方面并没有太多的提升，甚至因为代码量的提升带来更多的心智负担和出错的概率。
例如因为某个奇怪的失误把代码写成了这样：
boolean flag = getMboValue().isNull(); if (flag) { this.getMboValue("vendor").setReadOnly(false); } else { this.getMboValue("vendor").setReadOnly(false); } 所以，原本一个可能出现问题的地方现在变成了四五个。
除此之外，flag的命名不够meaning，而我也倾向于移除这个变量，毕竟这个表达式并不长。但与上面不同的是，我个人会建议完全弃用 ! 运算符，原因是这个运算符实在是太不够明显了。所以我个人建议的写法是：
this.getMboValue("vendor").setReadOnly( getMboValue().isNotNull() ); 增加一个isNotNull方法来使得语义更为清晰。
或者：
this.getMboValue("vendor").setReadOnly( getMboValue().hasValue() ); 在无法增加方法的情况下，我也会建议用 == false来代替 ! ，因为在字面上这样会更难以被忽略：
this.getMboValue("vendor").setReadOnly( getMboValue().isNull() == false ); 比较一下：
this.getMboValue("vendor").setReadOnly( !getMboValue().isNull() ); 很显然上面的写法在提醒看的人，嘿，哥们儿注意点，我这里是反的。
当然，抛开代码审查员的问题，作为一个一无所知的程序员来重新审视这段代码，我会发现Mbo这个缩写其实会非常的令人费解，而且getMboValue这个方法实在是出现了太多次，另外为代码中一个有this，另一个没有this，让这段逻辑更加离奇。
最后，童鞋你写大括号的习惯我很欣赏，趁着你们的代码审查员还没有让你把所有的大括号都变成半展开之前，赶紧换工作投入大C#的怀抱吧……到时候同样的代码可能只需要写成这样就可以了：
mbo["vendor"].ReadOnly = mbo["vendor"] != null;
类似的话题
本站所有内容均为互联网搜索引擎提供的公开搜索信息，本站不存储任何数据与内容，任何内容与数据均与本站无关，如有需要请联系相关搜索引擎包括但不限于百度，google,bing,sogou 等
© 2025 tinynews.org All Rights Reserved. 百科问答小站 版权所有