好代码十个秘诀
软件的质量属性
鲁棒 - Solid and Robust Code
简洁 - Maintainable and Simple Code
高效 - Fast Code
简短 - Small Code
共享 - Re-usable Code
可测试 - Testable Code
可移植 - Portable Code
集百家之长, 归我所用 - Follow Basic Coding Style
1.代码能够清晰的表达你的思路
2.代码应该具备自解释能力，注释代码别是单纯解释语句，这种注释毫无疑义
3.编码的缩进和排版规范
4.所有的函数和变量应有他人容易理解的名字
5.将Tab键改用为4个空格字符
6.减少但个函数的长度，控制在50-100行以内
7.避免幻数，多使用枚举和常量的定义
取个好名字 - Use Naming Conventions
1.采用匈牙利命名法对变量进行命名
2.名字要清晰表达含义，不要怕长
凌波微步, 未必摔跤 - Evil goto’s? Maybe Not…
1.goto的使用应该遵循原则，而不是全盘否定
2.不用写高深晦涩的语句，不要一味追求性能忽视代码可读性
3.模式并不是一味正确，特定问题更需要考虑反模式
先发制人, 后发制于人- Practice Defensive Coding
1.尽量保持代码的简洁和简单
2.调用其它接口和函数时候首先对返回值进行检查
3.避免有符号/无符号,32位/16位，被零除等误算情况
见招拆招, 滴水不漏 - Handle The Error Cases: They Will Occur!
1.通过异常处理机制来保证程序代码的健壮性
2.异常处理中一定要注意资源的释放
3.异常处理要关注日志的详细记录，便于后续BUG分析
4.不用把后台编码或系统异常直接抛给用户
熟习剑法刀术, 所向无敌 - Learn Win32 API Seriously
1.Win32 API是微软平台编程根本
2.对系统强大的公用类库的熟悉和整理将事半功倍
双手互搏, 无坚不摧 - Test, but don’t stop there
1.如果你没有进行测试，你完成的代码将仅仅是个半成品
2.尽可能多的对自己的代码进行测试
3.编码人员应该更专注于百盒测试和单元测试
4.要善于使用JUnit,NUnit，PureCoverage,Compuware,NCover等测试工具
5.相互间的Review和走查是对代码可维护性的重要测试手段
6.有特殊性能要求时候需要对相关功能或模块单独进行性能测试
活用段言 - Use, don’t abuse, assertions
1.断言可以很好的描述假设和不可能的情况
2.断言对程序Debug很有用，可以尽早的发现程序问题
草木皆兵, 不可大意 - Avoid Assumptions
1.考虑到用户使用的各种场景
2.不用假设用户会正确输入数据，要做好各种完整性和边界的检验
3.程序中70%左右代码是为了保证这种完整性服务的，正常条件下功能可能30%代码就实现了
最高境界, 无招胜有招 - Stop writing so much code
1.一味拷贝粘贴代码就是在制造拷贝BUG，这种代码对系统无任何意义
2.编码过程注意重用，函数级->组件级->系统级
3.通过重构持续改进代码质量，改进自我逻辑思维
最后总结下：
1.养成良好编码习惯，你面试的一小段代码可能就足一展现你全部陋习。
2.熟练使用好各种辅助工具，但不要全部依赖工具，最主要是学习分析和设计的思考方式
3.注重单元测试，关注程序性能,可维护性,可测试性是编码技能提升重要手段
4.通过重构使编码过程形成完整闭环的反馈回路，重构能力可以很好体现自己的设计能力
5.养成良好习惯，形成自己的编码过程检查单，多请教老员工可能事半功倍。
鲁棒 - Solid and Robust Code
简洁 - Maintainable and Simple Code
高效 - Fast Code
简短 - Small Code
共享 - Re-usable Code
可测试 - Testable Code
可移植 - Portable Code
集百家之长, 归我所用 - Follow Basic Coding Style
1.代码能够清晰的表达你的思路
2.代码应该具备自解释能力，注释代码别是单纯解释语句，这种注释毫无疑义
3.编码的缩进和排版规范
4.所有的函数和变量应有他人容易理解的名字
5.将Tab键改用为4个空格字符
6.减少但个函数的长度，控制在50-100行以内
7.避免幻数，多使用枚举和常量的定义
取个好名字 - Use Naming Conventions
1.采用匈牙利命名法对变量进行命名
2.名字要清晰表达含义，不要怕长
凌波微步, 未必摔跤 - Evil goto’s? Maybe Not…
1.goto的使用应该遵循原则，而不是全盘否定
2.不用写高深晦涩的语句，不要一味追求性能忽视代码可读性
3.模式并不是一味正确，特定问题更需要考虑反模式
先发制人, 后发制于人- Practice Defensive Coding
1.尽量保持代码的简洁和简单
2.调用其它接口和函数时候首先对返回值进行检查
3.避免有符号/无符号,32位/16位，被零除等误算情况
见招拆招, 滴水不漏 - Handle The Error Cases: They Will Occur!
1.通过异常处理机制来保证程序代码的健壮性
2.异常处理中一定要注意资源的释放
3.异常处理要关注日志的详细记录，便于后续BUG分析
4.不用把后台编码或系统异常直接抛给用户
熟习剑法刀术, 所向无敌 - Learn Win32 API Seriously
1.Win32 API是微软平台编程根本
2.对系统强大的公用类库的熟悉和整理将事半功倍
双手互搏, 无坚不摧 - Test, but don’t stop there
1.如果你没有进行测试，你完成的代码将仅仅是个半成品
2.尽可能多的对自己的代码进行测试
3.编码人员应该更专注于百盒测试和单元测试
4.要善于使用JUnit,NUnit，PureCoverage,Compuware,NCover等测试工具
5.相互间的Review和走查是对代码可维护性的重要测试手段
6.有特殊性能要求时候需要对相关功能或模块单独进行性能测试
活用段言 - Use, don’t abuse, assertions
1.断言可以很好的描述假设和不可能的情况
2.断言对程序Debug很有用，可以尽早的发现程序问题
草木皆兵, 不可大意 - Avoid Assumptions
1.考虑到用户使用的各种场景
2.不用假设用户会正确输入数据，要做好各种完整性和边界的检验
3.程序中70%左右代码是为了保证这种完整性服务的，正常条件下功能可能30%代码就实现了
最高境界, 无招胜有招 - Stop writing so much code
1.一味拷贝粘贴代码就是在制造拷贝BUG，这种代码对系统无任何意义
2.编码过程注意重用，函数级->组件级->系统级
3.通过重构持续改进代码质量，改进自我逻辑思维
最后总结下：
1.养成良好编码习惯，你面试的一小段代码可能就足一展现你全部陋习。
2.熟练使用好各种辅助工具，但不要全部依赖工具，最主要是学习分析和设计的思考方式
3.注重单元测试，关注程序性能,可维护性,可测试性是编码技能提升重要手段
4.通过重构使编码过程形成完整闭环的反馈回路，重构能力可以很好体现自己的设计能力
5.养成良好习惯，形成自己的编码过程检查单，多请教老员工可能事半功倍。
