这样编程就是慢性自杀,该如何解决
这样编程就是慢性自杀1.没有异常处理机制,程序不能自己报告异常2.没有大量的断言,千疮百孔这种情况下编程
这样编程就是慢性自杀
1.没有异常处理机制,程序不能自己报告异常;
2.没有大量的断言,千疮百孔
这种情况下编程简直就是生不如死
各位技术领导,请珍惜程序员的生命,
为我们提供好用的异常处理机制和断言机制
[解决办法]
沙发,注意楼主的结贴率
[解决办法]
[解决办法]
[解决办法]
[解决办法]注意楼主的结贴率
[解决办法]╮(╯▽╰)╭
[解决办法]大叔，是不是再加条： 适当的注释？
[解决办法][解决办法][解决办法]http://forum.csdn.net/PointForum/ui/scripts/csdn/Plugin/003/onion/15.gif
[解决办法]注意楼主的结贴率。。。。
[解决办法]顶一下。。。
[解决办法]你们公司的代码规范，额。。。。。。。。。。。。
[解决办法]从来不使用断言。。。惭愧~~~~~~~~~
[解决办法][解决办法][解决办法][解决办法][解决办法][解决办法]测试驱动
[解决办法]没有 unit test 的编程也是“自杀”。
实际上，身体健康才谈得上自杀，如果病入膏肓就不需要“自杀”了。
对于编码也一样。如果你的代码本身就是垃圾。那么把它用精美的盒子包装起来也是垃圾，还可惜了一个盒子。
[解决办法][解决办法] 异常处理机制和断言机制
[解决办法][解决办法]惭愧啊
[解决办法]求科普, 断言是什么?
[解决办法]异常处理回收日志？
断言？？？？我知道段誉。还知道六脉神剑。
[解决办法] 断言还从未用过。
异常这东西倒是有一些感觉，但是异常并非是抛出就完事，也不是见到就抛的，若是说想要构造一个结构比较好的系统，应该是对异常的抛出及处理有订出规则。
其实我觉得一个项目的好坏极大部门是出在管理环节上，跟PG的关联并不是很多，因为PG再烂只烂一块，PM烂就烂到一坨。
常见的因素就是项目开发的评估过程，这其中包括时程(系统架构熟悉等非需求分析方面的因素)以及对人的因素(正确的时间安排正确的人)需要进行事先的评估。
[解决办法]呼呼呼，多判断？
------解决方案--------------------
程序员工作就是慢性自杀。。。。。
[解决办法]断言没用过，LZ写篇文章出来
