c语言源码

摘要：让别人指出工作中的错误是需要学习的，并不是天生就会的。我们都自豪于自己的工作，从不乐于承认错误。我们不知道犯了多少错，也不愿意其他人发现这些错误。如果你正着手于建立成功的Peer Review,这些自然的抵触情绪就必须克服。Peer Review是和技术训练类似的社交活动。在一个组织中，逐步灌输Review流程，一定要了解组织文化和成员们所持有的价值观。经理们应当相信花在Review的时间是一种投次，然后为团队安排Review,你要理解为什么某些人并不愿意将自己的工作拿给同事们做详细的审查，而且牢骚不断。你也要向团队和经理说明Peer Review流程，期待的行为，以及大家的帮助对于个人和团队 阅读全文

摘要：6.1数据抽象隐藏实现并非只是在变量之间放上一个函数层那么简单。类并不简单地用getter和setter将变量推向外间，而是暴露抽象接口，以便用户无需了解数据的实现就能操作数据本体。如下面是一个阅读器，需要获取当前阅读进度。接口定义如下： public interface PaperReader { double getTotalPages(); double getCurrentPageIndex(); }而较好的方式是: public interface PaperReader { double getCurrentProgress(); }添加取值及赋值操作是严肅的事。6.2数据、对象的 阅读全文

摘要：读了一下<<人件>>，最大的感触的是软件行业的问题似乎在这二十年没有变化过，作者也提到过软件行业的革新的速度只不过比钢铁企业稍快一点而已，我想应该远不及街头小贩的革新速度。如果是这样，既然这本书被如此推崇，却得到多少实质性的改变呢？ 说到底，这件事完全要看老板怎么看！即便程序员和项目经理再清楚这个行当所谓的真理，又能如何？ 人人都能有个靠窗的位置，人人都不用常加班而平衡地生活，真不知道老美是不是已经享受到了。但看看我们周围，那只能是痴人说梦一般。醒醒吧！变化是一步步进行的，环境也是这样！想要做到如作者期望的那般，还有很长的路要走, 也有一些事情可以在自己能影响的范围内推 阅读全文

摘要：团队应该一致同意采用一套简单的格式规则，可以运用将这些规则自动化的工具。代码格式关乎沟通，而沟通是专业开发者的头等大事。或许你认为“让代码能工作”才是专业开发者的第一优先级。你今天编写的功能，极有可能在下一版本中被修改，但代码的可读性却会对以后可能发生的修改行为产生深远影响。原始代码修改之后很久，其代码风格和可读性仍会影响到可维护性和扩展性。即便代码已不复存在，你的风格和律条仍存活下来。向报纸学习看看写得很好的报纸。从上到下阅读，在顶部，有头条，告诉你故事主题。然后第一段是大纲，接着细节渐次增加。源代码应当一样，名称简单且一目了然。源文件最顶部应该给出高层次概念和算法。细节应该往下渐次展开，直 阅读全文

摘要：马云语录: 世界是由懒人来支撑的！ 懒不是傻懒，如果你想少干， 就要想出懒的方法。 要懒出风格，懒出境界。McConnell在他的<<Code Complete>>提到三种"懒":"实在的懒","开明的懒"以及"一劳永逸的懒"。并说明第三种"懒"才是最具产值的"懒",因为它需要运用工具或者代码来为自己完成任务：这就是工作中的自动化。<<The Pragmatic Programmer>>的作者也有专门章节提到"一切都要 阅读全文

摘要：由pyskydrive工程(http://code.google.com/p/pyskydrive/)中发现的进度条，加了一点修改！import osimport sysimport cmdimport unicodedatafrom threading import Threadfrom time import sleepclass ProgressBar(Thread): """A simple text progress bar control.""" def __init__(self): self.running = Tru 阅读全文

摘要：安装1.安装Python2.下载SendKeys并安装 (http://pypi.python.org/pypi/SendKeys )setup.py --install3.下载pywinauto并安装 (http://pypi.python.org/pypi/pywinauto/0.4.0 )setup.py --install4. 研究pywinauto包中的文档及例子启动应用程序 gWORD2003 = ur"C://Program Files//Microsoft Office//OFFICE11//WINWORD.EXE"app = application.App 阅读全文

摘要：注释的恰当用法是弥补我们在用代码表达意图时遭遇的失败。我们总无法找到不用注释就能表达自我的方法，所以总要有注释，这并不值庆贺。如果你发现自己需要写注释，再想想看是否有办法翻盘，用代码来表达。注释会撒谎。注释存在的时间越久，就离其所描述的代码越远，可能变得全然错误。原因很简单：程序员不能坚持维护注释。程序员应当负责将注释保持在可维护、有关联、精确的高度。我同意这种说法。但我更主张把力气用在写清楚代码上，直接保证无须编写注释。真实只在一处地方有：代码。只有代码能忠实地告诉你它做的事，所以应当减少注释。写注释的常见动机之一是糟糕的代码的存在。我们编写一个模块，发现它令人困扰、乱七八糟。我们告诉自己： 阅读全文