好的编程习惯
好的编程习惯
好的编程习惯做好版本控制，并及时备份代码
编码时，最痛苦的事情不是有多少bug没解决，而是突然停电了，一天的工作却没有保存。版本控制时，最好使用版本控制软件。无论什么时候改变自己的程序，它们都会将其保存为.bak文件。
估算解决问题所需要的时间
为自己定一个时间限制，如果在这期间未能解决问题，那就去寻求帮助，或到网上找答案，而不是尝试去做“超级堆码员”，因为很多问题，你很少会是这个世界上唯一一个遇到的人。站在别人的肩膀上，会让你的形象变得高大、伟岸。
重视，但不过于注重程序的设计模式
在大中型系统中，引入设计模式，往往能极大地提高系统研发的效率。但设计模式并非万金油，有时候，写一个简单的算法，要比引入某种模式更容易。如果一个100行就能写完的脚本，最终却使用了8个类，10个接口，外加一大堆范式和标记符，结果导致97%的代码不做任何事情，这种优化又有什么意义？在多数情况下，程序代码应是简单易懂
使用输出日志
打印输出函数可以跟踪变量的执行，但频繁地插入打印会使得屏幕的输出很乱，而写一个日志函数，可以保证 Debug 的时候的输出以一种统一的，可管理的方式出现，这样在最后发布稳定版本的时候，只需要简单的几行命令就可以从代码中剔除所有的日志打印行。
加强测试
测试的重要性并不亚于开发，所以要非常注重程序自测试。测试时，一般使用工具为主，人工为辅的策略，工具包括用单元测试，assert语句，代码测试容器，人工指用 print 和debugger 一行一行跟踪。
优化代码
优雅的代码非常的易读，所以如果时间允许，应该尽可能地优化代码，对时间和空间进行合理分配与使用。之前声明的一些变量，现在可能没用了。同样，并不依赖循环的一些声明可以移到循环模块之外去。否则后续开发或是技术提供会比较困难。但也需要注意，优化后的代码并不是越简短越好，用的语法越偏僻越好，因为晦涩的代码，维护成本会非常高，而且好的代码不但要实现功能，更要好维护，最好是A写的代码让B能很轻易的理解和修改。
检查代码
代码要经常检查（包括自查和其他同事检查）。在提交代码前，找个同事一起坐下来，向他解释代码做了哪些修改。这样做的过程中通常能够发现代码中的错误，而不需要同事说一句话。这比自己审查自己的代码要有效的多。将代码的bug发现的越早，成本越低。
回顾代码
在看到自己以前的代码时，通常会有两种矛盾不同的想法：第一种：我怎么写了这么烂的代码；第二种，我写的代码还是挺有成就感的。其实，经常回顾以前的代码，往往会触发新的想法，以及对以前编码更深层次的思考。
对项目文件归类保存
可以把项目文件放到SOURCE、HEADERS、MAKE、EXES等不同的文件夹中。如果工程包含多个源文件，则可以建立一个README文件，注明每个源文件、数据文件、临时文件以及日志文件(如果有的话)的作用。还可以注明编译和运行步骤。
遵循编程规范
合理使用缩进；使用循环和条件语句时，先把左右括号对应起来，然后再在里面写其他语句；使用有意义的变量和函数名称，例如，使用‘radius’来代替圆的半径，而不是用‘r’来表示。
任何软件都会有BUG
BUG是永远也改不完的，所以关键是要修复严重的、影响业务的、显眼的Bug。一个软件项目，参与的人数越多，并不代表软件可靠性越好，相反，“人多手杂”，而且需求越变更，潜在的Bug会越来越多，很多时候，也许只是修改了一行代码，其很有可能影响到很多关键流程的执行。
不要心存侥幸
可能出错的地方一定会出错，偶尔发生偶尔不发生的问题就是大问题。所以，对于一些常见的问题，一定做到防微杜渐：每个变量都做初始化；每个函数都做声明；引用每个参数都会做有效性检查；在可能出错的每个地方都会做边界条件检查等等。这样开发出来的程序一定会稳固很多，就是出错也会很容易修改。而一些没经过正规培训或是半路出家的所谓的高手，一般开发速度很快，三下两除二的就开发完成了，结果很可能出现“功能大体实现，bug总是在变”的情况，最后花费很长的时间来修改代码中的bug，总时间甚至会大大延期。而真正的高手，追求的境界是零缺陷代码。
尽可能复用成熟代码
如果有现成的允许使用的经过测试的代码或程序库，并且有人维护或维护成本可以接受，程序员应该尽量使用现有代码和库来节省时间和开发测试成本。
了解底层知识
优秀的程序员不会只关注程序如何实现，而会深层次地剖析其实现机理，所以，程序员要对自己的操作系统和硬件要有足够的了解，从CPU的执行方法，到操作系统的运转，到程序的编译链接，到代码的加载与运行，到程序的调试，最后到实现的功能这一整套的内容，只有做到这样，才能真正提高。
养成耐心、冷静的好习惯
作为一名程序员，不能像普通人一样被计算机掌控，而应该作为计算机的主人，去掌控计算机。所以，一定要有足够的耐心，当程序运行不正确时，要冷静下来，站在计算机的角度去看问题、分析问题。