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

[EagleB]

先贴上源码地址：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_Month、weekfont、tabHeight、s_width。

---

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

上边有些地方表达不当，让大家误会了。 sorry

[Lonely]

你是说那个整天讲鸡汤的那个胖子吗

[missdeer]

求闰年的算法好像错了

[acoder2013]

tiny fool 是小笨蛋？

[EagleB]

@Lonely 嗯，是

[Nexvar]

技术圈有点小知名度的，有干货的还是不多

[zonghua]

@Nexvar 有个小女友的那位？

[miao1007]

买了那本书，感觉鸡汤感太浓

[tinyfool]

之前其实 V2EX 吐槽这个控件的人还蛮多。不过我很久不怎么上 V2EX ，甚至有时候搜索东西的时候，偶然发现自己被长篇大论的批判了一番都不知道，所以也都没回应。当然，之前包括吐槽这个插件的人，也都是一句话说写得烂，我也不知道该咋回应，所以，看到了也只好由他去了。

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

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

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

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

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

这个代码，我没记错的话，就是闰年有个 bug 改过一次，发布过就没改过了。

[watzds]

😮

[tinyfool]

好，说说代码风格。

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

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

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

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

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

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

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

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

不过，我好像从来没有说过这个日历有多牛，这个日历甚至都没有任何的图片资源，一切都是用字符和画线的方式画的。我的所有描述大概应该都是，在最早的时候， iOS 程序员连日历控件都没有，我需要用的时候怎么办呢？那就自己写一个吧。

[pasturn]

@tinyfool 该用国际化这个词

[tinyfool]

@pasturn 只加了某一国而已，而且当时也没有国际化的基础，代码都是写死的，他也想直接换，但是不会

[FrankFang128]

你这样发帖好么……
谁不知道 Code Review 的体验：

[EagleB]

@tinyfool getDayCountOfaMonth ：我认为在查表的方式好一点；
getDayCountOfaMonth ： if/else 花括号，不是啥问题，个人喜好吧

[EagleB]

@FrankFang128 没事想跟前辈学下，就随便看看。

[tinyfool]

@EagleB

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

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

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

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

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

没错，确实不怎么样，可惜我都找不到了，否则说不定我也可以开源出来（有道同意的话）。不过它的意义在于，让有道至少早了几个月到半年，发版本。对有道的开发者也是一个对 iOS 开发祛魅的过程，原来这么简单就行，这么烂的代码也可以上线，而且下载量这么凶猛，哈哈。

[tinyfool]

我一直懒得开源，我们实现的 iBookAuthor 解析器和 Cocoa touch Android 版，不过回头等我懒癌结束了，欢迎你们去看你，不过请不要揪着代码风格。看看内容，看看具体实现，看看架构，那两个东西蛮好玩的。

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

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


另外，我最近扒了一个 Google 的库，改造成了 Cocoa 的接口，拖延症不加剧的话，也许 1-2 个月会开源，到时候有兴趣可以看看。

[EagleB]

@tinyfool 嗯，我没有别的意思，只想学习一下。 08 年 10 月， iOS 才发布一年多，苹果风格不稳定，这个问题没考虑到。

[tinyfool]

July 11, 2008 iPhone OS 2.0 Final 发布，同时才有的 App Store 。

[Allianzcortex]

@missdeer ？（能被 4 整除且不能被 100 整除）或（能被 400 整除）

[acros]

角度不太对。
评价软件应该看他优点多突出，对于净挑毛病的，应该没几个人有底气....

[l0wkey]

想起了 Dash 的 iOS 版

[missdeer]

@Allianzcortex 手机上只看到 date.year % 4==0 这一截。。。电脑上看到完整的没问题

[kevinreadonly]

@zonghua 恩，那个有钱的死胖子 2333333

[xcodebuild]

大家都看得出来你什么意思，即使你不停的说『没有别的意思』。

[Sirormy]

找上门来不好意思说了，哈哈哈哈哈

[onlyhot]

气氛有点怪

[crisfun]

若要补刀应该让我们见识下什么是经常提

[daniellu]

无可厚非啊，肯开源，就已经很了不起了。
挑毛病，谁不会，从头到尾的起一个控件、写好、开源啊，再说， ios 刚发布的那时候，国内连资料都很少，更加别说开源控件了。
有时间翻翻自己 N 年前写的代码呗，每个人都是在不停的成长的，对不对？

[juice]

@tinyfool 该续费了

[tommyzhang]

code review 别人几年前的代码 然后说 low 相信楼主不是傻逼 就是二百五脑袋被驴提过了

[LedChang]

我觉得楼主说的没毛病

[LedChang]

不知道你们在喷什么，看看当时的代码指出来有问题怎么了，谁不是一点点成长起来的

[tinyfool]

真的不是不能批评，不过，我觉得，做性能优化，我经验比楼主多多了，我就在多少两句吧。关于，那个不用查表，用 Switch-Case 的问题。

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

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

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

我不是说，我这么说一定比查表好。而是，这不是你该关心的问题。如果 profile 说明这里是一个性能攸关点，你做各种尝试都是合理的。在这时候，我觉得想太多。跟讨论回有几个写法差不多。

[imsoso]

好久没见到楼主活人了， mark 一记

[muziki]

Year & 3 == 0 && ( year % 25 != 0 || year & 15 == 0)
判断闰年会快一些

[hotdogwc]

虽然不爱被灌鸡汤，但是讲道理，刚才把代码看了一遍， SDK 发布几个月，资料各种缺失的情况下写出这个东西，我是服的。我觉得“没别的意思”的人应该想想在那个情景下是不是可以写的比这个好，反正我不能。

[greatghoul]

楼主你其实是嫉妒人家有个漂亮可爱的女朋友而已吧。。

[hotdogwc]

@l0wkey Dash 代码我也草草的看了一遍，没看到什么槽点，难道我的代码洁癖严重不足？

[htfy96]

为什么 getDayOfMonth 一定要查表，感觉这么写也挺清晰的

[jun0205]

早期 iOS 开发和现在差别太大，那时候资料少，开源的更少，什么东西都得自己写。
不像现在什么各种优秀的资源都有，没法比较。

[tinyfool]

@muziki 这个谁要写这个代码在我的项目里面，我要打不及格。

第一，不见得快，这个可以跑一个测试，比如比较 100 万次，试试看，我估计不见得快，或者说不见得有显著的性能收益。
第二，可读性下降。
第三，什么场景需要快速计算闰年，全人类才走了几千年，枚举一边，用最慢的算法，也很快出结果。这么去追求效率得不偿失。

[tinyfool]

@juice 续啥费？

[alexsunxl]

@LedChang 喷一喷代码其实没问题， 但总体上感觉楼主太针对人， 这就不太好了。
所以 tiny 叔才不得不出来解释一通

[holyghost]

& 3 比 % 4 快难道不是常识么

我咋就这么瞧不上这些技术圈的网红呢，还有那个什么 justjavac

[wanttofly]

@LedChang “代码格式我就不说了，空格写的很随意，大小写对于我这种强迫症来说也很受不了。最重要的是我认为稍微参考下苹果 framework 中函数的命名方式，就不会写出协议中这么扯淡的命名。 interface 中的命名大多数都还不错，但是-(void)setDayFlag:(int)day flag:(int)flag;这个是什么鬼，我认为- (void)setFlag:(int)flag forDay:(int)day;更好。” 态度有问题，说啥都是白扯。内容没毛病，但是比如说可以小声的告诉“ hi ，你裤子好像有点问题”的情况下为什么要拿着喇叭打声的说“我靠，你的前开门没拉”呢

[tinyfool]

@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]

小码农提一句，这种实际上现实中每天调用都不会超过 5000 次的接口，代码可读性，比那 0.0001 秒的优化有意义多了把

[tinyfool]

@caiyouzai 对的。我以前做搜索， 1 个 ms 都很重要。但是，不是每个代码的 1 个 ms 都要去揪。要找到核心代码，去压榨一点点性能改善，但是调用比较少的，对整体影响不大的，连看都不看。

[tinyfool]

@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]

全文是 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]

@tinyfool tiny 大神好 6 啊

[sumstain77]

@zonghua 哟

[ren2881971]

我觉得这是一个圈粉帖。。。

[holy_sin]

不要把时间花在指责上

[Jaylee]

@holyghost justjavac 就是一个 sb, 见一次骂一次

[timeship]

某位成功把话题转到了优化上

[tinyfool]

@timeship 嗯，成功转移了

[isaced]

“正在看这个贴，老大默默走到我的身后，一巴掌拍向我的脑袋说道：少说话，多做事！”

[tinyfool]

@isaced 嗯，这个代码才 500 行，目前这个帖子应该早就超过 500 行了吧

[fukual66]

莫名想起了当年激动人心的演讲，我在现场，听得我瑟瑟发抖，找回当时评价的链接[地址]( https://www.zhihu.com/question/44019457)

[zengcool]

我一直以为，敢于开源自己项目的人都是勇士。觉得 tinyfool 解释的那么清楚，算是非常认真负责了。我想想自己写过的代码，哎呀，让我死了算了。哈哈~

[sopato]

翻出多年前的代码来找刺，确实有点过分了哈~~~~~