大家帮我看看，这代码是水平。。

认为这种写法好的显然是不写单元测试的那种。三个嵌套 if 你就能搞出 2^3=8 种分支，你有精力去写这么多的 test-case 吗？

能写出这样代码的一般都是逻辑很混乱的那种，不会去整理思考分支结构的前因后果，然后 debug 的时候发现空指针或者报错，然后顺势往里插一个 if 来解决问题。。

降低预期！降低预期！降低预期！
现在 360 行，行行转码农，进来的人水平参差不齐！
只要是能跑，没 bug ，看得懂的代码，都行。别给我出 bug ，别让我半夜起来修生产环境都行！
否正这种代码看多了会脑溢血，你不接受能怎么办捏？帮他改？教他写？那花的不还是你自己的时间么。
有这时间，多刷几部剧不好么。

```java
public class CulContext {

public String member1;
public String member2;
public String name;
public String org;
public String updateTime;

public boolean canChangePartyPositions() {
if (changeCondition()) {
return true;
}
return !Objects.equals(member1, member2);
}

private boolean changeCondition() {
return member2 == null && member1 != null;
}
}
```
===
```java
public class BizService {

public boolean changePositions(CulContext culContext) {
if (culContext.canChangePartyPositions()) {
return changePartyPosition(culContext);
}
return false;
}

private boolean changePartyPosition(CulContext culContext) {
//提前返回降低代码复杂度
//biz
return false;
}
}
```

@darkcode 图床问题,国内能访问到,梯子不能

先说我的观点：尽管代码有优化空间，比如判断条件可以合并，但是其实并不严重，至少这么多楼下来大家看懂这个代码的占多数不是吗？
其次就是楼上说时间久了变成屎山，其实任何代码时间久了不重构都会变成屎山，拿这个举例，如果参数 member 再多几个，判断条件的组合就会爆炸（排列组合 Cmn ），这种时候使用只要还是这样 if else 写再怎么合并条件、提前返回还是看不懂的，这种情况我能想到的解决办法就是使用 **规则引擎** 这种模式去做，将每个判断条件的处理变成一个 handler 。

@starsky007 正解，看评论怎么感觉大家都有点不入行啊

逻辑确实有问题
这里逻辑确实可以简化
mb1 != mb2 && mb1!=null return true
return false

学完重构与代码简洁之道，写出来的代码同事看不懂。（你这代码这么多个 return ，else if 也不嵌套？）年后准备跑路

个人觉得大多数情况，大家眼中只有好深莫测的优美代码和浅显易懂的烂代码。只要能避免 bad case 就不是烂代码。

@lolizeppelin
写 bug 了吧🐶

String mb1 = new String("A");
String mb2 = new String("A");
按你的代码会 return true

代码不够优雅是水平问题
各种特例有考虑到说明已经用心了

封装一个 member 类，把 org 和 name 作为属性，然后实现 swap

提早 return 就行了

```java
if (member1 == null ? member2 == null : !member1.equals(member2)) {
return false;
}
return changePartyPositions(member1, member2, name, org, updateTime);
```

写代码的应该是新手，总体感觉有以下两个问题：
1.方法的设计就有问题，为什么要拆成两个方法，明明就是干一个事情的，入参还都一样
2.一般方法应该就两个部分，一是什么情况下什么也不做直接返回，二是具体要干什么，这些都没考虑清楚，直接根据业务条件来写，后面等业务变化后一定是一坨屎

第一个乍一看不觉得有问题，仔细看发现只是为了 equals 避免空指针写了这么一大堆 if ，改成 Objects.equals 就好。

如果是业务条件需要的类似判断场景，那么像图一这么写两层 if 嵌套其实比楼上一些人的全写到一个 if 括号里更容易阅读。

@tohuer00 合并条件是没问题的，写法上 在 || 换行就能方便阅读了

第二个 感觉 最好不要多层 if 嵌套，这个还好层数不多 不是很复杂。 建议可以反着写 if(a==null) if(b==null)

@hackk 同看不到