zoukankan      html  css  js  c++  java
  • 谈谈几个编程习惯

          一个人的成功有时往往体现在细节上,而习惯往往是这些细节的具体表现形式,这里我也想总结几个不太好的编程习惯。


          第一:下面的一段程序大概的意思就是,页面上有一个属性HighPrice,它最终会通过ViewState保存在页面中,如果ViewState为空,则设置属性HighPrice的值为-1,否则直接读取ViewState中的值。但实际情况并不是这样,程序在初始化时,如果ViewState["HighPrice"]意外的写入了些非数字字符串数字,程序就会抛出异常。

    public int HighPrice {
      
    get
      {
        
    if (ViewState["HighPrice"!= null)
           
    return (int)ViewState["HighPrice"];
        
    else
           
    return -1;
      }
       
    set
       {
           ViewState[
    "HighPrice"= value;
       }
    }


          解决方案:下面给出相对正确的写法。大家如果有更好的写法可以提出参考下。
          说明:(int)ViewState["HighPrice"]这种写法和int.TryParse(ViewState["HighPrice"].ToString(), out _HighPrice);还有是相当大的区别的,因为ViewState["HighPrice"]对象要确保是数字字符串才行,如果不小心给它赋值为空,那么就会出现异常。不要过份相信一个对象的数据类型,特别是这种object类型的,这样写出的程序不健壮。

    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;
                    }
                    
    //把变量值保存到ViewState中
                    ViewState["HighPrice"= this._HighPrice;
                }
            }

          //第二:对于多条件的判断,最典型的要数&&操作符了。如果一个语句的执行需要同时满足两个条件,我们经常会这样写:if(条件一&&条件二),意图是认为条件一和条件二都等于true的情况下,但实际情况是如果两人条件//都是false,那么最后的条件一&&条件二的结果刚好也是true,此时就会出现不可预测的错误。而且这种错误也是非常难查找的。有时候写代码能省就省,不能省的一个也不能少。

          //说明: 1:此条对C#不成立,但其它的语言就不一定,大家可以测试下。

                   //2:由于此条并不适用于主流的语言,写在这有点让园友糊涂,这里表示道歉,但在某种环境上确实存在,起码我遇到过,这里并不要求大家同意我的观点,信则有不信则无,只有当你真正遇到过才会有更深的体会。

         更新:上面的第二条大家都不太认同,不过我遇到的情况和这篇文章差不多:http://directwebremoting.org/blog/joe/2008/02/28/2_wrongs_making_a_right_false_false_true.html ,大家可以参考下,有园友说是因为firebug的一个BUG,这里我特把这条注释掉,这里没有像园友说的嘴硬不承认错误,而是有时候的确有些难以解释的现象出现,而且当改变相应的写法后的确原有的BUG不存在。

          第三:对于if语句的写法。我们大多会这样写:if(条件==true),正常情况下是没有问题,但有时会写成if(条件=true),也就是程序员在写的时候少写了一个等号,造成程序永远执行下面的代码,这种错误查找起来也是相当困难的,因为编译器在编译时并不会报错。


          解决方案:
            1:可以这样写if(true==条件),如果你写成了if(true=条件),编译器会报错,因为true是不能充当左值的。
            2:如果只有一个条件,就直接if(条件),把==true给省略即可,如果是多条件就按方法一来执行。

               说明:1:if(条件=true)这种程序当然并不是程序员想这要写,只是有时会少写一个而已。

                        2:if(条件=true),编译器并不会报错,有园友说会出提示警告,这里大家可以自己取证下。

          第四:对于操作符的重载问题。例如我们想重载“==”,代码如下:两个对象相等的标准就是属性sName相等,程序中一上来就直接p.sName,没有考虑到p对象是否为null,这种也是编译器无法在编译期间判断的。这种代码也只有在程序调试时才比较容易发现,如果你在程序中判断这个自定义类是否为空:if(null==自定义类),我们从程序上来看这里都是不会出问题的,但是在等号重载中没有判断对象的有效性,这对BUG的排查也是相当困难的。

                  说明:这里重载了等号和不等号,这里并不是多余的,而是必须,因为它们必须成对出现。

    /// <summary>
        
    /// 自定义测试类
        
    /// </summary>
        public class a
        {
            
    public string sName
            {
                
    get;
                
    set;
            }
            
    public a(string _sName)
            {
                
    this.sName = _sName;
            }
            
    /// <summary>
            
    /// 重载==操作符
            
    /// </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>
            
    /// 重载!=操作符
            
    /// </summary>
            
    /// <param name="p"></param>
            
    /// <param name="b"></param>
            
    /// <returns></returns>
            public static bool  operator !=(a p, a b)
            {
                return
     !Object.Equals(p, b);
               

            }

        }

           第五:对于数据格式转换。拿字符串转换成数字来说,很多朋友喜欢直接int.Parse(要转换的字符串),如果这个字符串是你期待的数字字符串那没问题,如果字符中为空,或者是存储的中文或者其它非数字字符串,那也是转换失败,其实我们大可利用int.TryParse方法来解决,不成功还有一个默值,起码不能中止程序的运行。

           我大概总结了几个,大家看还有没有些类似的不太好的习惯呢?

      

  • 相关阅读:
    【费用流】【CODEVS】1227 方格取数2
    【CODEVS】1034 家园
    【BZOJ】1066: [SCOI2007]蜥蜴
    【最大流】【CODEVS】1993 草地排水
    【HDU】2191 多重背包问题
    【TYVJ】1520 树的直径
    【BZOJ】1984 月下“毛景树”
    【BZOJ】1588: [HNOI2002]营业额统计
    【NOI】2004 郁闷的出纳员
    【POJ】2892 Tunnel Warfare
  • 原文地址:https://www.cnblogs.com/ASPNET2008/p/1457616.html
Copyright © 2011-2022 走看看