Skip to content

良好编程

防错性编程

需要check的场景  // 数据产生方式不可控。数据经过不可靠的通道、或者来自普通用户的输入。
    多个系统间的调用、一般是多进程间的网络调用、比如service的入口函数。
不需要check的
    一般是一个进程空间内部。
        模块内部函数之间的调用
        目标明确的库函数
    正常情况下、应该避免错误调用导致进程崩溃。但是库函数在有清晰说明的情况下、可以接受崩溃的情况发生。

参考 http://blog.jobbole.com/101801/

failfast、尽早检查出错误、退出程序

逻辑更清晰
    错误校验和业务处理分离、业务处理可以不用做放错check、使得业务代码会清晰简单很多。
    把check放到入口处、后面的代码就不需要再check了、直接默认正常去处理。避免代码中出现到处check的烦恼。
性能更好
    避免后续的工作浪费、提高性能。尤其是避免出现已经做了部分db查询、突然发现输入的参数格式不对。

异常与返回值

如果函数的返回结果是个明确的错误、业务无法继续处理了、用异常。
如果函数返回后业务还会继续、只是会因为返回的不同而走向不同分支、用返回值。
异常要跟名字一样、真的是异常了、而不是仅仅是个逻辑转向。

参考 http://typethinker.blogspot.com/2007/04/checks-exceptions-and-assertions.html

最小惊奇

tbl_address命名
management的表设计

参考 https://en.wikipedia.org/wiki/Principle_of_least_astonishment

命名

避免无意义、尽量有描述性。
不要太短、不要太长。
避免太长的方法
    缩写
        常见缩写
        能快速理解的缩写
        增加注释后能容易理解的缩写
    tip法
        可以只取业务语义中的一部分、能使人在简短注释后、快速联想到完整的语义。
举例  // 时价
    如果给时价取名词
        可以考虑：timing_price、而不是time_price
        长度适中、能表达语义
    如果要表达是否时价
        time_price或者timing_price是名词、这里需要的是个形容词、所以这里取名的关键是找一个合适的形容词、或者自己造一个形容词。
        直观方案：is_timing_price、但是不准确。因为这个值如果放到sku上、修饰的是sku、但是sku不是个price、is_timing_price让人感觉sku是个price、略怪。是timing去修饰price、不是price修饰sku。
        更好的表达：price_is_timing或者price_timing。因为sku是个名词实体、这样选择后、price_is_timing或者price_timing就是个形容词、用来修饰名词、语法上会顺畅很多、不会让人觉得哪里不对。
        取一半语义的tip方式：timing。这种取名法在首次看到的时候、需要一个注释、但是因为关联性强、看一眼也能快速记住、也是可选的方案。优点是短、缺点是需要注释。

logging

输入输出要log
能用输入信息简单推到出的信息不要打印
复杂计算后的的中间状态需要log
分支流程一般不需要打印、因为一般可以用输入信息或者中间状态推理出来
sql应该打印、但是可以放在debug模式

推荐书籍

代码大全
unix编程艺术