• Paul Shan
    2022-03-20
    个人觉得Kotlin默认上界定为Any?不好，不符合Kotlin默认安全原则，默认上界应该定为Any，包含可空类型应该明确写。

    作者回复: 确实挺坑的。

    共 3 条评论
    6
  • A Lonely Cat
    2022-02-09
    总结：尽量 val 不可空 ?. ?.let

    作者回复: 言简意赅

    
    6
  • vox
    2022-04-26
    !!. 也可以用takeif的形式来替换吧

    作者回复: 是的，感谢补充

    
    4
  • Paul Shan
    2022-03-20
    Android开发中，在和Service交互的代码中尽量使用nullable类型，因为不能确定服务端返回的数据是否真有，但是要把这一层隔离好，真正的业务逻辑尽量使用non-nullable类型，保持代码的简洁。 请问老师，在测试代码中，能否使用!!？我会在很多测试场景下使用!!，在生产代码中，使用数据的时候会用?.let等方法处理掉，但是测试场景中，如果测试数据已经准备到位，会用!!保持代码的简洁，减少判断，请问这样的使用是否合理? Compose的preview情况下，也会遇到类似的问题，有些数据在生产情况下是不会显示UI，但是为了让preview显示，也会加!!，让编译系统以为数据已经准备好，请问这样的使用是否合理?

    作者回复: 测试环境使用非空断言是可以理解的。

    
    3
  • 神秘嘉Bin
    2022-02-10
    kotlin定义了不可空的入参的方法，java传入了平台类型，这种除了review外一般怎么防范？出现过几次npe了🙈

    作者回复: 使用静态代码检测方案。不过，目前没有现成的开源方案，这需要自己来实现对应的检测规则。

    共 2 条评论
    
  • 24隋心所欲
    2022-10-28 来自河北
    准则二：“绝不适用非空断言”，感觉有点绝对了。非空断言是有合适的使用场景的，只是不滥用就行。如果绝对不使用的话，有时候可能是掩盖bug了而不是解决bug
    
    