case2：4个数据源定义，该用谁呢
代码示例：
声明1：
public interface IR4UDataSource { .... }
声明2：
public interface RecommendIDataSource { .... }
声明3：
public interface IRecommendDataResource { .... }
声明4：
public class RecmdDataSource { .... }
大脑活动：
4个推荐数据源，其中有3个是接口声明，为什么接口定义了不能多态，不能复用接口的声明？这三代的抽象好像有一丢丢失败。
代码跟读：
homepage 包下的 IR4UDataSource，和非常古老的首页曾经爱过，线上实际不会使用；Recommend2 包下的“RecommendIDataSource” 属于收藏夹，但也属于古老版本，收藏夹不在使用；
Recommend3 包下的“IRecommendDataResource” 确实是首页场景推荐使用，但也是曾经的旧爱；
原来当今的真命天子是Recommend3包下的“RecmdDataSource”，一个使用俏皮缩写未继承接口的实体类，看来是已经放弃伪装。
修改建议：
......
3.3 避免使用具有不同含义但却有相似名字的变量
case1 : 大家都是view，到底谁是谁
代码示例：
public void showOverlay(@NonNull View view ...) { ... View rootView = getRootView(view); DxOverlayViewWidget dView = createDxOverlayViewWidget(); dView.showOverLayer(view.getContext(), (ViewGroup)rootView, cardData, itemData); ... }
代码跟读：
代码中存在3个以view结尾的局部变量，rootView、view 、 dView，其中 view 和 dView 之间只有一个字母的差异，方法如果长一点，view 和 dView 使用频率在高一点，掺杂着rootView会让人抓狂。另外dView也并不是一个view，实际是个DXViewWidget。
修改建议：
public void showOverlay(@NonNull View hostView ...) { ... ViewGroup parentView = getParentView(hostView); DxOverlayViewWidget dxOverlayViewWidget = createDxOverlayViewWidget(); dxOverlayViewWidget.showOverLayer(hostView.getContext(), parentView, ...); ... }
4.使用读的出来的名称
使用读的出来的名称，而不是自造词，这会给你无论是记忆，还是讨论需要说明是哪个方法时，都能带来便利。可以使用达成共识的缩写，避免造成阅读障碍。
4.1 避免使用令人费解的缩写
Case1：接口定义中的俏皮缩写
代码示例：
/** * Created by *** on 16/8/6. */ public interface IR4UDataSource { .... }
大脑活动：
R4U是什么？ R4和Recommend4这个目录有什么关系，难道是购后推荐的数据源定义吗？那U又代表什么？
代码跟读：原来R4U是Recommend For You的俏皮写法
修改建议：
public interface IRecommendForYouDataSource { .... }
Case2：成员变量命名的缩写
代码示例：
.... // 标题指示器（indicators） private LinearLayout mTabLL; private TabLayout mTabLayout; ....
大脑活动：
“mTabLL”是什么呢？有注释！难道mTabLL是指示器视图？“LL“”也不像是indicators的缩写，喔，LL是LinearLayout的首字母缩写。嗯，使用LinearLayout自定义做成指示器有点厉害！诶，不对，好像TabLayout更像是个选项卡式指示器的样子。
代码跟读：
原来“mTabLL” 下面声明的 “mTabLayout”才是指示器视图，“mTabLL”只是指示器视图的父视图。还好“mTabLayout”没有缩写成“mTabL”，导致和“mTabLL”傻傻分不清，作者已然是手下留情了。
修改建议：
.... private LinearLayout mTabLayoutParentView; private TabLayout mTabLayout; ....
Case3：局部变量命名的缩写
代码示例：
.... for (PageParams.GroupBuckets ss:params.groupBucketIds.values()) { if (ss != null) { bucketIds.removeAll(ss.bucketIdsAll); Collections.addAll(bucketIds, ss.currentBucketIds); } } ....
大脑活动：
"ss"是什么鬼，是不是写错了，GroupBuckets首字母缩写是“gb”，PageParams和GroupBuckets 的首字母缩写是“pg”
这难道是，PageParams 和 GroupBuckets 的尾字母缩写，在一个圈复杂度为18的方法中看到尾字母缩写“ss”？啊！好难受。
修改建议：
for (PageParams.GroupBuckets groupBuckets :params.groupBucketIds.values()) { if (groupBuckets != null) { .... } }
5、使用可搜索的名称
若变量或常量可能在代码中多处使用，则应赋其以便于搜索的名称。
5.1 给魔法值赐名
Case1： 数字魔法值没法搜索也看不懂
代码示例：
public static void updateImmersiveStatusBar(Context context) { .... if (TextUtils.equals(isFestivalOn, "1")) { if (TextUtils.equals(navStyle, "0") || TextUtils.equals(navStyle, "1")) { .... } else if (TextUtils.equals(navStyle, "2")) { .... } } .... }
大脑活动：
对于TextUtils.equals(isFestivalOn, "1") ，我还能猜测一下这里的“1” 代表开关为开的意思。那TextUtils.equals(navStyle, "0"/"1"/"2") 中的“0”，“1”，“2” 我该如何知道代表什么意思？老板，请不要再问我为什么需求吞吐率不高，做需求慢了，可能是因为我的想象力不够。
修改建议：
实际上，协议约定时就不应该以 “0”，“1”，“2” 这类无意义的数字做区分声明。
public static final String FESTIVAL_ON = "1"; public static final String NAV_STYLE_FESTIVAL = "0"; public static final String NAV_STYLE_SKIN = "1"; public static final String NAV_STYLE_DARK = "2"; public static void updateImmersiveStatusBar(Context context) { .... if (TextUtils.equals(isFestivalOn, FESTIVAL_ON)) { if (TextUtils.equals(navStyle, NAV_STYLE_FESTIVAL) || TextUtils.equals(navStyle, NAV_STYLE_SKIN)) { .... } else if (TextUtils.equals(navStyle, NAV_STYLE_DARK)) { .... } } .... }
