前言

今天 code review 时发现某个同事的代码中存在滥用try catch的现象。其实这种行为我们也许都经历过，刚参加工作想尽量避免出现崩溃问题，因此不可避免得想在所有可能抛出异常的地方都try catch一下。

当然，这种行为肯定是不可取的。如果这样，那还不如所有逻辑都包在大大的try catch里好了。代码的是否具有高健壮性必然是代码是否高效优雅决定的。

当然，这个也引起我的思考，try catch会影响性能么？

结论

try catch不会影响性能。——严格意义上说是微乎其微。

这个结论的确很难让人接受，最起码与我的预估不大一样。

按照我的想法，当代码中出现的各种特性越多，轻量点的如enum，重一点的如“反射”，必然会增加更多的开销。

然而，从结果看，在没有抛出异常时，try catch的影响跟添加了一个 if else是同一个量级的。也就是说，我们完全可以忽视try catch耗费的那点性能。

前言

对于Android开发者来说，序列化总是一个不能避免的问题。前有“使用enum实现单例模式可以自动序列化”的观点，后有“在Intent传输过程中使用Parcelable进行序列化可以减少性能损耗”的思考。

由此，我们很有必要找到应对各种场景的最佳实践。

本文中我们谈谈Serializable 和 Parcelable。

结论

二话不说先说结论（就是这么直接干脆）：序列化的数据仅需在内存中传输的，使用Parcelable；反之，如果需要持久化或者网络传输等等的，请使用Serializable。

论述

Serializable相信大家不会陌生，从Java中就有这个接口存在。Serializable接口是一种标识接口，它的迷人之处在于，你只要让需要序列化的类实现该接口，Java便会对该类进行高效的序列化。

今天是2016年处于工作时间内的第一个星期天——暂且忽略包含在元旦假期内的3号吧。每次跨越一个年头，第一个要头疼的就是每次写日期的时候不得不提醒一遍自己，现在是新的一年了。

以往的习惯，也是要写一写年度总结的，不过都是在农历新年的夜里、在爆竹声声辞旧岁的氛围中，写下一些文字发在自己的QQ空间里。

而今年，本来是不准备再写了的。一方面是身份的转变，似乎看清了一些东西，不必把事事都演化成习惯，让自己背负着前进；另一方面是有了一种明悟，生活之精彩，实在不是文字所能表达，强行给经历贴上一段似是而非的记录，反而局限了记忆中事物的万千变化。

但今天，突然想写点什么。

博客搭建在github上，形式不错，但是没有了一个固定的编辑器。恰巧注册了简书，就写在这里吧。既然提到了身份的转变，就以这点开始好了。

表驱动法是一种编程模式——从表里查找信息而不是使用逻辑语句（if 和 case）。事实上，凡是能通过逻辑语句来选择的事务，都可以通过查表来选择。对简单的情况而言，使用逻辑语句更为容易和直白。但随着逻辑链的越来越复杂，查表法也就愈发显得更具吸引力。

表驱动法使用总则

例子一：
使用复杂的逻辑对字符分类

if((('a' <= inputChar) && (inputChar <= 'z')) || 
(('A' <= inputChar) && (inputChar <= 'Z‘）））{
    charType = CharacterType.Letter;
}else if ((inputChar == ' ') || (inputChar == ',') || (inputChar == '.') || (inputChar == '!') || (inputChar == '(') || (inputChar == ')') || (inputChar == ':') || (inputChar == ';') || (inputChar == '?') || (inputChar == '-')) {
    charType = CharacterType.Punctuation;
} else if (('0' <= inputChar) && (inputChar <= '9')){
    charType = CharacterType.Digit;
}

使用一个查询表，就可以把每个字符的类型保存在一个用字符编码访问的数组里，那么上述代码可以替换为：

charType = charTypeTable[ inputChar ];

使用表驱动法，必须要解决两个问题。

1，怎样从表中查询条目。 比如你希望把数据按月进行分类，那么创建一个月份表是非常直截了当的，你可以用一个下标从 1 到 12 的数组实现它。而另一些数据可能很难直接用于查表。

2，你应该在表里存些什么。有
时候，表查询出来的结果是数据，有时候，表查询出来的结果是动作，或者有时候，查出来的是子程序的引用。无论何种情况，表都会变得更为复杂。

一，选择好变量名的注意事项

一个好的变量名是可读的、易记的和恰如其分的。可以通过应用多条原则来实现这些目标。

1，最重要的命名注意事项

为变量命名时最重要的考虑事项是，该名字要完全、准确地描述出该变量所代表的事物。获得好名字的一种使用技巧是用文字表达变量所代表的是什么。

2，以问题为导向

一个好名字通常表达的是“什么”，而不是“如何”。

3，最适当的名字长度

平均名字长度在 8 到 20 个字符的程序容易调试。当然这并不意味着你应该尽量把变量名控制到这个范围。它强调的是，如果你查看自己写的代码时发现了很多更短的名字，那么你需要认真检查，确保这些名字含义足够清晰。

4，变量名对作用域的影响

较长的名字适用于很少用到的变量或者全局变量，而较短的名字则适用于局部变量或者循环变量。

对位于全局命名空间中的名字加以限定词。