Boss有句口头禅：“XXXX做得不solid”！由于这个[‘salid’]读音很发人深省因此在我们同事之间广为流传！
今天在调试的时候，很流利地重写了一些代码，令人费解的是死活不出结果，自我感觉应该很solid呀，刚刚才发现是为了调试json结构体的type其中两种情况true和false的意义，将需要处理的json文件多添加了一行“lihui”：why，当时为了确认如果是true/false是满足json的结构定义，而修改成why是不满足的，而重新写的时候，下面这个判断被我抛弃了：
if (!json){
printf(“Error before: %s\n”, cJSON_GetErrorPtr());
return;
}
如此一来，在将数据传入到json结构体的时候，由于格式出错中途已经退出了，所以json已经是null了，后面不会再处理了；而加上这行就会立马打印出错误的地点，尽管可以gdb一步一步跟到底哪一步出错，但是cJSON_Parse处理步骤还是挺多的，刚就浪费了很多时间，无形就是一个效率的问题，其实我觉得更是习惯问题
一直大部分写的都是各种脚本语言，各种库都封装的很solid，用起来也很懒散，比如按自己想象就能写对的perl，还有比较好动手的python，只为了简单实现功能，而不考虑其写得够不够完美，其实还说不上完美，应该说够不够完整，其实都差太远
今天涛哥说了一句 if [“$a”x =“$2”x ]，后面的x是干啥的，我随口说了句就是字符串对比，x可以不加，我从来就没加，过后试了试，现在的shell貌似这个真的问题不大，但是在网上也搜出来了这段话：if [ “$test”x = “test”x ];注意到”$test”x最后的x，这是特意安排的，因为当$test为空的时候，上面的表达式就变成了x = testx，显然是不相等的。而如果没有这个x，表达式就会报错：[: =: unary operator expected
不管是否需要，这种思路是十分solid的，在做判断的时候，首先无形中判断了下变量本身非空，容错性考虑的更周到
对自己而言，如何写的更solid，这点十分需要加强，实现10个功能，5个所有出错情况都没考虑到，那么也没啥意义，得在平时一点一滴积累中改善
