这是一个代码气味问题，但日志记录可能不是首选的选择。我更喜欢接受流参数，以使编写单元测试更容易。例如：

public class Greeter {

    public void greet(String name, PrintWriter out) {
        out.print("Hello, " + name);
    }

}

public class GreeterProgram {

    public static void main(String[] args) {
        new Greeter().greet(args[0], new PrintWriter(System.out));
    }

}

public class GreeterTest {

    @Test
    public void testGreet() {
        StringWriter sw = new StringWriter();
        PrintWriter out = new PrintWriter(sw);
        new Greeter().greet("Zhou", out);
        out.flush();
        assertEquals("greeting", "Hello, Zhou", sw.toString());
    }
}

当你开发一个规模大于5的团队的更大的应用程序时。你必须使用一个框架来记录。对于其他人来说，更容易找到问题的根源是很重要的。
system.out可以在非常小的应用程序或小的团队中使用，在这些应用程序或团队中，您可以进行基本的交流，但不建议使用system.out，因为您希望看到日志，解释为什么应用程序会与相应的数据崩溃，而不是控制台打印输出指出有问题，但是你不知道这是在哪个班级发生的，因为你的队友编码了那个特定的班级。

第一， System.out 不是测井输出的目标，除了非常小的工具或一些一次性的东西；这就是日志框架被发明的原因。在这里，不管您是选择log4j、jdk日志还是其他完全不同的东西，一开始都不重要。尽管log4j是java世界中事实上的日志标准。
因为那些“代码嗅探器”总是假设（除非另行通知）您编写了某种服务器软件，所以当您使用输出时，它们会发出警告 System.out 因为对于这样的服务器，打印到 System.out 或者 /dev/nul …
但是，如果您编写了某种命令行工具（可能是一个批处理客户机到一个服务器，只是为了有另一个示例而不是grep…），那么完全可以将当前状态或其他输出写入 System.out （即使“嗅探者”还在呻吟）“状态”在这里主要是指正反馈；任何错误消息都应该被记录到日志子系统中，尽管将它们打印到屏幕上也是一个好主意。
通常你可以注解你的源代码来安抚“嗅觉探测器”…