在lltong网友的博客 重拾C，一天一点点_7 中看到了一道小题，觉得挺有趣。这个题目是这样的：
有一个人在一个森林里迷路了，他想看一下时间，可是又发现自己没带表。恰好他看到前面有两个小女孩在玩耍，于是他决定过去打听一下。更不幸的是这两个小女孩有一个毛病，姐姐上午说真话，下午就说假话，而妹妹与姐姐恰好相反。但他还是走近去他问她们：“你们谁是姐姐？”胖的说：“我是。”瘦的也说：“我是。”他又问：现在是什么时候？胖的说：“上午。”“不对”，瘦的说：“应该是下午。” 这下他迷糊了，到底他们说的话是真是假？
这个小题之所以引起了我的兴趣，是因为一种直觉：这个题目虽小，但似乎却并不容易写。
有时候我们轻而易举能解决的小问题，反而不容易写出代码。因为问题太简单可能反而会让我们找不到算法。例如，几乎每个人都知道123是一个三位数，但对于初学者来说，写出求123是几位数的代码，却可能难于登天。因为这个问题太容易了，所以反而想不到用不断地除以10的办法来解决这个问题。
因此写小问题的代码，，有时可能很有意义。因为这可以帮助我们发现自己的盲点，清晰自己的思路。
下面就来试解这个问题。
这个问题的一个特点是头绪较多，有姐姐、妹妹，胖子、瘦子，真话、假话，上午、下午，而且这些头绪复杂地交织在一起。这就是这个题目虽然小得可以直接猜到答案但却很不容易用代码解决的原因之一。多个因素，越是微缩化地结合在一起就越不容易解开。通常情况下，解开细绳结比解开粗绳节要难得多。道理是一样的。
编程首先要将问题数值化，也就是把姐姐、妹妹等等都用0，1这样的数值来表示或进行在代码层面的映射。但是由于这种数值表示离我们的思维较远，我们并不习惯甚至根本不会把一切都抽象为数值来进行思考。所以为了更符合人类的思维习惯，为了代码的可读性，多数语言都提供了返璞归真重新回人类思考轨道的手段，比如用宏名替代常量。
另一个常用手段就是枚举(enum)。枚举可以让我们更自然地思考而不是更“机器”地思考。因此，在还没想如何解决问题之前，我就先写下了这样的声明：
因为问题中有上午和下午，所以
typedef enum{上午 ,下午 ,}时间;绊住的不仅是双脚，还有未来。
