C # programming experience and insights of ordinary calculators,

C # programming experience and insights of ordinary calculators,

Prepaid:

 

This is an ordinary calculator written in C #. The function basically imitates the built-in calculator program of Windows 8 (version 6.3 and internal version 9600 ). Supports addition, subtraction, multiplication, division, backspace, clearing, square root, reciprocal, inverse number, four consecutive orders, continuous equal signs, auto-completion, memory, and keyboard input. The calculation result is basically correct because the input in multiple formats is known without crashing.

However, compared with the Windows version, this calculator has many disadvantages: for example, the accuracy cannot reach the latter level; the "display" part only has one row, and the current formula cannot be displayed; the loss of conversion between decimal and binary data was not optimized During computation (for example, 12.45-12.4, that is, "android calculator Bug http://www.guokr.com/article/27173/"); the feature is also easier than the latter.

The calculator program features: The color is more bright, as for the beauty of the beautiful, the benevolent sees the wise, the wise sees the wisdom; because the "display" only one line, design when M contains data, make the MR button color change to prompt; in addition, the number of eggs hidden somewhere is unknown.

 

Let's take a look at your criticism.

(. Net Framework must be installed to run)

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

 

Written sentiment:

1.When starting a job, you should be clear about the plan and have a deep understanding of the target. For example, during programming, I found that the Windows Calculator has the auto-completion function (for example, press the key 1 + 2 = 5 =, display 7, that is, 5 + 2 ). The original mind thought that data can be cleared after the computation is completed.

 

2.The specification of programming style is very important. Naming is a technical task. It must reflect the nature and subordination of a variable, function, and so on. It is good at writing comments to make it concise and effective. Modify the code and comment first. If you write code like a famous C language textbook, it is easy to go astray, and you cannot recognize the program, so you can rewrite it. I think of a Python egg as a reference:

 

 

The Zen of Python, by Tim Peters

Python path

 

Beautiful is better than uugly.

Appearance 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 complexity.

 

Flat is better than nested.

The plane is better than nesting.

 

Sparse is better than dense.

Sparse is better than dense.

 

Readability counts.

Readability needs to be considered.

 

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

The principle should not be broken even in special circumstances,

 

Although practicality beats purity.

Although it is more practical than pure.

 

Errors shoshould never pass silently.

Errors should not be passed quietly,

 

Unless explicitly silenced.

Unless otherwise specified.

 

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

When there is confusion, refuse to guess (thoroughly understand the problem ).

 

There shoshould be one -- and preferably only one -- obvious way to do it.

There is always one, and (ideally) only one, obvious method to solve the problem.

 

Although that way may not be obvious at first unless you're Dutch.

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

 

Now is better than never.

Starting now is better than never starting,

 

Although never is often better than * right * now.

Although never starting is always better than starting immediately.

 

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

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

 

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

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

 

Namespaces are one honking great idea -- let's do more of those!

Namespace is an excellent idea for us to use it more.

 

3.Both general and special cases should be taken into account during testing. I made a random script to generate a random prompt and compare it with the Windows Calculator. I tested 800 rows in a row without any problems. But immediately, I found another BUG. This shows that the representativeness of the random script is not enough. If you really want to use the representative operation test, in fact, 30-50 operations are enough. There are many special keys in the calculator, such as 0, backspace, root number, decimal point, and root number. If you plan the functional objectives of these keys in advance, you can avoid a lot of detours.