看了眼 tinyfool 经常提的日历控件 - V2EX
V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
请不要在回答技术问题时复制粘贴 AI 生成的内容
EagleB
V2EX    程序员

看了眼 tinyfool 经常提的日历控件

  •  
  •   EagleB 2016-11-27 18:49:43 +08:00 9005 次点击
    这是一个创建于 3241 天前的主题,其中的信息可能已经有所发展或是发生改变。

    先贴上源码地址:Here 代码是是 08 年写的,这点还是非常服的,这个时候我还在上高中。 08 年到现在 OC 在一些特性上改进很多,其中使用的CFGregorianDate相关 api 在 iOS 8.0 之后也不建议使用了,所以这里我只说我确认不是好的实践的部分。

    先来看下头文件:

    // // CalendarView.h // ZhangBen // // Created by tinyfool on 08-10-26. // Copyright 2008 __MyCompanyName__. All rights reserved. // #import <UIKit/UIKit.h> @protocol CalendarViewDelegate; @interface TdCalendarView : UIView { CFGregorianDate currentMonthDate; CFGregorianDate currentSelectDate; CFAbsoluteTime currentTime; UIImageView* viewImageView; id<CalendarViewDelegate> calendarViewDelegate; int *monthFlagArray; } @property CFGregorianDate currentMonthDate; @property CFGregorianDate currentSelectDate; @property CFAbsoluteTime currentTime; @property (nonatomic, retain) UIImageView* viewImageView; @property (nonatomic, assign) id<CalendarViewDelegate> calendarViewDelegate; -(int)getDayCountOfaMonth:(CFGregorianDate)date; -(int)getMonthWeekday:(CFGregorianDate)date; -(int)getDayFlag:(int)day; -(void)setDayFlag:(int)day flag:(int)flag; -(void)clearAllDayFlag; @end @protocol CalendarViewDelegate<NSObject> @optional - (void) selectDateChanged:(CFGregorianDate) selectDate; - (void) monthChanged:(CFGregorianDate) currentMonth viewLeftTop:(CGPoint)viewLeftTop height:(float)height; - (void) beforeMonthChange:(TdCalendarView*) calendarView willto:(CFGregorianDate) currentMonth; @end 

    代码格式我就不说了,空格写的很随意,大小写对于我这种强迫症来说也很受不了。最重要的是我认为稍微参考下苹果 framework 中函数的命名方式,就不会写出协议中这么扯淡的命名。 interface 中的命名大多数都还不错,但是-(void)setDayFlag:(int)day flag:(int)flag;这个是什么鬼,我认为- (void)setFlag:(int)flag forDay:(int)day;更好。

    下面来看下源文件:

    源文件中定义了全局的几个变量:

    const float headHeight=60; const float itemHeight=35; const float prevNextButtOnSize=20; const float prevNextButtOnSpaceWidth=15; const float prevNextButtOnSpaceHeight=12; const float titleFOntSize=30; const int weekFOntSize=12; 

    这几个变量主要是来控制试图的大小、字体的大小,只有在这个文件内部试哟哦难过,没有用static修饰,不是很明白,可能 tinyfool 记忆里好,不会再工程中其他地方使用相同名字的变量。

    学 C 语言的时候,大概都做过这么一个练习:获取某年某月的天数。来看看 tinyfool 的实现:**

    -(int)getDayCountOfaMonth:(CFGregorianDate)date{ switch (date.month) { case 1: case 3: case 5: case 7: case 8: case 10: case 12: return 31; case 2: if((date.year % 4==0 && date.year % 100!=0) || date.year % 400==0) return 29; else return 28; case 4: case 6: case 9: case 11: return 30; default: return 31; } } 

    interesting ,自行体会一下。

    实现中有很多类似的实践(个人认为这不是好的实践):

    - (void)movePrevMonth{ if(currentMonthDate.month>1) currentMonthDate.month-=1; else { currentMonthDate.mOnth=12; currentMonthDate.year-=1; } [self movePrevNext:0]; } 

    再来看下这个类的析构函数:

    - (void)dealloc { [super dealloc]; free(monthFlagArray); } 

    Excuse me. 这里虽然不太可能出现崩溃的情况,但不是应该先释放子类持有的资源?

    最后,总结一些 tinyfool 的变量命名风格:title_MonthweekfonttabHeights_width


    我观察到的是,如果有人在微博上反驳他什么,他通常的回应是毫无道理(有道理的时候也有,少),其他的不想评价,怕被喷。

    第 1 条附言    2016-11-27 23:44:50 +08:00
    上边有些地方表达不当,让大家误会了。 sorry
    63 条回复    2016-11-28 20:56:42 +08:00
    Lonely
        1
    Lonely  
       2016-11-27 19:05:05 +08:00 via iPhone   1
    你是说那个整天讲鸡汤的那个胖子吗
    missdeer
        2
    missdeer  
       2016-11-27 19:27:35 +08:00 via Android
    求闰年的算法好像错了
    acoder2013
        3
    acoder2013  
       2016-11-27 19:27:43 +08:00   1
    tiny fool 是小笨蛋?
    EagleB
        4
    EagleB  
    OP
       2016-11-27 19:28:25 +08:00
    @Lonely 嗯,是
    Nexvar
        5
    Nexvar  
       2016-11-27 19:46:26 +08:00 via Android   2
    技术圈有点小知名度的,有干货的还是不多
    zonghua
        6
    zonghua  
       2016-11-27 19:49:34 +08:00
    @Nexvar 有个小女友的那位?
    miao1007
        7
    miao1007  
       2016-11-27 20:03:56 +08:00 via Android   1
    买了那本书,感觉鸡汤感太浓
    tinyfool
        8
    tinyfool  
       2016-11-27 20:05:36 +08:00
    之前其实 V2EX 吐槽这个控件的人还蛮多。不过我很久不怎么上 V2EX ,甚至有时候搜索东西的时候,偶然发现自己被长篇大论的批判了一番都不知道,所以也都没回应。当然,之前包括吐槽这个插件的人,也都是一句话说写得烂,我也不知道该咋回应,所以,看到了也只好由他去了。

    既然你这么认真的写,我就聊两句。

    我写过一篇文章,其实提到过这个插件的前因后果,楼主包括其他人也都说我经常提到这个插件。没错,提过很多次,我好像没有说过这个东西有多牛逼。我只是说,在那个时候,大概是 IOS SDK 发布了几个月以后,没有啥日历插件可用,我就做了一个。

    刚有 SDK 的时候,我其实并没有 iOS 设备,虽然很喜欢,但是确实买不起 iPhone ,很多人可能也记得当年 iPhone 其实也并不好买,那时候国内还没有行货呢。我的一个朋友的公司的活动上,抽奖,偏向我让我得到了一个 iPod touch 。我就想写个东西,写啥呢,就想写个记账软件,毕竟月月月光,也希望可以存点钱。设计的思路是首页有个日历,来显示最近一个月啥时候有收支。所以,就需要一个日历控件,当时并没有。就大概花了一个晚上做了一个吧。现在找不到原始的代码库, Google Code 的代码库好像也看不了修改历史了。细节我记得不了,反正这就是一个晚上或者几个晚上搞出来的东西,我那时候的主业是做搜索,基于 lucene 。

    后来,做了两个星期,也就是学 iOS 两个星期后,有个大概样子了。这时候有道词典的人,通过新浪的一个朋友,找到了霍炬,辗转找到了我。他们当时想迅速做一个 iOS 版本占领市场,当时好像金山已经发了版本。但是有道那边,没有有 Mac/iOS 经历的工程师。于是我就答应帮他们做。

    然后,做了一个月上线。我自己的记账软件就搁置了,一直到了 2013 年,我在上海的时候,才想起来,有这么一个搁置了多年的软件,找我的 CTO 补了个结尾,修改了一点 UI ,就上架了。以前有文章写过这个故事。

    这个代码,我没记错的话,就是闰年有个 bug 改过一次,发布过就没改过了。
    watzds
        9
    watzds  
       2016-11-27 20:14:05 +08:00 via Android
    tinyfool
        10
    tinyfool  
       2016-11-27 20:16:06 +08:00
    好,说说代码风格。

    我代码风格一般。写这个代码的时候,我日常写三种语言, Java , Php 和 OC 。代码风格混合,混乱肯定是有的。这个锅我的,我背。总体上是准备走 Apple 风格的,某些部分懒得改了,估计就比较乱了。

    const 是常量,不是变量,不过这里确实比较没有怎么考虑。一开始是没准备开源的,做完了就直接开了。这锅也是我的。

    getDayCountOfaMonth 的实现我没看出来锅在哪里。

    movePrevMonth ,本来就是一个简单的功能,没啥太复杂的思考。

    dealloc 的问题,你可能不知道,在早期 SDK 的时候, bug 比较多,我们要实验各种方法避免内存泄漏,有些写法比较诡异,但是在某个版本下,反而效果是好的。到了今天 SDK 也还是会出现一些问题。

    这个东西开源完了以后的大概 2-3 年,很火,每天都有邮件来咨询各种问题,最早版本,甚至没有 demo 代码和事例。后来问的人多了,就加上了(在项目说明里面,不过 google code 已经把这些部分都吃掉了,维护过 google code 项目的人应该知道)。

    后来,系统提供了一个什么方法我记不得了,而且开源的日历比较多,而且都比这个好看,这个慢慢就无人问津了吧。

    最搞笑的是,曾经有个人想把这个东西汉化(操,不知道用什么词好,本地化?)成老挝语,还是柬埔寨语来着,但是代码不是完全看得懂,还写了长篇大论来问我。

    不过,我好像从来没有说过这个日历有多牛,这个日历甚至都没有任何的图片资源,一切都是用字符和画线的方式画的。我的所有描述大概应该都是,在最早的时候, iOS 程序员连日历控件都没有,我需要用的时候怎么办呢?那就自己写一个吧。
    pasturn
        11
    pasturn  
       2016-11-27 20:26:15 +08:00 via iPhone
    @tinyfool 该用国际化这个词
    tinyfool
        12
    tinyfool  
       2016-11-27 20:28:46 +08:00
    @pasturn 只加了某一国而已,而且当时也没有国际化的基础,代码都是写死的,他也想直接换,但是不会
    FrankFang128
        13
    FrankFang128  
       2016-11-27 20:31:50 +08:00   1
    你这样发帖好么……
    谁不知道 Code Review 的体验:

    EagleB
        14
    EagleB  
    OP
       2016-11-27 20:46:23 +08:00
    @tinyfool getDayCountOfaMonth :我认为在查表的方式好一点;
    getDayCountOfaMonth : if/else 花括号,不是啥问题,个人喜好吧
    EagleB
        15
    EagleB  
    OP
       2016-11-27 20:53:17 +08:00
    @FrankFang128 没事想跟前辈学下,就随便看看。
    tinyfool
        16
    tinyfool  
       2016-11-27 20:57:27 +08:00
    @EagleB

    我觉得你看问题太浮于表面了,这个代码不是不能挑问题,问题很多。

    问题是,去挑 1 个 500 行,在 iOS 包括苹果官方,大多数编码规则还在形成期的代码的风格问题,唉。

    在那个时间阶段,比较像现在 Swift ,每次升级 iOS SDK ,里面项目模版的写法都会变的一塌糊涂,连苹果的风格都没稳定下来。

    关注些更有意义的事情,和更有意义的人吧。

    如果你能看到,有道词典 iOS 版第一版的代码,估计你也会觉得很烂。

    没错,确实不怎么样,可惜我都找不到了,否则说不定我也可以开源出来(有道同意的话)。不过它的意义在于,让有道至少早了几个月到半年,发版本。对有道的开发者也是一个对 iOS 开发祛魅的过程,原来这么简单就行,这么烂的代码也可以上线,而且下载量这么凶猛,哈哈。
    tinyfool
        17
    tinyfool  
       2016-11-27 21:03:50 +08:00
    我一直懒得开源,我们实现的 iBookAuthor 解析器和 Cocoa touch Android 版,不过回头等我懒癌结束了,欢迎你们去看你,不过请不要揪着代码风格。看看内容,看看具体实现,看看架构,那两个东西蛮好玩的。

    前者还好。后者光把环境搭起来,编译好全部的依赖可能就需要一个小时。

    要是真有天我们开了,欢迎去研究研究。


    另外,我最近扒了一个 Google 的库,改造成了 Cocoa 的接口,拖延症不加剧的话,也许 1-2 个月会开源,到时候有兴趣可以看看。
    EagleB
        18
    EagleB  
    OP
       2016-11-27 21:08:59 +08:00
    @tinyfool 嗯,我没有别的意思,只想学习一下。 08 年 10 月, iOS 才发布一年多,苹果风格不稳定,这个问题没考虑到。
    tinyfool
        19
    tinyfool  
       2016-11-27 21:14:03 +08:00
    July 11, 2008 iPhone OS 2.0 Final 发布,同时才有的 App Store 。
    Allianzcortex
        20
    Allianzcortex  
       2016-11-27 21:19:12 +08:00
    @missdeer ?(能被 4 整除且不能被 100 整除)或(能被 400 整除)
    acros
        21
    acros  
       2016-11-27 21:23:17 +08:00 via iPhone
    角度不太对。
    评价软件应该看他优点多突出,对于净挑毛病的,应该没几个人有底气....
    l0wkey
        22
    l0wkey  
       2016-11-27 21:27:46 +08:00
    想起了 Dash 的 iOS 版
    missdeer
        23
    missdeer  
       2016-11-27 22:58:58 +08:00
    @Allianzcortex 手机上只看到 date.year % 4==0 这一截。。。电脑上看到完整的没问题
    kevinreadonly
        24
    kevinreadonly  
       2016-11-27 23:02:00 +08:00
    @zonghua 恩,那个有钱的死胖子 2333333
    xcodebuild
        25
    xcodebuild  
       2016-11-27 23:29:07 +08:00 via Android   3
    大家都看得出来你什么意思,即使你不停的说『没有别的意思』。
    Sirormy
        26
    Sirormy  
       2016-11-28 00:42:46 +08:00 via Android
    找上门来不好意思说了,哈哈哈哈哈
    onlyhot
        27
    onlyhot  
       2016-11-28 00:51:25 +08:00 via iPhone
    气氛有点怪
    crisfun
        28
    crisfun  
       2016-11-28 03:07:52 +08:00 via iPhone
    若要补刀应该让我们见识下什么是经常提
    daniellu
        29
    daniellu  
       2016-11-28 08:16:55 +08:00
    无可厚非啊,肯开源,就已经很了不起了。
    挑毛病,谁不会,从头到尾的起一个控件、写好、开源啊,再说, ios 刚发布的那时候,国内连资料都很少,更加别说开源控件了。
    有时间翻翻自己 N 年前写的代码呗,每个人都是在不停的成长的,对不对?
    juice
        30
    juice  
       2016-11-28 09:07:30 +08:00
    @tinyfool 该续费了
    tommyzhang
        31
    tommyzhang  
       2016-11-28 09:17:05 +08:00   2
    code review 别人几年前的代码 后说 low 相信楼主不是傻逼 就是二百五脑袋被驴提过了
    LedChang
        32
    LedChang  
       2016-11-28 09:21:36 +08:00
    我觉得楼主说的没毛病
    LedChang
        33
    LedChang  
       2016-11-28 09:22:37 +08:00
    不知道你们在喷什么,看看当时的代码指出来有问题怎么了,谁不是一点点成长起来的
    tinyfool
        34
    tinyfool  
       2016-11-28 09:40:00 +08:00   2
    真的不是不能批评,不过,我觉得,做性能优化,我经验比楼主多多了,我就在多少两句吧。关于,那个不用查表,用 Switch-Case 的问题。

    这么说话都是半瓶子咣当,性能优化不是教条,不是说,老师说这么写对的就这么写。性能优化是一个一直在变的东西,唯一可以相信的是 profile 。

    第一,不要过早优化。
    第二,这是一个有限条件选择,不涉及到问题增长速度。
    第三,编译器如果觉得这里值得优化成一个 table 会动手的。
    第四,性能优化,要理解一个代码调用频度场景。这个函数会被调用几次呢?大概,只在日历初始化的时候,调用一次,翻页的时候,调用一次。翻一次页,人工都设置了一个动画, 0.5 秒,还是多少记不得了。然而,这里用 Switch-Case 还是查表性能差异可能对产品性能产生影响么?

    写代码的时候,第一优先是可读性。这个代码其实可读性也一般,因为说过了,基本上就是一晚上随手写的,后来也没改过。性能一定要在 profile 的前提下去做。我们的学校教育,教育出来一堆纸上谈兵的性能知识,很多还是错的。比如很多类似的技巧,在编译器优化前提下,根本不存在了。比如当年谭浩强的书里面给你讲了一堆,在某个编译器可能成成立,在另外一个编译器不能成立的技巧。

    我不是说,我这么说一定比查表好。而是,这不是你该关心的问题。如果 profile 说明这里是一个性能攸关点,你做各种尝试都是合理的。在这时候,我觉得想太多。跟讨论回有几个写法差不多。
    imsoso
        35
    imsoso  
       2016-11-28 09:51:26 +08:00
    好久没见到楼主活人了, mark 一记
    muziki
        36
    muziki  
       2016-11-28 09:57:08 +08:00 via iPhone
    Year & 3 == 0 && ( year % 25 != 0 || year & 15 == 0)
    判断闰年会快一些
    hotdogwc
        37
    hotdogwc  
       2016-11-28 09:58:15 +08:00
    虽然不爱被灌鸡汤,但是讲道理,刚才把代码看了一遍, SDK 发布几个月,资料各种缺失的情况下写出这个东西,我是服的。我觉得“没别的意思”的人应该想想在那个情景下是不是可以写的比这个好,反正我不能。
    greatghoul
        38
    greatghoul  
       2016-11-28 10:00:08 +08:00
    楼主你其实是嫉妒人家有个漂亮可爱的女朋友而已吧。。
    hotdogwc
        39
    hotdogwc  
       2016-11-28 10:00:49 +08:00
    @l0wkey Dash 代码我也草草的看了一遍,没看到什么槽点,难道我的代码洁癖严重不足?
    htfy96
        40
    htfy96  
       2016-11-28 10:02:35 +08:00 via Android
    为什么 getDayOfMonth 一定要查表,感觉这么写也挺清晰的
    xAI
        41
    xAI  
       2016-11-28 10:03:33 +08:00
    早期 iOS 开发和现在差别太大,那时候资料少,开源的更少,什么东西都得自己写。
    不像现在什么各种优秀的资源都有,没法比较。
    tinyfool
        42
    tinyfool  
       2016-11-28 10:13:47 +08:00   1
    @muziki 这个谁要写这个代码在我的项目里面,我要打不及格。

    第一,不见得快,这个可以跑一个测试,比如比较 100 万次,试试看,我估计不见得快,或者说不见得有显著的性能收益。
    第二,可读性下降。
    第三,什么场景需要快速计算闰年,全人类才走了几千年,枚举一边,用最慢的算法,也很快出结果。这么去追求效率得不偿失。
    tinyfool
        43
    tinyfool  
       2016-11-28 10:21:13 +08:00
    @juice 续啥费?
    alexsunxl
        44
    alexsunxl  
       2016-11-28 10:22:50 +08:00
    @LedChang 喷一喷代码其实没问题, 但总体上感觉楼主太针对人, 这就不太好了。
    所以 tiny 叔才不得不出来解释一通
    holyghost
        45
    holyghost  
       2016-11-28 10:24:22 +08:00
    & 3 比 % 4 快难道不是常识么

    我咋就这么瞧不上这些技术圈的网红呢,还有那个什么 justjavac
        46
    wanttofly  
       2016-11-28 10:40:25 +08:00
    @LedChang “代码格式我就不说了,空格写的很随意,大小写对于我这种强迫症来说也很受不了。最重要的是我认为稍微参考下苹果 framework 中函数的命名方式,就不会写出协议中这么扯淡的命名。 interface 中的命名大多数都还不错,但是-(void)setDayFlag:(int)day flag:(int)flag;这个是什么鬼,我认为- (void)setFlag:(int)flag forDay:(int)day;更好。” 态度有问题,说啥都是白扯。内容没毛病,但是比如说可以小声的告诉“ hi ,你裤子好像有点问题”的情况下为什么要拿着喇叭打声的说“我靠,你的前开门没拉”呢
    tinyfool
        47
    tinyfool  
       2016-11-28 10:41:22 +08:00   1
    @holyghost 没错,这是常识,不过我懒得细看你的实现。

    我做了一个简单的 benchmark 你可以看看

    //
    // main.m
    // testleapyear
    //
    // Created by Peiqiang Hao on 2016/11/28.
    // Copyright 2016 年 Peiqiang Hao. All rights reserved.
    //

    #import <Foundation/Foundation.h>

    int main(int argc, const char * argv[]) {
    @autoreleasepool {
    // insert code here...

    NSTimeInterval t1 = [[NSDate date] timeIntervalSince1970];

    for (int i = 0; i< 1000000; i++) {

    int year = i;
    int leapYear = (year & 3) == 0 && ((year % 25) != 0 || (year & 15) == 0);
    }
    NSTimeInterval t2 = [[NSDate date] timeIntervalSince1970];
    NSLog(@"%g",t2-t1);

    t1 = [[NSDate date] timeIntervalSince1970];
    for (int i = 0; i< 1000000; i++) {

    int year = i;
    int leapYear = ((year % 4==0 && year % 100!=0) || year % 400==0);
    }
    t2 = [[NSDate date] timeIntervalSince1970];
    NSLog(@"%g",t2-t1);

    }
    return 0;
    }

    结果是:

    2016-11-28 10:37:54.885253 testleapyear[16140:987950] 0.00339603
    2016-11-28 10:37:54.893403 testleapyear[16140:987950] 0.00789499

    在 100 万次调用下,你的实现比我快了 4 个毫秒。在我看来,这样的优化,千万不要做,得不偿失。当然如果你觉得我的测试条件写错了,你可以改,我可以再跑一次。运行环境是我的 rmbp 15 寸低配,去年中期的配置。
    caiyouzai
        48
    caiyouzai  
       2016-11-28 10:47:09 +08:00
    小码农提一句,这种实际上现实中每天调用都不会超过 5000 次的接口,代码可读性,比那 0.0001 秒的优化有意义多了把
    tinyfool
        49
    tinyfool  
       2016-11-28 10:50:21 +08:00
    @caiyouzai 对的。我以前做搜索, 1 个 ms 都很重要。但是,不是每个代码的 1 个 ms 都要去揪。要找到核心代码,去压榨一点点性能改善,但是调用比较少的,对整体影响不大的,连看都不看。
    tinyfool
        50
    tinyfool  
       2016-11-28 11:07:05 +08:00
    @holyghost 我没有说你的知识不对的意思。包括 @EagleB

    高德纳老师有句话叫做“过早优化是万恶之源。”,原文, We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil.

    当你关心了一个明显不是性能攸关的点的时候,我就担心你的大局观了。刚才说了求月日数,一次翻页才调用一次,闰年判断也如此。这根本不是性能攸关点。

    其次,一个操作比另外一个操作快,是很常见的。这很正常,但是,按照刚才的 benchmark 在当前测试条件下快了不到一倍。如果本身很耗时,不到一倍也是不错的回报。问题是运行 100 万次都才 7 个 ms ,这快了一倍叫做没有收益。

    在实战的性能优化里面,我们关心的第一是运行多次的,性能攸关点。复杂度的增长速度。以及那些差异到了 100-1000 倍,甚至更大的操作。比如内存和硬盘,有了 SSD 没差那么远了,但是仍旧很大。比如硬盘的连续读写和随机读写,比如硬盘,内存和网络。

    现在的问题是,卡马克的某个优化很牛逼,某个图形算法里面乘除 2 用位运算(不管是图形算法啦,系统库里面多了去了),这些都没错。

    但是人家也不是每句话,都要把乘除 2 改为位运算的。计算机发展的早期,确实有很多这么干的,但是慢慢的都认识到了,有些优化要做,某些最好不做,最好不早做。
    tinyfool
        51
    tinyfool  
       2016-11-28 11:19:37 +08:00   1
    全文是 We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%. 刚才少引用了最后一句。

    跟我之前做 Java 性能优化的体验一致,一个日撑 10 万次请求的服务,我优化到了 30 万,后来 300 万,后来 3000 万。其实没改多少代码,每一步的核心都是找当年的性能瓶颈在哪里。

    我们家 CTO 当年优化的一个 iOS 的地图点聚合问题,源代码是苹果 WWDC 的一个 Demo 代码,从全屏 5000 个点,聚合一次需要 22 秒,优化到了几十毫秒,他优化了 7-8 个不同的地方,但是优化的代码量并不大。核心还是找出关键问题。
    tommybiteme
        52
    tommybiteme  
       2016-11-28 12:03:30 +08:00
    @tinyfool tiny 大神好 6 啊
    sumstain77
        53
    sumstain77  
       2016-11-28 13:15:17 +08:00
    @zonghua
    ren2881971
        54
    ren2881971  
       2016-11-28 13:24:56 +08:00
    我觉得这是一个圈粉帖。。。
    holy_sin
        55
    holy_sin  
       2016-11-28 13:25:55 +08:00
    不要把时间花在指责上
    Jaylee
        56
    Jaylee  
       2016-11-28 14:10:11 +08:00   1
    @holyghost justjavac 就是一个 sb, 见一次骂一次
    timeship
        57
    timeship  
       2016-11-28 14:55:46 +08:00
    某位成功把话题转到了优化上
    tinyfool
        58
    tinfool  
       2016-11-28 15:03:12 +08:00
    @timeship 嗯,成功转移了
    isaced
        59
    isaced  
       2016-11-28 15:17:53 +08:00   1
    “正在看这个贴,老大默默走到我的身后,一巴掌拍向我的脑袋说道:少说话,多做事!”
    tinyfool
        60
    tinyfool  
       2016-11-28 15:25:57 +08:00
    @isaced 嗯,这个代码才 500 行,目前这个帖子应该早就超过 500 行了吧
    fukual66
        61
    fukual66  
       2016-11-28 16:51:50 +08:00
    莫名想起了当年激动人心的演讲,我在现场,听得我瑟瑟发抖,找回当时评价的链接[地址]( https://www.zhihu.com/question/44019457)
    zengcool
        62
    zengcool  
       2016-11-28 20:11:37 +08:00
    我一直以为,敢于开源自己项目的人都是勇士。觉得 tinyfool 解释的那么清楚,算是非常认真负责了。我想想自己写过的代码,哎呀,让我死了算了。哈哈~
    sopato
        63
    sopato  
       2016-11-28 20:56:42 +08:00
    翻出多年前的代码来找刺,确实有点过分了哈~~~~~
    关于     帮助文档     自助推广系统     博客     API     FAQ     Solana     1021 人在线   最高记录 6679       Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 30ms UTC 18:07 PVG 02:07 LAX 11:07 JFK 14:07
    Do have faith in what you're doing.
    ubao snddm index pchome yahoo rakuten mypaper meadowduck bidyahoo youbao zxmzxm asda bnvcg cvbfg dfscv mmhjk xxddc yybgb zznbn ccubao uaitu acv GXCV ET GDG YH FG BCVB FJFH CBRE CBC GDG ET54 WRWR RWER WREW WRWER RWER SDG EW SF DSFSF fbbs ubao fhd dfg ewr dg df ewwr ewwr et ruyut utut dfg fgd gdfgt etg dfgt dfgd ert4 gd fgg wr 235 wer3 we vsdf sdf gdf ert xcv sdf rwer hfd dfg cvb rwf afb dfh jgh bmn lgh rty gfds cxv xcv xcs vdas fdf fgd cv sdf tert sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf shasha9178 shasha9178 shasha9178 shasha9178 shasha9178 liflif2 liflif2 liflif2 liflif2 liflif2 liblib3 liblib3 liblib3 liblib3 liblib3 zhazha444 zhazha444 zhazha444 zhazha444 zhazha444 dende5 dende denden denden2 denden21 fenfen9 fenf619 fen619 fenfe9 fe619 sdf sdf sdf sdf sdf zhazh90 zhazh0 zhaa50 zha90 zh590 zho zhoz zhozh zhozho zhozho2 lislis lls95 lili95 lils5 liss9 sdf0ty987 sdft876 sdft9876 sdf09876 sd0t9876 sdf0ty98 sdf0976 sdf0ty986 sdf0ty96 sdf0t76 sdf0876 df0ty98 sf0t876 sd0ty76 sdy76 sdf76 sdf0t76 sdf0ty9 sdf0ty98 sdf0ty987 sdf0ty98 sdf6676 sdf876 sd876 sd876 sdf6 sdf6 sdf9876 sdf0t sdf06 sdf0ty9776 sdf0ty9776 sdf0ty76 sdf8876 sdf0t sd6 sdf06 s688876 sd688 sdf86