这是一个创建于 4272 天前的主题，其中的信息可能已经有所发展或是发生改变。
 |
1
tioover 2013-03-16 15:39:22 +08:00 via Android
最后一题大概是:=
|
 |
2
Xrong 2013-03-16 15:52:35 +08:00
希望有人解释下第二题，语义上感觉一样啊
|
 |
4
volCANo 2013-03-17 11:56:54 +08:00
|
 |
6
alexrezit 2013-03-17 12:37:47 +08:00  1
1. 加上花括号是个好习惯;
2. 在某些编译器的默认设置里, 这样的结构是要给出一个 warning 的: myFreakyFunction { if (what) { return oo; } else { return xx; } } 必须要写成这样来消除这个 warning: myFreakyFunction { if (what) { return oo; } else { return xx; } return xx; } 例如旧版本 Xcode 默认的编译器, 但现在最新版本已经不会给出 warning 了, 貌似是从 Apple LLVM 4.x 开始. 其实为了逻辑更清晰, 我自己现在已经尽量在每个 function / method 里只 return 一次了. 例如当 type 为 BOOL 时: BOOL myFreakyFunction { BOOL isXXX = NO; if (what) { isXXX = YES; } else { isXXX = NO; } return isXXX; } 而不是: BOOL myFreakyFunction { if (what) { return NO; } else { return YES; } } 或: BOOL myFreakyFunction { if (what) { return NO; } return YES; } |
 |
7
cassyfar 2013-03-17 12:54:37 +08:00
|
|
8
volCANo 2013-03-17 13:57:00 +08:00
@cassyfar 肯定有吗？又不是说if else 里面一定要有return，如果里面不写呢？
代码逻辑是没什么问题的，只是编码规范。你想想，如果if else里面的东西非常多，你去读甚至都找不到return在哪儿，那么你会觉得这代码不爽吗？应该会的，甚至你会说，这个函数没有返回，是错的。 所以在if else外面写return，别人读起来会容易些。这只是个编码规范问题。 还有第一个if后面只有一句代码也要加大括号，我一直有这个习惯，我的理由是：虽然你现在是只要一行，但以后非常有可能要添加逻辑，就不只是一行了，到时候也要加括号；况且，都加括号不是更一致吗？而且，很多编译器都帮你加好了，你写个if 后面的大括号都自动给你不气了。 |
 |
9
for4 2013-03-17 14:09:54 +08:00
|
 |
10
laskuma 2013-03-17 15:21:45 +08:00
不觉得他说的有道理 这只是纯粹的taste上的问题 你偏好哪一种 风格不差 看着不乱 易于理解就好了 他对++的分析我倒是很赞成 这种带side effect太多的语句写多了连debug的时候都会造成困难 但是关于if(){return}else{return}却是我不能接受的 个人还是觉得if(){return}return;的写法没有什么难理解的 代码一行行看下来也都明白 多写一个return反而会让人摸不着头脑
|
 |
11
best1a 2013-03-17 15:33:22 +08:00
第二种写法还有一些别的好处，比如有时可以减少一下if的嵌套
|
 |
14
perrywky 2013-03-18 13:57:11 +08:00
其实他说的道理《代码大全》里都已经提到了，就是“代码是写给人看的”
1. 加上花括弧，块的边界更清晰，别人读起来更轻松 2. 去掉花括弧，语义发生了变化，第二个return从“其它情况”变成了“默认情况”，本来是很简单的互斥关系，现在第一个return成了特殊情况，读代码的人就会想，还有没有其他特殊情况呢？ |
 |
15
GTim 2013-03-18 17:40:58 +08:00
1. 防止手贱在 if 后加了 分号（";");另外一个就是某些代码编辑器tab和space不分的情况下，某些人就会进入思维误区，为是并行还是串行想破脑袋；其它风格问题
2.语义上来说是不一样的，同样可以防止某些人手贱 把 else 写成 else if 3. 不要只研究i = i+1 和 i++两个表达式，而是要研究上下文！何况 i++ 与 ++i本身就是两种语境；举个例子：a = ++i; 和 a=i=i+1;哪种更好？ a=i++;用一条语句怎么写加法的方式 ? 这三个问题，一般都是语义上的问题，计算机是死的，人是活的，但更悲剧的是计算机遵守交通规则，但人却不一定遵守交通规则;计算机的智力几乎都是一样的，但人的呢？千奇百怪,很多人就是转不过那个弯弯 |
|
16
GTim 2013-03-18 17:45:04 +08:00
针对第三个问题，有很多牛角尖可以钻的，仔细研究下去，可能永远出不了那个坑
|
 |
17
guotie 2013-03-18 17:49:00 +08:00
i++ ++i单独写没有任何问题；
如果单独写i++ 也要改成i = i + 1就有点装逼了 |
 |
18
iEverX 2013-03-18 23:47:21 +08:00
|
 |
19
leafduo 2013-03-19 01:04:15 +08:00
第一个加括号是有必要的，改代码的时候不会忘记加，switch 里面的 break 语句同理。
第二个更多是 personal taste 的问题吧，另外就是有的版本的编译器对第一种写法会给 warning，最新版本的 clang 已经能识别两种了。 对于自增操作符这种，我都是觉得实践中哪个清楚、方便就用哪个，没歧义的时候就用自增，难理解了就拆开。 |
 |
21
zhujinliang 2013-03-19 09:00:12 +08:00
@GTim C语言里一边移动指针一边取出数据或写入数据是多么的惬意。 while(count--) *pBuf++ = 0x00;
|
 |
22
fancl20 2013-03-19 10:39:47 +08:00 1
|
|
23
GTim 2013-03-19 17:57:38 +08:00
@zhujinliang 我也是
|
|
24
tioover 2013-03-20 08:14:17 +08:00 via Android 1
|
 |
25
zztom 2013-03-20 08:24:19 +08:00
花括号应该是个还习惯，不过我起初加他的理由竟然是为了好看
|
 |
26
skydark 2013-03-20 08:35:35 +08:00
@fancl20 @tioover 个人倒是觉得这种编译器自己能推断的事情交给它们做很对啦……
不过又仔细看了下，是因为`:=`允许 redeclaration 吗？不过它的 redeclaration 很受限一般倒是不会出什么问题，但的确会产生看起来是声明+初始化的地方进行了重新赋值的行为…… http://golang.org/ref/spec#Short_variable_declarations |
 |
27
palxex 2013-03-20 09:36:29 +08:00
++这几个例子，拿任意高级语言举例都不错。就放在C里不合适……因为它就是高级语法的汇编。强调的是语句可以几乎直接对应到不长的汇编段落。
i++这种情况下，i强调的是一个内存地址，用图灵机的语言，就是一个具体可以打孔的位置。你对这一个位置强调i2=i1+1，i2跟i1是两个不同的变量……完全没有意义。 在SSA的情况下强调其是两个变量，正是因为"变量"与"地址"的解耦，让更高级的优化成为可能。但这本来就不是C，甚至C++这类语言的设计目的。如果要批判这里，C的指针设计才是更应该批判的，但这就是它的设计——和精髓：可移植汇编语言。unix hater's handbook分析的不错，这个特性让unix和C得以病毒式传播，而且方兴未艾。 关于王垠的第三题，如果要改造图灵机，维持相同的计算能力并规避地址的存在……我简单的大脑当机了若干次也没什么结果。莫非要改造成lambda演算？ |
|
28
alexrezit 2013-03-20 09:46:34 +08:00
|
Select Language