移动开发代码规范实战指南

最近帮朋友公司看一个移动端项目，刚打开代码库就有点懵。同一个功能在不同页面写法完全不一样，变量命名像谜语，注释几乎没有。最离谱的是，登录逻辑在三个地方重复出现，改一处就得手动同步另外两处。这种状况其实在小团队里太常见了——前期图快，后期遭罪。

命名不是小事

别小看变量和方法怎么叫。看到 getData() 这种名字就头疼，到底拿的是用户数据还是订单？换成 fetchUserProfile() 或者 loadRecentOrders()，谁看了都明白。类名也一样，别用 Manager、Helper 这种万金油后缀，具体点，比如 ImageCache 比 DataManager 强多了。

结构统一才好维护

团队里有人喜欢把网络请求写在 Activity 里，有人抽成单独的服务类。时间一长，新人根本不知道该往哪加接口。定个规矩：所有 API 调用必须放在 api/ 目录下，按模块分文件。比如用户相关都走 UserApi.java 或 UserService.kt。

class UserApi {
    fun login(username: String, password: String): Call<LoginResponse>
    fun getUserProfile(): Call<UserProfile>
}

空指针是能防的

Kotlin 的可空类型用起来其实挺顺手。别嫌 String? 多了个问号麻烦，它能逼你在编译期就把空值处理好。Java 项目至少加上 @Nullable 和 @NonNull 注解，配合 Lint 检查，能拦住一半线上崩溃。

日志别瞎打

见过满屏都是 Log.d("TAG", "进入方法") 的项目，真出了问题反而找不到重点。统一用个封装过的 Log 工具类，加个开关控制输出级别，上线自动关闭调试日志。关键节点才打印，比如网络请求失败、数据解析异常。

object AppLogger {
    private const val IS_DEBUG = BuildConfig.DEBUG
    
    fun d(tag: String, message: String) {
        if (IS_DEBUG) {
            Log.d(tag, message)
        }
    }
}

资源文件也得管

图片命名别用 img_01.png、icon_new.png 这种。改成 ic_user_avatar.png、btn_submit_pressed.9.png，一眼就知道用途。字符串资源同理，login_hint_email 比 hint_1 明确多了。

自动化检查省力气