Some programming habits

A person's success is often reflected in details, and habits are often the specific forms of these details. Here I also want to summarize a few bad programming habits.

First:The following sectionProgramThe general meaning is that there is a property highprice on the page, which will be saved in the page through viewstate. If viewstate is empty, set the value of the property highprice to-1, otherwise, the value in viewstate is read directly. However, this is not the case. during initialization, if viewstate ["highprice"] accidentally writes some non-numeric string numbers, the program will throw an exception.

Public   Int Highprice {
Get
{
If (Viewstate [ " Highprice " ] ! =   Null )
Return ( Int ) Viewstate [ " Highprice " ];
Else
Return   - 1 ;
}
Set
{
Viewstate [ " Highprice " ] = Value;
}
}

Solution: The correct statement is provided below. For more information, see.
Note :( Int ) Viewstate [ " Highprice " ] This write MethodInt. Tryparse (viewstate ["Highprice"]. Tostring (),Out_ Highprice); There is a big difference, because viewstate ["Highprice"] The object must be a numeric string. If it is accidentally assigned a null value, an exception occurs. Do not overtrust the data type of an object, especially the object type, so that the program written is not robust.

Private   Int _ Highprice =   - 1 ;
Public   Int Highprice
{
Get
{
If ( Null ! = Viewstate [ " Highprice " ])
{
Int . Tryparse (viewstate [ " Highprice " ]. Tostring (), Out _ Highprice );
}
Return   This . _ Highprice;
}
Set
{
This . _ Highprice = Value;
If ( Null   = Viewstate [ " Highprice " ])
{
This . _ Highprice =   - 1 ;
}
// Save the variable value to viewstate.
Viewstate [ " Highprice " ] =   This . _ Highprice;
}
}

 

//Second, the most typical number & operator for multi-condition judgment.If the execution of a statement needs to satisfy two conditions at the same time, we often write like this: If (condition 1 & condition 2), the intention is to think that both conditions one and two are true, however, if both conditions are false, the final result of condition 1 & condition 2 is true, and an unpredictable error occurs. This error is also very difficult to find. Sometimes writeCodeIt can save, but it cannot save.

//Note: 1:This article is not true for C #, but not necessarily for other languages. You can test it.

// 2: Because this article does not apply to mainstream languages, it is a bit confusing for garden friends. I apologize for it, but it does exist in some environment. At least I have met it, this does not require everyone to agree with my point of view. If you believe it or not, you will have no more experience.

Update:The second article above is not quite recognized by everyone, but the situation I encountered and this articleArticleSimilar:Http://directwebremoting.org/blog/joe/2008/02/28/2_wrongs_making_a_right_false_false_true.htmlFor your reference, some yuan you said it was because of a bug in firebug. Here I comment out this article. Here, I did not say that I did not admit the mistake as I said by Yuan You, but sometimes it is difficult to explain the phenomenon, and when the corresponding writing changes, it is true that the original bug does not exist.

Third: Write the if statement.Most of us write like this: If (condition = true), normally there is no problem, but sometimes it is written as if (condition = true ), that is to say, when a programmer writes less than one equal sign, the program will always execute the following code. It is also very difficult to find such errors, because the compiler will not report errors during compilation.

Solution:
1: You can write if (true = condition) in this way. If you write if (true = condition), the compiler reports an error because true cannot act as the left value.
2: if there is only one condition, if (condition) is used directly and = true is omitted. If multiple conditions are used, the execution is performed by the method.

Description: 1: If (condition = true) is certainly not a programmer who wants to write this program, but sometimes writes less.

2: If (condition = true), the compiler will not report an error. Some garden friends say they will prompt a warning. Here you can collect evidence on your own.

4. Operator overloading.For example, if we want to reload "=", the Code is as follows: the two objects are equal to the same standard, that is, the sname attribute is equal, and P is directly used in the program. sname does not take into account whether the P object is null, which cannot be determined by the compiler during compilation. This kind of code can be easily found only during program debugging. If you determine whether the custom class is null in the program: If (null = custom class ), from the perspective of the program, there will be no problems here, but the object's validity is not judged in the equal sign overload, which is also very difficult to troubleshoot the bug.

Note: here the equal sign and non-equal sign are reloaded, which are not redundant but mandatory because they must appear in pairs.

///   <Summary>
/// Custom test class
///   </Summary>
Public   Class A
{
Public   String Sname
{
Get ;
Set ;
}
Public A ( String _ Sname)
{
This . Sname = _ Sname;
}
///   <Summary>
/// Overload = Operator
///   </Summary>
///   <Param name = "p"> </param>
///   <Param name = "B"> </param>
///   <Returns> </returns>
Public   Static   Bool Operator   = (A p, a B)
{
If (P. sname = B. sname)
{ Return   True ;}
Else
{ Return   False ;}
}
///   <Summary>
/// Reload! = Operator
///   </Summary>
///   <Param name = "p"> </param>
///   <Param name = "B"> </param>
///   <Returns> </returns>
Public   Static   Bool Operator   ! = (A p, a B)
{
Return ! Object. Equals (p, B );

}< P>

}

Fifth: for data format conversion. If you convert a string to a number, many friends prefer to use int directly. parse (the string to be converted). If this string is the expected numeric string, no problem. If it is null, or the Stored Chinese or other non-numeric strings, that is also a conversion failure. In fact, we can use Int. the tryparse method is used to solve the problem. If the program fails to run successfully, there is a silence value. At least the program cannot be stopped.

I have summarized a few points. Do you still have some similar bad habits?