今天在apache项目中看到如此代码,好郁闷, 大家来看看吧, 随便散fen

不过就是多了一个isDebug的无用变量嘛。也不是什么大的问题。
不过别人在使用log4j或者commons-logging的时候在debug之前进行debug-enable判断确实是符合规范的。

楼主是说，apache的代码也有垃圾？？

这个不是垃圾，是因为如果在前面加一个判断的话，可以减少调用log的次数，因为有些log是很花时间的，虽然不用写到log中但也花了一定的时间。

这段代码是输出日志的
在控制台，也在log文件里面

我想仅仅看这两行代码就说有问题,未免优点太武断了,也许变量isDebug在其他地方用到了

汗~~
处理日志的地方都应该有这样的代码阿！怎么是垃圾代码？？
debug日志只在程序调试阶段才用到，真正运行时就应该关掉。我做的所有项目都是这样写的，有什么问题么？？？

不好意思，没看清问题，原来楼主是说那个debug变量啊，好像是有点奇怪。

也许，那个isDebug = log.isDebugEnabled();的isDebug 在别的地方使用了，只从这两行代码上就断定，可能有些太武断了！祝你好运！

146行: isDebug = log.isDebugEnabled();
147行: if(log.isDebugEnabled()) log.debug("In AxisServletBase init
呵呵，大家看清楚搂猪的意思。
147行代码中的log.isDebugEnabled()，应该改为isDebug
146已经调用log.isDebugEnabled()，147再调用一次log.isDebugEnabled()，浪费时间。
这么多人都说没有问题，所以，这种代码的存在是有土壤的啦！不用大惊小怪。呵呵。

用intelliJ就知道有哪些变量是没用到的了,指示灯会变黄色的:D

我再次申明一下我的观点: 谁都有可能范一些低级的失误(或错误),即使apache这样的优秀的项目也有. 不过看来楼上各位的回答我更感觉apache 的优秀的:-(

楼主优秀的项目<>优秀的代码
优秀的项目+优秀的代码 = 经典
优秀的项目著作 = 成功
优秀的代码经验 = ?

呵呵1！你好像没有看过buglist吧！！这点错误就发感慨1！！！设计上多找找！！这种一眼就看出来的问题，用工具都能check出来！！你能看出来，还当件大事

to: aprim(四楞子)
isDebug在后面还有用来做判断,是否也能check出来,我的意思是没有必要调用两次log.isDebugEnabled(),多掉几次也是没有的,就怕像这样的代码放到循环里面去啦, 呵呵,你说会怎么样,(呵呵也不就是影响点速度是吗,我只是大惊小怪而已).希望大家继续bt,yy,分不够我再加反正我好有6k多分啦

apache上的项目，总体的设计才是真正我们应该学学的，具体到代码的确是无非保证质量。我在tomcat里就看见不少起码我认为比较糟糕的code

就放到循环里又会如何影响速度？isDebugEnabled()方法不过是一个简单的delegation而已，对它的调用会被JVM优化掉，根本对速度毫无影响。

接分接分hehe, lou zhu fei chang zi xi ya!

pf pf啊。这么叼的事也能看出来。

单纯的看这两段代码，每一个code都会觉得有点。。不知道搂主有没有注意到，整个的Axis工程中所有的log.debug()都判断时都
使用了if(log.isDebugEnabled()) log.debug("debug信息。");呢！！（包括apache的所有project）
以搂主的意思是不是，所有的这样的代码都应该改成if(AxisServletBase.isDebug) log.debug("debug信息。");呢！！到底这段代码为什么这样写呢！你还是好好想一想吧！到底是那种更好呢！！相信
大家都有自己的判断吧！如果你要把他写到循环中..heihei...没人能反对，不过我还真的很少见有人这么做希望你看程序的时候能多关注一下，设计方面的，而不是这样的地方。

to : aprim(四楞子) 呵呵, 你说这种也是太极端了吧, 因为这一个方法中有n多地方用到了log.debug("")方法,而且在那个方法中已经声明了isDebug的变量而且在后续调用log.debug("")之前的判断都是用isDebug来判断的,而不是这么写的if (log.isDebugEnabled()). 所以认为这时代码实现者的疏忽、失误而导致的。这样的代码在jdk的源码中是看不到的，不知道你在jdk源码中看到了类似的代码没有？

###class AxisServletBase    /**
     * our initialize routine; subclasses should call this if they override it
     */
   public void init() {
        ServletContext context = getServletConfig().getServletContext();        webInfPath = context.getRealPath("/WEB-INF");
        homeDir = context.getRealPath("/");        isDebug = log.isDebugEnabled();
        if(log.isDebugEnabled()) log.debug("In AxisServletBase init");
        isDevelopment= JavaUtils.isTrueExplicitly(getOption(context,
                        INIT_PROPERTY_DEVELOPMENT_SYSTEM, null));    }
/////////////////////////////////////////////////////////////////////////////
    /**
     * This is a uniform method of initializing AxisServer in a servlet
     * context.
     * @todo add catch for not being able to cast the context attr to an
     * engine and reinit the engine if so.
     */
    public static AxisServer getEngine(HttpServlet servlet) throws AxisFault
    {
        AxisServer engine = null;
        if (isDebug)
            log.debug("Enter: getEngine()");        ServletContext context = servlet.getServletContext();
        synchronized (context) {
            engine = retrieveEngine(context);
            if (engine == null) {
                Map environment = getEngineEnvironment(servlet);                engine = AxisServer.getServer(environment);
                storeEngine(context, engine);
            }
        }        if (isDebug)
            log.debug("Exit: getEngine()");        return engine;
    }
/////////////////////////////////////////////////////////////////////////////
那个方法中有n多个地方调用了log.debug();????请注意这个isDebug是一个static private 变量
而且也只被调用了两次，目的很明确，这个变量不是为init()方法提供的，而是专门为
public static AxisServer getEngine()方法提供的。（服务启动和不启动对是否log.debug()是有影响的）所以，在init()方法中只为该变量赋值，而不使用它。使程序仍然有良好的可读性、可维护性。并非程序员的失误。另外：这样的代码在jdk源码中是见不到的
呵呵，你读过jdk的原码吗？在jdk中根本就没有任何一个类有debug级别的代码（99%没有任何log）！当然见不到了。
就算jdk中没有这样的代码就能说jdk写的没有问题吗！
众所周知，Vector和其他众多处于同源的其它List，接口函数上，却有着很大的不同。多去apache的maillist看看，比这严重几百倍的问题有都是！你这种问题发上去是不会有人给你回复的。其实最后我还是那一句话：”希望你看程序的时候能多关注一下设计方面的，而不是这样的地方。”

调试易

今天在apache项目中看到如此代码,好郁闷, 大家来看看吧, 随便散fen

解决方案 »