看《unix编程艺术》总结的出色程序员十大良好习惯
1)易于理解,利于组合。
2)“只做好一件事”
3)想清楚代码的组合,如何构建自己的一套API.(更加深入地理解真实世界系统状态。重构)
4)【目前紧缺】:对事物形式化清晰描述与理解的能力。并将其流程图,伪代码化(到了这步,写代码就是技术活了,基本可以查阅资料,尝试,试验,请教人而完成)
1)模块,封装和最佳模块大小
强内聚弱耦合:让你解决小问题的时候尽量少的去牵连其他问题。
模块不能太大:
模块不能太小:不然就得编写很多接口。传递很多参数。而传递参数的思维成本,代码量都比较大。
2)先定义函数名字,函数参数,返回值,返回类型;再为该函数API写注释。通常写注释的过程中,你会将事情说清楚。
3)紧凑性:一个API设计,一个模块设计,能否轻松或者比较轻易地装入人脑的特性。如果不手册就可以看懂这个函数,那最美妙不过了。一套API,而不是一个。如同list.h中所实现的,看到名字就可以了解个程序的大概。其它的我只要查阅即可,而不须了解全貌。易于理解,利于组合。
4)名字起得好与不好关系很大。因为这涉及到能否易于理解,易于分类。而分类对后续工作的影响很大。
5)正交性:每一个动作(API)只改变一件事,不会影响其它。改变每个属性的方法有且仅有一个。
“只做好一件事”
6)重构(重复代码):修改内部代码时,而不影响引函数的外在行为。
“不要重复自身,真理的单点性”:重复会导致前后矛盾,产生问题,因当你修改重复点时,往往只修改了一部分而并非全部。通常,这也意味着你对代码的组织并没有想清楚。
可通过重构去除重复代码;如果有大量的重复样板代码,是不是可以用单一的更高层表现形式生成这些代码、然后通过提供不同的细调选项生成不同个例?【代码生成器】
7)SPOT原则。倡导一个数据结构,使得模型中的状态跟真实世界系统的状态能够一一对应。
“无混淆”:真实世界绝对清晰明确的状态在模型中也应该绝对清晰明确;
“无垃圾”:数据结构(模型)不能设计得太通用,应该合就好。
"解决一个定义明确的问题":强单一中心。
“形式法”,“试探法”
8)简洁性:清瘦如禅般的简洁性。
禅教导我们:依附导致痛苦;
Unix说:分离产生价值。
9)模块内的单个函数是不是太大了?这个与行数,与内部复杂性都有关。判别标准:如果不能用一句话简单描述一个函数与其调用函数间的约定,那这个函数就可能太大了。
就我个人而言,若局部变量太多,就倾向于拆分成子程序。
*代码是不是有内部API?好的API应是意义清楚,不用看内部具体如何实现就可以理解的。如果存在多层嵌套调用函数,应该警惕了。
“透明性和可见性清单”
10)在写函数原型之后立即写一行注释,每个函数都是这样。《编程风格的元素》(the Elements of Programming Style)
11)协作进程:将复杂应用程序划分成几个协作进程,通过应用程序专用命令集或协议通信。
==========================
6 透明性:来点儿光
=========================
1)美在计算科学中的地位,要比在其它任何技术中的地位都重要,因为软件是太复杂了。美是抵御复杂的终极武器。
2)可显性:对用户而言,良好的文档有助于提高可显性;对程序员而言,良好的变量名和函数名有助于提高可显性。在软件中仅仅做到“不晦涩”是不够的,还必须尽力做到“有帮助”。
*如果程序设计使内部数据流程非常容易理解。
3)优雅的代码:优雅的代码不仅正确,而且显然正确;优雅的代码不仅将算法传达给计算机,同时也把见解和信心传递给阅读代码的人。
通过追求代码的优雅,我们能够编写更好的代码。学习编写透明的代码是学习如何编写优雅代码的第一关,很难的一关。
==============================================
感想分类二:关于复杂度的一些新思考与术语概念
==============================================
1)问题本身很复杂
2)通过例程来学习apue是比较简单,直观而有驱动力,成就感的。
3)是什么增加了问题的复杂性?哪些原理?
组合的多样性;
思考不深入,结构的影响;
4)原型开发要做哪几件事情?顺序地做?循环递归地做?
分析业务(要做什么,有什么限制,要实现什么功能),定义一套API函数名及参数,逐个实现并逐个测试;
5)复杂度是要花代价的,拼命不遗力气地减小它。
6)特定清晰性。清楚。明白。简洁。秩序。考察。观察。
7)灵活应用这些API,并且体会为何如此设计。从内核和应用两个层次上体会。不要眼高手低。因为我是靠后者吃饭的。而前者是体验痛快的。呵呵。