这是一个创建于 3107 天前的主题，其中的信息可能已经有所发展或是发生改变。
这 save 还能更快点吗？
 |
1
knva 2017 年 7 月 13 日
没准是测试代码呢.
|
 |
2
Famio 2017 年 7 月 13 日
function clean_cache()
{ alert("缓存清除成功！") } 前两天 V 站看到的 |
 |
3
kinghui 2017 年 7 月 13 日
没准是兼容代码呢.
|
 |
4
chazz 2017 年 7 月 13 日
哈哈哈，跟前段时间的清楚缓存 一摸一样的操作
|
 |
5
claysec 2017 年 7 月 13 日
def random():
a = random(10) return a |
 |
6
surfire91 2017 年 7 月 13 日
我咋觉得没啥问题，可能是为了方便调试，或者是预留接口之类的
|
 |
7
Lonely 2017 年 7 月 13 日
这一般是预留的吧
|
 |
8
KaKaGoSki 2017 年 7 月 13 日
如果项目写完了就不会要你接手了 先写完逻辑再补代码而已
|
 |
9
cod 2017 年 7 月 13 日
没毛病。 第一段预留，第二段一般都是测试代码，改成 false 就快速屏蔽。
经常这么写，尤其是脚本类语言。 当然 c/c++的话，就不可能这样，改一下再编译太费劲。 |
 |
10
momocraft 2017 年 7 月 13 日
我做到一半时也这样..不过会写个 FIXME
|
 |
11
reus 2017 年 7 月 13 日  7
少见多怪，你经验还是太少
用来调试的，用来预留的，各种技巧，多学习，少吐槽 |
 |
12
blacklee 2017 年 7 月 13 日
1. 很多人说了，这没毛病，是你少见多怪。多写几年，你就会用这种方法来调试代码了。
2. 话虽如此，但这种代码应该是留给自己的，把这种代码交出去就不太好了。 |
 |
13
iyangyuan 2017 年 7 月 13 日
没什么大问题，方便扩展，很有先见之明
|
 |
14
autoxbc 2017 年 7 月 13 日
附加操作，快速屏蔽
if(true) {...} 快速略过判断条件 if( false || ... ) {...} else {...} 多方案备选 switch(1) { case 1: ... break; case 2: ... break; } |
 |
15
printempw 2017 年 7 月 13 日
挺正常的，我也常写，不过一般会标明，也不会就这么放着交给别人
|
 |
16
nutting 2017 年 7 月 13 日 via Android
第一个应该留个 TODO 吧，第二个测试用的，但是 true 建议定义到一个常量里起个名字吧
|
 |
17
kamen 2017 年 7 月 13 日
写法没毛病，但是好歹加个注释啊
 |
 |
18
Mikewu 2017 年 7 月 13 日
测试的时候我也常这样写
 |
 |
19
mingyun 2017 年 7 月 13 日
// to do
|
 |
20
Ouyangan 2017 年 7 月 13 日
因为没写完逻辑的话 , 不这样写编译器就会报错啊...
|
 |
21
oneonesv 2017 年 7 月 13 日
测试用的 没毛病
|
 |
22
hellojeana 2017 年 7 月 13 日 via iPhone
@Famio 好好笑！！😂😂
|
 |
23
wemore 2017 年 7 月 13 日 via Android
uc 看不到图，顺便绘麻好评
|
 |
25
ditel 2017 年 7 月 14 日 via Android
第一个基本是写个接口，后面再填
|
|
26
autoxbc 2017 年 7 月 14 日
@weyou 我写的是常规状态，所谓常规状态就是不影响条件判断，略过状态是调试时快速切换用
略过判为真 常规状态 if( false || ... ) 略过状态 if( true || ... ) 略过判为假 常规状态 if( true && ... ) 略过状态 if( false && ... ) |
|
27
autoxbc 2017 年 7 月 14 日
|
|
28
autoxbc 2017 年 7 月 14 日
@weyou 抱歉刷屏，刚发现我们俩的出发点不一样
你的写法在调试的"冷区"适用，写 true || 就快速判真，不过出调试时略麻烦，需要删除 true || 我的写法在"热区"适用，布尔值和逻辑符号就放在那，平时也有，但是不影响逻辑。进调试时只改动布尔值，出调试也只改布尔值，尤其是弱类型语言，0 和 1 切换就行。 乍一看比较怪异，这样扣题"还有这种操作"。 |
 |
29
e9e499d78f 2017 年 7 月 14 日
应该用：
///* //*/ |
 |
30
Mutoo 2017 年 7 月 14 日 1
两段代码切换:
//* Block-A[run this] /*/ Block-B //*/ 删除掉第一个 / /* Block-A /*/ Block-B[run this] //*/ |
 |
31
knight322 2017 年 7 月 14 日
楼主啊，方法上面好像有注释哦
|
 |
32
cxbig 2017 年 7 月 14 日
这些手段常用啊，不过提交之前肯定是完善了的。哪怕留白，或因分工需要交给其他人做，一定会写 todo。
|
 |
33
owt5008137 2017 年 7 月 14 日 via Android
@cod c++有时候也这么写，还有时候用#if 0 和#if 1 的
|
 |
34
hao3721 2017 年 7 月 14 日
少见多怪
|
 |
35
sonyxperia 2017 年 7 月 14 日
 |
 |
36
lxy 2017 年 7 月 14 日
第一个至少留注释 TODO，第二个至少留个调试变量 if(DEBUG)
|
 |
37
kary1 2017 年 7 月 14 日
预留的吧，具体实现还没有来得及写
|
 |
38
ikaros 2017 年 7 月 14 日
第一个我就经常这么写的..........
主要是为了在规划结构的时候,决定哪些函数该做什么, 把所有的函数和结构都规划好之后再写里面的逻辑 第二个不会这么写 |
 |
39
timi 2017 年 7 月 14 日
= = 经常这么写，虽然不好看，但是好歹调试起来顺手顺心就好了
|
 |
40
crackhopper 2017 年 7 月 14 日
第一个没毛病，第二个有毛病。如果需要判断，应该写成具体的函数，然后用 1 的方式预留一下；如果只是 debug 的话，注释掉明显更好。加减注释只是快键一下就 OK 了；如果是测试的话，应该写到单元测试里去。
|
 |
41
foursking 2017 年 7 月 14 日
看在是妹子的头像，我就不吐槽了啊
|
 |
42
lommo 2017 年 7 月 14 日
我不看评论，还以为要吐槽花括号的开始位置呢。
|
 |
43
Quaintjade 2017 年 7 月 14 日
很正常，先搭好框架再实现功能，不然你得全写完才能测试
不过一般会写一行注释标明待实现。暂时用不到的功能可以抛 System.NotImplementedException 避免坑他人。 |
 |
44
AlisaDestiny 2017 年 7 月 14 日
@kamen save 方法上是有注释的。只是楼主截图不完整。
|
 |
45
af463419014 2017 年 7 月 14 日
 |
|
46
Lonely 2017 年 7 月 14 日 via iPhone
@af463419014 厉害了
|
Select Language