程序设计中的一些感悟

这篇感悟写的不错,特此转贴

1)学习应该从基础打起,不要一开始就尝试最高深的技术。

2)每看一本书,不要说这章我以前学习过了,也掌握的很好,因此我可以跳过这一章看更重要的了。

3)对于作业,遇到不会的尽量不要立刻向别人请教。如果实在解决不了的问题,可以先完成你会的,然后把一些特别的难点提炼出来,向高手请教。

3)不要指望书本和行家能帮你解决一切问题,因为并不是所有问题都能由别人教给你。

4)向别人请教问题应该把问题说明白。对于错误提示信息应该原样提供出来,不要按自己理解的信息提供。因为既然你自己做不了,说明你理解一般都有问题。

5)问问题最好能带代码。

6)不要说“编译通过,可是运行时...",因为编译错误和运行错误可能根本没有关系。一般来说,编译是语法问题,而运行是逻辑问题。

7) 书看千遍不如做程序一遍,应该尽量尝试去写程序。

8)做程序千个不如做好程序一个。应该尽量完善你现在做的程序,而不要不断开新的计划,而每个计划都虎头蛇尾。

9)要想到你不是一个人写程序,而是和大家一起写程序。

10)高深的技巧虽然显示了高深的本领,但是对于合作往往是有害的,应该尽量写出简单易读的代码。

11)编制程序应该尽量做到自注释,即代码本身一读就懂,好象自己在说明自己的逻辑一样。

12)复杂的代码如果实在做不到自注释,应该给出适量的注释。

13)注释在修改代码的时候应该相应修改,不能用陈旧的注释去误导别人。

14)代码应该尽量可重用,相同功能的代码应该由相同的函数完成,重要函数应该给出调试信息,以便调试时及早发现问题。

15)应该尽量写小函数,每个函数尽量不要超过40行或者更少。这样不用滚动屏幕也许就可以读完整个函数。

16)对于switch语句,尽量不要有过多的分支,如果分支太多,可以考虑用跳转表。

17)尽量少使用一些有争议的语句,如goto和三目运算符,既然有争议,它肯定有一定的缺点。

18)对于goto,许多工程师技术高到可以合理使用,而不至于导致问题。但是你的程序并不一定给你同水平的人看和修改,他们可不能保证合理的读和修改这些相关代码。

19)代码编写时应该有一定的格式,其基本要求是对理解代码有一定帮助。

20)如果数据是多个模块共有的,应该提供一个封装的类来管理它,并提供一个合适的接口给各个模块。这样,如果数据内容有重大修改,则只要接口不变,基本上可以保证程序不要很复杂的修改。

21)应该尽量考虑到数据的并发控制。

22)数据的并发控制应该封装在接口内,而不要暴露给其他模块,这样可以减少因为并发原因导致的程序死锁。

23)数据本身结构不可以太复杂。应该尽量把不相关的数据分割成为两组数据。

24)对于数据量比较大的情况,应该考虑数据库。

25)数据库接口应该采用标准ODBC或者ADO接口,尽量不要根据实际数据库DBMS提供的接口来处理,因为你可能在实际使用中更换DBMS。

26)小的数据可以考虑文件,文件路径应该必须设计成相对路径。

27)在一个函数中,应该尽量打开文件后使用完后立刻关闭,这样其他程序可能使用文件。

28)不要尝试把文件全部读到内存中,应该分次处理大文件。

29)编写程序应该提供相关的测试程序,以提供测试手段。

30)应该考虑代码、函数的使用情况,不要超越函数可以使用的范围使用之。

随便写了这么点,呵呵,应该是比较凌乱的,也不完全,希望大家不要见笑。

程序设计中的一些感悟

时间: 2024-10-28 08:45:06

程序设计中的一些感悟的相关文章

第04章 程序设计中的流程控制

/**第四章 程序设计中的流程控制 @选择语句 形式一:if(条件表达式) 单条语句; 形式二:if(条件表达式){ 语句体;} 形式三:if(条件表达式){ 语句体;}else{ 语句体;} 形式四:if(条件表达式){ 语句体;}else if{ 语句体;} 形式五:if(条件表达式){ 语句体;}else if{ 语句体;}else{ 语句体;}=========================================================================

树结构在程序设计中的运用

                                                                                引言 近年来,由于各种竞赛纷纷采用free-pascal,因此对于算法来说,空间效率上的要求降低了,而对时间效率却提出了更高的要求.这使得选手不仅要娴熟地掌握常规算法,而且要大胆创新,构造更高效的算法来解决问题. 在以往的程序设计中,链式结构采用得较多.的确链式结构有编程复杂度低.简单易懂等优点,但有一个致命的弱点:相邻的两个元素间的联系

程序设计中的命名

[程序设计中的命名] 在设计过程中好的命名不一定但更大可能会带来好的设计,但是如果坏的命名那一定不会给你带来好的设计.在设计过程,如果你发现你很难命名某一个模块,某个方法时,可能你真正遇到的问题不是难命名的问题,而是这个设计是否真的合理,你或许应该花更多的时间来重新设计一下你的模块. 1.名字应该尽量采用名词 Bad:           Happy Good:          Happiness 2.不要使用类似名字空间的前缀 Bad:           SystemOnlineMessa

Java UDP 中 广播的 感悟

多播:很好 但是   有 风险 广播 是有一定 风险的,如果所有的数据 都进行广播的话,有些人 并不像收到 这些数据,就会造成 网络 阻塞. 网络 风暴 后果不堪设想,所有的数据都阻塞, 就像北京的 堵车一样,谁也 别想发送数据. 所以在 广域网里,基本很少用到 广播,就算 用到 的话 也会很小心的. Java UDP 中 广播的 感悟,布布扣,bubuko.com

[转]在C#程序设计中使用Win32类库

http://blog.163.com/j_yd168/blog/static/496797282008611326218/ C# 用户经常提出两个问题:"我为什么要另外编写代码来使用内置于 Windows 中的功能?在框架中为什么没有相应的内容可以为我完成这一任务?"当框架小组构建他们的 .NET 部分时,他们评估了为使 .NET 程序员可以使用 Win32 而需要完成的工作,结果发现 Win32 API 集非常庞大.他们没有足够的资源为所有 Win32 API 编写托管接口.加以测

软件开发过程中的一些感悟

工作快四年了,从事开发工作也有两三年了(头一两年从事设计工作),这期间有些感悟,写下来以备以后回过头来见证自己的成长. 对一个本科学的设计,毕业的时候对于计算机的知识了解甚少的人而言,靠着自学以及同事的帮助能够从事软件开发工作,我自己都感觉到不可思议.这期间不仅有自己奋斗的辛酸,更有成长的快乐.下面说说我自己的一个学习方法,希望对某些人有些帮助. 刚开始的时候因为没有基础,所以在同事的推荐下看了一些基础书籍(感觉谭浩强的书比较好,MFC深入浅出也相当不错),做了一些基本的练习.万丈高楼平地起,基

状态机思路在程序设计中的应用

状态机思路在程序设计中的应用 作者: 张俊  发布时间: 2015-09-13 12:20  阅读: 1314 次  推荐: 3   [收藏] 状态机的概念 状态机是软件编程中的一个重要概念,比这个概念更重要的是对它的灵活应用.在一个思路清晰而且高效的程序中,必然有状态机的身影浮现. 比如说一个按键命令解析程序,就可以被看做状态机:本来在A状态下,触发一个按键后切换到了B状态,再触发另一个键后切换到C状态,或者返回到A状态.这就是最简单的按键状态机例子.实际的按键解析程序会比这更复杂些,但这不影

程序设计中关于异常机制的思考

程序的运行过程从来都不是一帆风顺的,运行期间会遇到各式各样的突发状况,如文件打不开.内存分配错误.数据库连不上等等.作为一个进阶过程中的编程人员,思考和处理例外状况极为重要.因为它在很大程度保证了程序的连贯性和稳定性,并为问题的发现提供支撑. 下面就本人在编程过程中有关异常的编程范式做一下总结. 一.面向过程形式 面向过程式的范式将异常的传递都交于函数的参数与返回值来处理,如: bool func ( const InType& input, OutType& output, string

Qt多线程程序设计中,可使用信号和槽进行线程通信

Qt多线程程序设计中,可使用信号和槽进行线程通信.下面是一个简单的示例. 该程序实现了线程中自定义一个信号和槽,定时1秒发送信号,槽响应后打印一条信息. [cpp] view plain copy  #include <QtCore/QCoreApplication> #include <QThread> #include <stdio.h> class MyThread:public QThread { Q_OBJECT public: MyThread(); voi