之前眼中有代码无产品，现在眼中有产品有代码，什么时候能做到有产品无代码？还需要努力。
刚开始实习的时候，总喜欢在程序中使用*(p+1) =而不是p[1]来给入参，甚至于用来给定义的数组赋值。而且只要是能使用指针的地方，尽量换做指针操作。总以为这样，代码的执行效率高。（不知道怎么记得，指针访问比数组访问效率高，执行速度会稍微快一些。但是实际上指针的访问，需要比数组的访问多额外的步骤）还乐此不疲。
后来发现这样写的代码，在后来阅读时，总是感觉有些不那么好读，看起来代码显得有些凌乱。总安慰自己说，
这样的代码执行效率好。在《C专家编程》中解释p[1]这种形式，总会被编译器改写或解释为*(p+1)。
后来程序写多了，发现很多代码使用数组形式赋值，倒是指针形式赋值的地方，倒是没有那么多见。
从只考虑程序的速度和空间，到考虑程序的可读性和安全性。
但是《代码大全》告诉了对于程序而言，正确性是排第一的，可读性是很重要的，因为任何人都能写出计算机读懂的程序，但是只有高手才能写出人读懂的程序。
现在的大部分编程方法，都是在降低程序的复杂度，提高程序的可读性。因为程序给人看的次数，远远大于编写程序的次数。
与其关心程序局部的优化，不如提高程序整体的性能。根据二八定律，真正的问题，只在于一点。而不在于每一部分都要保证最高性能。
于现在而言，更多时候，是可读性优先，性能其次。
于现在而言，更多时候，是可读性优先，性能其次。
这样可以做到尽快的理解代码，并作出优化。但是反过来，可能理解代码就需要很长时间，造成程序的可维护性低，容易在维护的过程中出现错误。
但是对于Release产品，有些十分注重于性能的部分，必须作出可读性的牺牲。相对于代码，产品更重要。
（《重构》优化与重构
优化着力于提高程序性能，降低可读性；
重构着力于提高程序可读性，可能伴随着性能的下降；）
从《代码大全》了解了《编程精粹》，从《编程精粹》知道了，代码还有安全性。
更明白了，于公司而言，
产品的价值远远大于代码本身，就像正确性远远大于代码其他属性一样。
不安全的代码，带来的是糟糕的产品。随之而来的是无尽的弥补措施。
与其编写自认为质量好的代码，
不如好好做好一个真正安全的代码，
产出一个质量高的产品，更有价值。
从《编程精粹》看到的一个程序优先级列表：
正确性；
可测试性；
全局效率；
可维护性/明晰性（可读性）；
一致性；
大小；
局部效率；
个人表达方式；
个人方便性；
当然，《编程精粹》第一条准则——每条准则都有例外。
这些都是作者在他的时代背景与工作环境下总结出来的，对于我们借鉴性很强。
而熟练乃至灵活使用还是需要大量的工程实践。
去明白，体验，感悟，最终形成适合我们面对的环境的准则。
附：
数组与指针的可交换性：
1、用a这样的形式对数组进行访问，总是被编译器“改写”或解释为像*(a+i)这样的指针访问。
2、指针始终就是指针。它绝不可能改写成数组。你可以用下标访问指针，一般都是指针作为函数参数时，而且你知道实际传递给函数的就是一个数组。
3、在特定的上下文中，也就是它作为函数的参数（也只有这种情况），一个数组的声明可以看作是一个指针。作为函数参数的数组（也就是在一个函数调用中）始终会被编译器修改为指向数组第一个元素的指针。
4、因此，当把一个数组定义为函数参数时，可以选择把它定义为数组，也可以定义为指针。不管选择哪种方法，在函数内部事实上获得的都是一个指针。
5、在其他所有情况中，定义和声明必须匹配。如果定义了一个数组，在其他文件对它进行声明时，也不许把它声明为数组，指针也是如此。
《C专家编程》
1989tie_959541171 2013-9-4 21:35
凤舞天 2013-9-4 02:10
1989tie_959541171 2013-8-27 22:18
用户1406868 2013-8-25 12:00
优良的架构和可读性，安全性之间并不是绝对的互斥关系，高手往往能平衡他们之间的关系
1989tie_959541171 2013-8-14 18:42
1989tie_959541171 2013-8-14 18:39
用户1190628 2013-8-13 08:08
elechi_989135129 2013-8-12 18:24
用户1242848 2013-8-12 08:34
*(p+1) 和p[1]编译后 汇编代码应该是一样的吧，至少用过那么多单片机，没看到编译出来结果有差异，不知道x86是否有差异？ 很有同感，代码可读性 可维护性 可扩展性， 比起那么一些小技巧，要重要很多很多， 那些自认为高超的 类似 ++p=i++ 这样的写法尤其让人讨厌