※ 引述《workworkwork (Miyada vv)》之铭言：
: 这是我"前"公司的经验了
: 一开始以为公司内有严格的coding style规定是件好事
: 我也赞成公司要有一致的coding style
: (像我以前看过apache的C code
: 全部CODE都像同一人写出来的一样)
: 而公司内也会有人code review你的部份
: 一切听起来都很完美
: 一开始听到有规定coding style和code reviewer也很开心
: 但因这一切都因为公司里有一个奇怪的规定而毁了
: "code不可以用code formatter去扫"
: 我承认自己写程式常会漏勾
: 所以写完会花很多心力在检查有没有BUG 是否会被攻击 资安问题等等....
: 但在这间公司发现一个很奇怪的事情
: "有资安漏洞的CODE大家会很有耐心的教 空格没空好会被骂的狗头淋头"
: 搞到最后一段程式写完我只知道检查空格....
: 最后的最后我决定离职的原因是出在reviewer
: 和reviewer的code观念差太多 跟本无法共事
: 例如：
: 1.
: 有时为了避免太多层出现===>
: if(a)
: {
: //do a things
: if(b)
: {
: //do b things
: if(c)
: {
: //do c things
: }
: }
: }
: 会改成====>
: if(!a)
: {
: return ;
: }
: //do a things
: if(!b)
: {
: return ;
: }
: //do b things
: if(!c)
: {
: return ;
: }
: //do c things
: 但因为这写法code reviewer没看过
: 她直接在辨公室里开飙
这个我看起来 A 跟 B 根本没什么不同，但 B 确实比较糟糕。
因为都是 X条件触发，处理 X条件，再继续往下做。
但你是 X不成立，就返回。这个 !X 不是好方法，实际上对系统架构没帮助。
你要让系统结构很维护，避免那么多{}层出现，
框到到底那个 } 是对应那个 { 都不知道了，应该这样写:
if(
fun_A() == true
&& fun_B == true
&& fun_C == true
&& .......
)
{
做某件事
}
function fun_A()
{
if(....) return(false);
return(true);
}
下略，自己补上 fun_B()..fun_C()。
这样写有啥好处？？
(1) 最大好处就是太多层后，真的不知道那个 } 是对应那个 {
也就是你一直在数空格数到底空对了吗？
(2) 除错超快，注意我是直接每个判别直接写一行，
你写的落落长后，除非你是天下奇杷，脑袋超清楚，
要不然肯定会错啦~~这个地方我除错的速度绝对比你快。
我直接一行一行 // && fun_C() == true
就找出问题了。
甚至未来你某个条件不想再用就像上面一样 mark 掉就好了。
以上给参考，你自己去评估三种写法哪种最好。
另外如果有人又要出来跟我战他要用 class 写法最好，
还是说这个写法糟透了，那是他家的事，我不出来应战。
我只是恰好路过，出来建议一下而已。