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