先贴图：

这是用 C# 语言编写的普通型计算器，功能基本模仿 Windows 8.1 自带计算器程序（版本 6.3，内部版本 9600）。支持加、减、乘、除、退格、清除、平方根、倒数、相反数、连续四则、连续等号、自动补齐、记忆、键盘输入等功能。可以应对已知的多种形式输入而不发生崩溃，计算结果基本正确。

但是该计算器与 Windows 自带版本相比还有很多不足，例如：精度无法达到后者水平；“显示屏”部分只有一行，无法显示当前运算式子；未对运算时十进制与二进制相互转化造成数据丢失的现象做优化（例如：，即“安卓计算器 Bug”）；功能相比后者也更为简单。

该计算器程序特点：色彩较为鲜艳，至于美不美，就仁者见仁智者见智了；由于“显示屏”只有一行，设计当 M 中存有数据时，使 MR 按钮颜色变化来提示；另外在某处藏有彩蛋，数目不详。

编写的感悟¶

• 开始一项工作时，计划要清晰，要对目标有深入的了解。例如，我在编程过程中发现，Windows 计算器具有自动补齐功能（如按键 1 + 2 = 5 =，显示 7，即 5 + 2）。而原来头脑中以为，运算完毕，就可以清空数据。

• 编程风格的规范很重要。命名是一个有技术的工作，要反映一个变量、函数等的性质、从属，让人一目了然；善于写注释，使之简明、保持有效。修改代码，先改注释。如果像某著名 C 语言教材一样乱写代码，很容易误入歧途，自己也认不清程序，从而走向重写之路。我想到了 Python 的一个彩蛋，作为参考：

The Zen of Python, by Tim Peters
Python 之道

Beautiful is better than ugly.
美观胜于丑陋。

Explicit is better than implicit.
显式胜于隐式。

Simple is better than complex.
简单胜于复杂。

Complex is better than complicated.
复杂胜于过度复杂。

Flat is better than nested.
平面胜于嵌套。

Sparse is better than dense.
稀少胜于稠密。

Readability counts.
可读性需要考虑。

Special cases aren't special enough to break the rules.
即使情况特殊，也不应打破原则，

Although practicality beats purity.
尽管实用胜于纯净。

Errors should never pass silently.
错误不应悄无声息的通过，

Unless explicitly silenced.
除非特意这么做。

In the face of ambiguity, refuse the temptation to guess.
当有混淆时，拒绝猜测（深入的搞明白问题）。

There should be one-- and preferably only one --obvious way to do it.
总有一个，且（理想情况下）只有一个，明显的方法来处理问题。

Although that way may not be obvious at first unless you're Dutch.
尽管那个方法可能并不明显，除非你是荷兰人。（Python 的作者 Guido 是荷兰人，这是在致敬）

Now is better than never.
现在开始胜过永远不开始，

Although never is often better than right now.
尽管永远不开始经常比仓促立即开始好。

If the implementation is hard to explain, it's a bad idea.
如果程序实现很难解释，那么它是个坏主意。

If the implementation is easy to explain, it may be a good idea.
如果程序实现很容易解释，那么它可能是个好主意。

Namespaces are one honking great idea -- let's do more of those!
命名空间是个绝好的主意，让我们多利用它。

• 在测试时，要兼顾普遍情况和特殊情况。我搞了一个随机脚本，生成随机的提示符，对照 Windows 计算器操作，一连测了 800 行都没有问题。但是马上发给学长测试，又发现了 bug。这说明随机脚本的代表性不够，如果真要用代表性的运算测试，实际上 30 ~ 50 次运算就够了。计算器里面的特殊键有很多，例如 0，退格，根号，小数点，根号。事先计划好这些键的功能目标，可以少走不少弯路。