Как удалить операторы отладки из производственного кода в Java

Использовать Препроцессор Java ? (нечто Google низко, но это - ссылка на старые форумы Joel, обсуждая это)

Java содержит своего рода собственный препроцессор. Это звонило APT. Это обрабатывает и генерирует код. В данный момент я не уверен, как это должно работать (я не попробовал его). Но это, кажется, используется для подобных вещей.

Другая возможность состоит в том, чтобы поместить, если оператор в Вашей функции входа, Вы получаете меньше кода этот путь, но за счет некоторых дополнительных вызовов функции.

я - также не большой поклонник завершенного удаления кода отладки. После того как Вы работаете, Вам, вероятно, будет нужен доступ к сообщениям отладки, если что-то пойдет не так, как надо. Если Вы удаляете всю свою отладку уровня кода, чем это не возможность.

public abstract class Config
{
    public static final boolean ENABLELOGGING = true;
}

import static Config.*;

public class MyClass
{
    public myMethod()
    {
        System.out.println("Hello, non-logging world");

        if (ENABLELOGGING)
        {
            log("Hello, logging world.");
        }
    }
}

компилятор удалит блок кода с "Привет, регистрируя мир". в нем, если ENABLE_LOGGING имеет значение true, потому что это - статическое окончательное значение. Если Вы будете использовать obfuscator, такой как прозащита, то класс Конфигурации исчезнет также.

obfuscator также позволил бы вещи как это вместо этого:

public class MyClass
{
    public myMethod()
    {
        System.out.println("Hello, non-logging world");

        Log.log("Hello, logging world.");
    }
}

import static Config.*;

public abstract class Log
{
    public static void log(String s)
    {
        if (ENABLELOGGING)
        {
            log(s);
        }
    }
}

метод Log#log ни до чего не уменьшил бы в компиляторе и был бы удален obfuscator, наряду с любыми вызовами к тому методу, и в конечном счете даже класс Журнала будет самостоятельно удален.

Непосредственно отвечать на Ваш вопрос: Я не знаю.

, Но вот другое решение Вашей проблемы: В моем уме существует два оператора, которые сталкиваются друг с другом здесь: "отладьте операторы" и "производственный код".

, Какова цель операторов отладки? Справка для избавлений от ошибок, в то время как (единица) тестирование. Если часть программного обеспечения правильно тестируется и работает согласно требованиям, операторы отладки являются почти УСТАРЕВШИМИ.

я категорически не согласен с отъездом любых операторов отладки в производственном коде. Я держал пари, что никто не потрудился тестировать побочные эффекты кода отладки в производственном коде. Код, вероятно, делает то, что он, как предполагается, делает, но он делает больше, чем это? Все Ваши #defines работают правильно и действительно вынимают ВЕСЬ код отладки? Кто анализирует 100 000 строк предварительно обработанного кода, чтобы видеть, не стало ли всего материала отладки?

, Если у нас нет другого определения производственного кода, необходимо рассмотреть вынимание операторов отладки после того, как код тестируется и быть сделанным с ним.

Я также настоятельно рекомендовал бы использование платформы журналирования.

Эти logger.IsDebugEnabled() не обязательно, это просто, что это может быть быстрее, чтобы проверить, является ли система на уровне отладки перед входом.

Используя платформу журналирования означает, что можно настроить регистрирующиеся уровни на лету, не перезапуская приложение.

у Вас мог быть вход как:

logger.error("Something bad happened")
logger.debug("Something bad happend with loads more detail")