Unreliable coding habits in Asp.net Development

When debugging a program, the process of checking the Code usually skips the code or logic that we think is absolutely impossible to make an error. However, sometimes, when I check it over and over again, I cannot find any possibility of errors, but the program is indeed not running as we imagined. At this time, many people think they have encountered a spiritual event. Almost every programmer has such an experience, but in the end, it is often proved that we are wrong, and should not be too confident in writing our habits.

　　Case 1:

1 bool AllowDisplay = CheckPower ();
2 p. Visible = AllowDisplay;
3if (p. Visible ){
4 // do something;
5}

Note: p is a <p runat = "server" id = "p">... </p> label declared on the aspx page.
At runtime, it is found that the do something part of the code in the if statement cannot be executed in any way, even if the AllowDisplay value is True during debugging!
In the past, similar practices were often used when writing code, without any problems. Now, this simple code is confusing.
Finally, after debugging, the cause is found: Visible = "false" is set in the Declaration Code of the upper-level container control of p for objective purposes "! Therefore, although the Visible attribute of a control is not a read-only attribute, you cannot rashly think that it will be what it is set for it.

　　Case 2:

1 OneClass obj = GetOneClass ();
2if (obj = null ){
3 // do something;
4}

When the program is running, do something code in the if statement cannot be executed. This is not surprising. It is strange that debugging found that an exception occurred in the line of "if (obj = null!
It should be said that no matter whether your obj is a null reference or not, there should be no errors here. This line of code has been written countless times in my C # programming career. How can this problem suddenly happen?
Many people have answered questions on CSDN, but none of them said the real crux of the problem. As a last resort, you can only keep thinking and debugging yourself, and finally find the cause. This is because the operator overload defined in the OneClass class lacks the judgment on whether the target object is null reference in the = Operator overload code, so when the program runs "if (obj = null)", it falls into an endless loop!

A friend in the garden also proposed a better encoding method yesterday, which is written as: if (null = obj ).

The above are some of the problems I encountered when I was involved in the development of a "general information management system" project. There are still many similar seemingly strange phenomena, but most of them get the answer after searching for the network, so they will not be listed one by one.

Finally, let me use a line of text to promote our work: If you are troubled by the expensive and complicated ERP, please go to http://landian.cq.cn/experience the elegant and fashionable blue-DOT General Information Management System, and you will definitely fall in love with her!