C # Programming General Calculator experience and sentiment

Map First:

This is a general-purpose calculator written in the C # language, which basically mimics Windows8 's own calculator program (version 6.3, build 9600). Support Add, subtract, multiply, divide, backspace, clear, square root, reciprocal, inverse number, continuous four, continuous equal sign, auto-fill, memory, keyboard input and other functions. You can handle known forms of input without crashing, and the results are basically correct.

However, this calculator has many disadvantages compared with the Windows self-brought version: for example, the precision cannot reach the latter level; the "Display" section has only one row and cannot display the current operand; no optimizations are made to the decimal and binary conversion data loss during operation (for example, 12.45–12.4, " Android Calculator Bug http://www.guokr.com/article/27173/"), the function is simpler than the latter.

The Calculator program features: The color is more vivid, as for the beauty is not beautiful, the benevolent see of the beholder; because the "display" only one line, design when the data stored in m, so that the Mr Button color changes to prompt, and there is an unknown number of eggs in place.

Below, please criticize the existing problems.

: (Requires the. Net framework to be installed to run)

Http://pan.baidu.com/s/1gdzkigN

Write the sentiment:

1. When starting a job, plan to be clear and have an in-depth understanding of the objectives. For example, I discovered during the programming process that the Windows Calculator has auto-completion capabilities (such as keys 1 + 2 = 5 =, display 7, or 5 + 2). The original thought that the operation is complete, you can clear the data.

2. The specification of the programming style is important. Naming is a technical work, to reflect the nature of a variable, function, and subordinate, let a person at a glance, good at writing notes, make it concise, remain effective. Modify the code and change the comment first. If the code like a well-known C language textbooks, it is easy to go astray, you can not recognize the program, so as to rewrite the road. I thought of a python egg, as a reference:

The Zen of Python, by Tim Peters

The way of Python

Beautiful is better than ugly.

Beauty is better than ugliness.

Explicit is better than implicit.

Display is better than implicit.

Simple is better than complex.

Simplicity is better than complexity.

Complex is better than complicated.

Complexity is better than excessive complexity.

Flat is better than nested.

Planes are better than nesting.

Sparse is better than dense.

Scarcity is better than dense.

Readability counts.

Readability needs to be considered.

Special cases aren ' t special enough to break the rules.

Even if the situation is special, it should not break the principle,

Although practicality beats purity.

Though practicality is better than purity.

Errors should never pass silently.

Mistakes should not be passed silently,

Unless explicitly silenced.

Unless you do it deliberately.

In the face of ambiguity, refuse the temptation to guess.

When there is confusion, refuse to speculate (in-depth understanding of the problem).

There should is one--and preferably only one--obvious the-do it.

There is always one, and (ideally) only one, obvious way to deal with the problem.

Although that is obvious at first unless you ' re Dutch.

Although that method may not be obvious, unless you are Dutch. (the author of Python, Guido, is a Dutch man, and this is a tribute)

Now is better than never.

Now it's better to start than never to start

Although never is often better than *right* now.

Although never start often than rush to start right away.

If the implementation is hard to explain, it's a bad idea.

If the program implementation is difficult to explain, then it is a bad idea.

If the implementation is easy to explain, it could be a good idea.

If the program implementation is easy to explain, it might be a good idea.

Namespaces is one honking great idea – let's do more than those!

Namespaces are a great idea, so let's use them more.

3. in testing, the general situation and special circumstances should be taken into account. I made a random script, generated a random prompt, compared to the Windows Calculator operation, measured 800 lines are no problem. But immediately, the bug was found. This shows that the random script is not representative enough, if you really want to use a representative operation test, actually 30-50 operations is enough. There are many special keys in the calculator, such as 0, backspace, square root, decimal point, radical. Planning these key functions in advance, you can take a lot of detours.

C # Programming General Calculator experience and sentiment