高质量编程程序员等级划分：看顶级高手如何编程

如何编写高质量的代码！

载选<编程思想> 非程序员 编 著 代码永远会有BUG，在这方面没有最好只有更好。

高效是程序员必须作到的事情，无错是程序员一生的追求。

复用、分而治之、折衷是代码哲学的基本思想。

模块化与面向对象是实现高效无错代码的方法。

高效无错代码需要思想与实践的不断反复。

1.2.1 命名约定 命令规范基本上采用了微软推荐的匈牙利命名法，略有简化。

1． 常量 常量由大写字母和数字组成，中间可以下划线分隔，如 CPU_8051。

2． 变量 变量由小写（变量类型）字母开头，中间以大写字母分隔，可以添加变量域前缀（变量活动域前缀以下划线分隔）。

如： v_nAcVolMin（交流电压最小值）。

变量域前缀见下表 局部变量，如果变量名的含义十分明显，则不加前缀，避免烦琐。

如用于循环的int型变量 i,j,k ；float 型的三维坐标（x,y,z）等。

3． 函数名一般由大写字母开头，中间以大写字母分隔，如SetSystemPara。

函数命名采用动宾形式。

如果函数为最底层，可以考虑用全部小写，单词间采用带下划线的形式。

如底层图形函数：pixel、o以及读键盘函数get_key 等。

4． 符号名应该通用或者有具体含义，可读性强。

尤其是全局变量，静态变量含义必须清晰。

C++中的一些关键词不能作为符号名使用，如class、new、friend等。

符号名长度小于31个，与ANSI C 保持一致。

命名只能用26个字母，10个数字，以及下划线‘_’来组成，不要使用‘$’‘@’等符号。

下划线‘_’使用应该醒目，不能出现在符号的头尾，只能出现在符号中间，且不要连续出现两个。

5． 程序中少出现无意义的数字，常量尽量用宏替代。

1.2.2 使用断言 程序一般分为Debug版本和Release版本，Debug版本用于内部调试，Release版本发行给用户使用。

断言assert是仅在Debug版本起作用的宏，它用于检查“不应该”发生的情况。

以下是一个内存复制程序，在运行过程中，如果assert的参数为假，那么程序就会中止（一般地还会出现提示对话，说明在什么地方引发了assert）。

//复制不重叠的内存块 void memcpy(void *pvTo, void *pvFrom, size_t size) { void *pbTo = (byte *) pvTo; void *pbFrom = (byte *) pvFrom; assert( pvTo != NULL && pvFrom != NULL ); while(size - - > 0 ) *pbTo + + = *pbFrom + + ; return (pvTo); } assert不是一个仓促拼凑起来的宏，为了不在程序的Debug版本和Release版本引起差别，assert不应该产生任何副作用。

所以assert不是函数，而是宏。

程序员可以把assert看成一个在任何系统状态下都可以安全使用的无害测试手段。

以下是使用断言的几个原则： 1）使用断言捕捉不应该发生的非法情况。

不要混淆非法情况与错误情况之间的区别，后者是必然存在的并且是一定要作出处理的。

2）使用断言对函数的参数进行确认。

3）在编写函数时，要进行反复的考查，并且自问：“我打算做哪些假定？”一旦确定了的假定，就要使用断言对假定进行检查。

4）一般教科书都鼓励程序员们进行防错性的程序设计，但要记住这种编程风格会隐瞒错误。

当进行防错性编程时，如果“不可能发生”的事情的确发生了，则要使用断言进行报警。

1.2.3 优化／效率 规则一：对于在中断函数／线程和外部函数中均使用的全局变量应用volatile定义。

例如： volatile int ticks; void timer(void) interrupt 1 //中断处理函数 { ticks++ } void wait(int interval) { tick=0; while(tick<interval); } 如果未用volatile，由于while循环是一个空循环，编译器优化后（编译器并不知道此变量在中断中使用）将会把循环优化为空操作！这就显然不对了。

规则二：不要编写一条过分复杂的语句，紧凑的C++/C代码并不见到能得到高效率的机器代码，却会降低程序的可理解性，程序出错误的几率也会提高。

规则三：变量类型编程中应用原则：尽量采用小的类型（如果能够不用“Float”就尽量不要去用）以及无符号Unsigned类型，因为符号运算耗费时间较长；同时函数返回值也尽量采用Unsigned类型，由此带来另外一个好处：避免不同类型数据比较运算带来的隐性错误。

1.2.4 其他 规则一：不要编写集多种功能于一身的函数，在函数的返回值中，不要将正常值和错误标志混在一起。

规则二：不要将BOOL值TRUE和FALSE对应于1和0进行编程。

大多数编程语言将FALSE定义为0，任何非0值都是TRUE。

Visual C++将TRUE定义为1，而Visual Basic则将TRUE定义为-1。

例如： BOOL flag; … if(flag) { // do something } // 正确的用法 if(flag==TRUE) { // do something } // 危险的用法 if(flag==1) { // do something } // 危险的用法 if(!flag) { // do something } // 正确的用法 if(flag==FALSE) { // do something } // 不合理的用法 if(flag==0) { // do something } // 不合理的用法 规则三：小心不要将“= =”写成“=”，编译器不会自动发现这种错误。

规则四：建议统一函数返回值为无符号整形，0代表无错误，其他代表错误类型。

1.3 模块化的C编程 C语言虽然不具备C++的面向对象的成分，但仍应该吸收面向对象的思想，采用模块化编程思路。

面向对象的思想与面向对象的语言是两个概念。

非面向对象的语言依然可以完成面向对象的编程，想想C++的诞生吧！ C++没有理由对C存在傲慢与偏见，不是任何场合C++方法都是解决问题的良药，譬如面对嵌入式系统效率和空间的双重需求。

注意我们谈的是方法，而不是指编译器。

C在软件开发上存在的首要问题是缺乏对数据存取的控制（封装），C编程者乐而不疲的使用着大量extern形式的全局变量在各模块间交换着数据，“多方便啊”编程者乐曰，并传授给下一个编程者。

这样多个变量出现在多个模块中，剪不断理还乱，直到有一天终于发现找一个“人”好难。

一个东西好吃，智者浅尝之改进之，而愚者只会直至撑死。

这世上本没有什么救世主，应在C上多下功夫，程序员和C缔造者早就有过思考，相信野百合也有春天，还是看看C语言如何实现模块化编程方法，在部分程度上具备了OO特性封装与多态。

在具体阐述之前，需要明确生存期与可见性的概念。

生存期指的是变量在内存的生存周期，可见性指的是变量在当前位置是否可用。

两者有紧密联系，但不能混为一谈。

一个人存在但不可见只能解释成上帝或灵魂，一个变量存在但不可见却并非咄咄怪事，模块化方法正是利用了静态函数、静态变量这些“精灵”们特殊的生存期与可见性。

最后需要明确一点的是这里的模块是以一个.C文件为单位。

规则一：利用函数命名规则和静态函数 模块中不被其他模块调用的内部函数采用以下命名规则：用全部小写，单词间采用带下划线的形式。

如底层图形函数：pixel、o以及读键盘函数get_key等。

这些函数应定义为static静态函数，这样在其他模块错误地调用这些函数时编译器能给出错误（如BC编译器）。

（注意：有些编译器不能报告错误，但为了代码风格一致和函数层次清晰，仍建议这样作）。

规则二：利用静态变量 模块中不能被其他模块读写的全局变量应采用static声明，这样在其他模块错误地读写这些变量时编译器能给出警告（C51编译器）或错误（BC编译器）。

规则三：引入OO接口概念和指针传参 模块间的数据接口（也就是函数）应该事先较充分考虑，需要哪些接口，通过接口需要操作哪些数据，尽量作到接口的不变性。

模块间地数据交换尽量通过接口完成，方法是通过函数传参数，为了保证程序高效和减少堆栈空间，传大量参数（如结构）应采用传址的方式，通过指针作为函数参数或函数返回指针，尽量杜绝extern形式的全局变量，请注意是extern形式的全局变量，模块内部的全局变量是允许和必须的。

传指针参数增加的开销主要是作参数的指针和局部指针的数据空间（嵌入式系统（如C51）往往由于堆栈空间有限，函数参数会放到外部RAM的堆栈中），增加的代码开销仅是函数的调用，带来的是良好的模块化结构，而且使用接口函数会比在代码中多处直接使用全局变量大大节约代码空间。

需注意一点的事物总有他的两面性，水能载舟，也能覆舟。

对于需要频繁访问的变量如果仍采用接口传递，函数调用的开销是巨大的，这时应考虑仍采用extern全局变量。

以下演示了两个C模块交换数据： //Module1.C OneStruct* void GetOneStruct(void); //获取模块1数据接口 void SetOneStruct(OneStruct* pOneStruct); //写模块1数据接口 struct OneStruct { int m?_imember； //…… }t1; //模块1的数据 //t1初始化代码….. OneStruct* void GetOneStruct(void) { OneStruct* pt1; //只需定义一个局部变量 t1.imember=15; pt1=&t1; return pt1; } void SetOneStruct(OneStruct* pOneStruct) { t1.imember=pOneStruct->imember; //……. } //Module2.C void OperateOneStruct(void); //模块2通过模块1提供的接口操作模块1的数据 OneStruct* void GetOneStruct(void); void SetOneStruct(OneStruct* pOneStruct); void OperateOneStruct(void) { OneStruct* pt2; //只需定义一个局部变量 pt2=GetOneStruct(); //读取数据 SetOneStruct(pt2); //改写数据 } 采用接口访问数据可以避免一些错误，因为函数返回值只能作右值，全局变量则不然。

例如 cOneChar == 4; 可能被误为cOneChar = 4; 规则四：有限的封装与多态 不要忘记C++的class源于C的struct，C++的虚函数机制实质是函数指针。

为了使数据、方法能够封装在一起，提高代码的重用度，如对于一些与硬件相关的数据结构，建议采用在数据结构中将访问该数据结构的函数定义为结构内部的函数指针。

这样当硬件变化，需要重写访问该硬件的函数，只要将重写的函数地址赋给该函数指针，高层代码由于使用的是函数指针，所以完全不用动，实现代码重用。

而且该函数指针可以通过传参数或全局变量的方式传给高层代码，比较方便。

例如： struct OneStruct { int m?_imember； int (*func)(int,int); //…… }t2;

计算机编程C/C++和JAVA

楼上的，你是不是做过.NET的哦？什么叫学过J2EE就能很好的上手ASP.NET？不懂别乱说话~！ 毋庸置疑的，JAVA是你所说的所有语言中，最为抢手的语言了，想要学好，也不是哪么容易的，初学者的话，《JAVA编程思想》比较适合你，另外《JAVA WEB开发技术方案宝典》也是不错的推荐，前者是基础中的基础，后者需要有一定的网页编程能力~

smt贴片机编程怎么学

1. 贴片机编程方式的选择介绍 2. 生产部门的负责人常常会考虑采用编程的不同方式，他们会问：“采用何种编程方式对我来说是最适合的呢?”没有一种可以满足所有的应用事例的答案。

他们权衡的内容一般会包含有：所采用的解决方案对生产效率、生产线使用的计划安排、PCB的价格、工艺控制问题、缺陷率水平、供应商的管理、主要设备的成本以及存货的管理是否会带来冲击 3. 对生产效率带来的冲击 4. ATE编程会降低生产效率，这是因为为了能够满足编程的需要，要增加额外的时间。

举例来说，如果为了检查制造过程中所出现的缺陷现象，需要化费15秒的时间进行测试，这时可能需要再增加5秒钟用来对该元器件进行编程。

ATE所起到的作用就像是一台非常昂贵的单口编程器。

同样，对于需要化费较长时间编程的高密度闪存器件和逻辑器件来说，所需要的总的测试时间将会更长，这令人头痛。

因此，当编程时间与电路板总的测试时间相比较所占时间非常小的时候，ATE编程方式是性价比最好的一种方式。

为了提高生产率，以求将较长的编程时间降低到最低的限度，ATE编程技术可以与板上技术相结合使用，例如：边界扫描或者说具有专利的众多方法中的一种。

5. 还有一种解决方案是在电路板进行测试的时候，仅对目标器件的boot码进行编程处理。

器件余下的编程工作在处于不影响生产率的时候才进行，一般来说是在设备进行功能测试的时候。

然而，除非超过了ATE的能力，功能测试的能力是足够的，对于高密度器件来说性能价格比最好的编程方法是一种自动化的编程设备。

举例来说：ProMaster?970设备配置有12个接口，每小时能够对600个8兆闪存进行编程和激光标识。

与此形成对照的是，ATE或者说功能测试仪将化费60至120小时来完成这些编程工作。

生产线使用计划安排 6. 由于电子产品愈来愈复杂和先进，所以对具有更多功能和较高密度的可编程元器件的需求量也愈来愈高。

这些先进的元器件在OBP的环境之中，常常要求化费较长的编程时间，这样就直接降低了产品的生产效率。

同样，由不同的半导体器件制造商所提供的相同密度的元器件，在进行编程的时候所化费的时间差异是非常大的，一般来说具有最快编程速度的元器件，价格也是最贵的。

所以人们在考虑是否支付更多的钱给具有快速编程能力的元器件时，面临着两难的选择是提升生产率和降低设备的成本，还是采用具有较慢编程时间的便宜元器件，并由此忍受降低生产率的苦恼 7. 此外，制造厂商必须记住，为了能够对付在短期内出现的大量产品需求，他们不可能依赖采用最适用的半导体器件。

缺少可获得最佳的元器件，会迫使制造厂商重新选择可替换的编程元器件，每个元器件具有不同的编程时间、价格和可获性。

对于OBP来说，这种情形对于实行有效的生产线计划安排显然是相当困难的。

8. 因为自动编程拥有比单接口OBP解决方案快捷的优势，所以对编程时间变化的影响可以完全不顾。

同样，由于自动编程方案一般支持来自于不同供应厂商的数千款元器件，可以缓解使用替代元器件所产生的问题。

???PCB的费用 9. 近年来，对先进PIC的编程和测试需求有了令人瞩目的增长。

这是因为芯片供应商使用新的硅技术来创建具有最高速度和性能的元器件。

认真仔细的程序设计必须考虑到传输线的有效性问题、信号线的阻抗情况、引针的插入，以及元器件的特性。

如果不是这样的话，问题可能会接二连三的发生，其中包括：接地反射(ground?bounce)、交扰和在编程期间发生信号反射现象。

10. 自动化高质量的编程设备通过良好的设计，可以将这些问题降低到最小的程度。

为了能够进行ATE编程，PCB设计师必须对付周边的电路、电容、电阻、电感、信号交扰、和Gnd反射、以及针盘夹具。

所有这一切将极大的影响到进行编程时的产量和质量。

因为增加了对电路板的空间需求，以及分立元器件(接线片、FET、电容器)和增加对电源供电能力的需求，从而最终增加了PCB的成本。

尽管每一块电路板是不同的，PCB的价格一般会增加2%到10%。

编程规则系统的选择 11. 许多电子产品制造厂商还没有认识到闪存、CPLD和FPGA器件仍然要求采用编程规则系统(programming?algorithms)。

每一个元器件是不同的，在不同半导体供应商之间编程规则是不能交换的。

因此，如果他们要使用ATE编程方式，测试工程师必须对每一个元器件和所有的可替换供应商(现在的和未来的)写下编程规则系统。

12. 如果说使用了不正确的规则系统将会导致在编程期间或者电路板测试期间，以及当用户拥有该产品时面临失败(这是所有情形中最坏的现象)。

最难对付的事情是，半导体供应商为了能够提高产量、增加数据保存和降低制造成本，时常变更编程规则。

所以即使今天所编写的编程规则系统是正确的，很有可能不久该规则就要变化了。

另外，不管是ATE供应商，还是半导体供应商当规则系统发生变化的时候都不会及时与用户接触。

13. 工艺过程管理和问题的解决 14. 基于ATE的编程工作的完成要求人们详细了解编程硬件和软件，以及对于可以用于编程的元器件的专业知识。

为了能够正确的创建编程规则，测试工程师必须仔细了解有关PIC编程、消除规则系统和查证规则系统的知识。

但不幸的是，这种知识范围一般超出了测试工程师的专业范围，一项错误将会招至灾难性的损失。

15. 测试工程师现在对所涉及的编程问题，也必须有及时的了解，诸如：元器件的价格和可获性、所增加的元器件密度、测试的缺陷率、现场失效率，以及与半导体供应厂商保持经常性的沟通。

???同样，由于半导体供应商或者说ATE供应商将不会对编程的结果负责，解决有关编程器件问题的所有责任完全落在了测试工程师的肩上。

???举例来说，如果失效是由于可编程控量突然增加，测试工程师必须首先确定问题的根源，然后着手解决这个问题。

如果说这个问题是由于元器件的问题所引起的、由于ATE编程软件所引起的、该PCB设计所引起的，或者说是因为测试夹具所引起的呢? ? ? 16. 这些复杂的问题可能需要化费数周的时间去分解和解决，与此同时生产线只能够停顿下来待命。

与此形成对照的是，在器件编程领域处于领先位置的公司将直接与半导体供应厂商一起合作，来解决编程设备中所存在的问题，或者说自己设计设备，所以能够较快的识别问题的根源。

17. 一个经过良好设计的编程设备能够提供优化的编程环境，并且能够确保最大可能的产量。

然而，在编程过程中存在着很小比例的器件将会失效。

不同的半导体供应商之间的这个比例是不同的，编程产出率的范围将会在99.3%到99.8%之间。

自动化的编程设备被设计成能够识别这些缺陷，于是在PCB实施装配以前就可以将失效的元器件捕捉出来，从而实现将次品率降低到最小的目的。

经过比较，编程的失效率一般会高于在ATE编程环境中的。

???对于制造厂商而言如果能够事先发现问题，可以在长期的经营中减少成本支出。

编程设备不仅可以拥有较低的PIC失效率，它们经过设计也可以发现编程有缺陷的PIC器件。

在现实环境中作为目标的PIC器件被溶入在PCB的设计中，设计成能够扮演另外一个角色的作用(电话、传真、扫描仪等等)，作为一种专门的编程设备可以简单地做这些事情，而无需提供相同质量的编程环境。

??? 18. 供应商的管理ATE编程潜在的可能是锁定一个供应商的可编程元器件。

由于ATE要求认真仔细的PCB设计，以及为了能够满足每一个不同的PIC使用需要专用的软件，随后所形成的元器件变更工作将会是成本非常高昂的，同时又是很花时间的。

通过具有知识产权的一系列协议方法，可以让数家半导体供应商一起工作，从而形成一种形式的可编程器件。

19. 由IEEE?1149.1边界扫描编程所提供的方法具有很大的灵活性，它允许在同一PCB上面混装由不同半导体供应商所提供的元器件。

然而，自动化编程设备可以最大灵活地做这些事情。

借助于从不同的供应商处获得的数千个PIC器件的常规器件支持，他们能够非常灵活地保持与客户需求变化相同的步伐。

20. 主要设备的费用??取决于使用ATE的百分比以及对生产率的要求，为了实现PIC编程可能会要求增添ATE设备。

关于ATE价格的范围从15万美元至40万美元不等，购置一台新的设备或者更新现有的设备使之适合于编程的需要是非常昂贵的事情。

一种方式是使用一台AP设备来提供编程元器件到多条生产线上。

这种做法可以降低ATE的利用率，从而降低设备方面的投资。

程序员等级划分：看顶级高手如何编程

有脑子，很听话，很认真，但基础不好，代码有局限性 这类型的程序员大多是工作一到两年的程序员，但和上面的不同，他们很有脑子思路很好，而且很听经理的话，做东西很认真，做不完了自己会加班写，学新的东西也很快，但是有一点不好的是，他们有很多理由说自己没时间学习基础，这些人一般是在学校没有学好，出来之后后悔了，学起来很认真，由于学了些新的知识，起点高，看不起基础的东西，从不想着没事去看看编程基础，看看算法，看看数据结构，总是以为我都能做出这样的项目了，还看那些小东西会很丢人的，于是在公司从不看回家更不想看，时间长了，技术会有很大的局限性，对某一块技术很不错，但是对其它技术不怎么好，于是在接到一个项目时，总喜欢使用自己现有的，会的技术去实现，转了一圈又一圈总算是把东西写出来了，而且还是加班完成了，但是代码的性能，稳定性，和效率上差的很远，扩展性也谈不上，时间一长，项目一多起来，就会出现多次反工，因为需求是会不断变化的，于是自己的代码也要变化，感觉很是理所当然，一个项目没事，接手的多了就麻烦了，新项目刚到手，老项目就出问题了，不是这里有点小毛病就是那个功能要升级，于是新项目放下，着手改老项目，手上能有三四个项目时，就会忙个不停，改的多了，没办法再改了就得重新设计，或是直接说这个功能实现不了。

其实在这个阶段的朋友很有潜力的，只要花点心思补习一下自己的技术缺陷，多看看高手的代码，写之前想一下，设计一下，自然事半功倍，千万不要有眼高手低的心态。

真正的高手Nb人物是怎么工作的------------程序员 1.不随便改变需求 他们不会主观的改变一些东西，不管是对还是错，如果要改的话他们会在开会时，或是私下跟你提出来，通过后再改，否则会按需求办事 2.不写没有思想的代码 在写功能时会加上一些人性化的功能，比果加个小图标，加一些验证，处理一些操作习惯，加加快捷键，处理好Tab顺序，等这些，不用你说，他们自己会处理好。

3.不写没有远见的代码 他们在写代码时会想，不会是单纯的实现功能，他要想，如果别人也要用这个方法怎么办，以后要改的时候怎么办，代码这样写是不是合理，是不是会影响性能，然后才会”吝啬“的出手。

4.不写不负责任的代码 我们写代码一是为客户用，二是方便其他人看，不单单是自己维护，要对自己的代码负责，从自己手上出去的代码代表的就是自己的脸，代码不好，人家会“打脸”的。

他们不愿意挨打所以他们负责。

高手在编程效率方面可能并不比普通程序员快多少，因为他们会吝啬自己敲下的每一行代码。

这种“吝啬”有两方面的含义，一是项目的架构性和整体性考量，二是从性能和优化的角度进行Coding。

其实，这里所映射的是一个开发者的技术视野。

有多位技术专家强调项目执行时的全局观。

面对一个项目，即使是团队中的普通一员，也要力求从项目整体架构的角度审视开发需求，对各个模块、接口和通信做最优化的预想和配置。

这样可以从全局审视整个项目的技术布局，预判可能出现的问题。

在确定了整体之后，落实到具体的模块实现，每一行代码不但有上下文的考量与规划，还要具备模块间的整体布局。

这是模块内的技术视野，比如接口的定义、注释的可读性、代码的执行效率等。

当你写下一行代码前，要考虑它是否会对整个系统造成影响，是否方便其他接口进行调用，这些都是一个开发高手的“技术潜意识”。

据一些经常带领入门级开发者的技术经理介绍，多数人只考虑自己所负责的模块进行开发，缺乏一个全局性的技术视野和对代码性能苛刻的态度，这样虽然能按交付日期完成项目，却对项目质量和开发者的自我提高有很大阻碍。

开发高手是代码阅读者。

大多数技术专家的代码阅读量是普通程序员的百倍，代码阅读的时间比写代码的时间要长得多。

多数程序员只把程序开发当成一份工作，他们在乎平台的前景、语言的优劣、报酬的高低;他们不愿为一个技术点反复钻研，不愿为一个bug精心测试，不愿为自身技术水平的提高多花时间。

而开发高手往往具有单纯的技术梦想，愿意为技术付出自己全部的时间。