随想

前面讲了kotlin的it变量引起的遮蔽问题，见Kotlin it隐式变量的遮蔽问题，本篇聊聊作用域函数（scoped function）可能引起的遮蔽问题。 先来看一个简单的示例： 这里涉及3个上下

在Java中lambda表达式的参数/局部变量和类的成员变量是会发生遮蔽（Shadow）现象的，但是lambda的参数/局部变量不会，即便发生多层嵌套（这样会报错，无法通过编译）： 不过在kotlin

由于kotlin支持类型推导，所以很多时候变量的类型可以省略，但有时候省略变量类型又可能带来一些不便，甚至隐患。本文记录下一些“建议声明类型”、“可以省略类型”的场景。（暂时想到的不多，后续持续更新）

Kotlin是一个宣称与Java兼容性较好的语言，但在接触后发现一些技术还是有“概念上”的冲突，本文就记录下两者对象的Field在继承中的不同表现。

最近看到两段相似的代码，两段代码的差别仅在启动线程的位置。 有时候写程序比较随意的时候，两种形式的代码都可以可能出现，下面记录下我对这种形式的一些想法。

在Android开发中，我们经常使用Android SDK提供的Handler类来完成线程间通信的任务，但是项目代码中，经常看到Handler过于随意地使用，这些使用可能有一些隐患，本文记录下这些问题

之前在翻译学习EOPL过程中回顾以前的代码时发现一个让人后背发凉的隐患，一种极其罕见、但是一旦出现就难以发现并可能造成非常大影响的bug，本文就记录下这个问题。

最近看了篇关于新技术风险的文章，结合自身经历，反思并总结下项目中应用所谓“新技术”的一些想法。（后面想到了再补充） 何为“新技术” 谈论“新技术”这个词的时候，很少深入、明确地解释这个词的意义。在我看

在平时开发中，相信大家都见过大量的这样的代码： 或者是另一种形式： 但是这种程序看上去是在为安全考虑，但是却包含了一些隐患。文本就分享一些我对这类隐患的一些思考。（本文以判空为示例，这种想法可以延伸到

回想起刚开始做Android开发工作时，有一个烦恼：当拿到一个新项目的时候，想从界面的跳转来梳理整个App的功能，结果发现根本没有对应的产品文档，然后代码中启动Activity的代码散落在Activi

平时的Android开发中，我们经常要在Fragment中去获取当前的Activity实例，刚开始的时候可能使用使用Fragment提供的getActivity方法来获取，但是这个方法可能返回null

最近在开发中遇到一个关于Java方法重写的一些问题，对于方法重写的用法以及可能导致的问题产生了一些思考，本文用于记录下这些想法。

随着集成开发环境越来越强大，编程开发工作也变得越来越高效，很多的代码都不需要逐字输入，可以利用代码生成和自动补全来辅助开发。但是这样的便利也可能引起一些疏忽

最近看到自己以前写的代码，很多的if表达式用作防御，没有写else，看的时候产生一些疑惑，还有一些想法，由本文记录这些想法。

几年前发生过一件事，当时被老东家裁员已经过去半年，然后有一天下班后在公交车上收到前同事的来电，问我一个功能写在哪里，我直接告诉他去X类里搜索AABBCC名称的一个dialog，显示这个对话框的下面一行

写完上一篇关于else-if子句的陷阱后，想起来以前还遇到过类似的关于else子句以及switch表达式中default条件的陷阱，本文就记录这个问题，并给出相关解决方案/建议。

if表达式/语句大概是所有开发者日常用到的语法中最多的，但最近在看以前的代码时想到到一个很容易发生但开发的时候经常忽略的问题，本文就记录下这个问题，并在最后提出一些建议。

变量声明方式的一些思考 在学习很多编程语言后，发现虽然大部分语言都支持变量声明，而且语义都一样，但是声明的语法却有很多种。正好近期也在设计这样的语法，就结合过去接触的语言来阐述自己的感想。

说起函数式编程，不得不提的是First-class Function的概念，有些文章把它翻译成“第一类函数”，有些是“一等函数”，我更倾向于“一等函数”，因为这种名字更能体现出“一等数据类型”的概念。

以前听过过一个有趣的说法：不要编写没有明显bug的代码，要去编写明显没有bug的代码。这里提到的两个概念：“没有明显bug的代码”和“明显没有bug的代码”。本文记录对这个话题的一些随想