News for hackers. Stuff that matters.
Re:Get rid of boolean function parameters by paulmd on Monday June 15, 2015 @11:04AM (#9719765)
For that situation the least-smelly answer is logger classes with a severity method

  logger.error("message")
or a log statement with a severity parameter

  logger.log(LOGLEVEL.ERROR, "message")
That lets you change the capture level based on the situation without the need to recompile your application, on a fine granularity (eg class-level). Getting errors in production? Edit one line of XML to turn up the capture level and go.

High-performance logging frameworks like SLF4J handle the first case very intelligently, there's almost no overhead to skipping a logging call. If used wisely with a high-performance logging engine (Log4j2 or Logback) there shouldn't be many calls needed, and except in very narrow situations the performance impact (if you could find one) would be drastically outweighed by the improvements in maintainability. Code quality does have its costs at times - otherwise we'd all be writing assembly. It's not going to be the straw that breaks the camel's back when it comes to performance.

Re:Get rid of boolean function parameters by ignoramous on Wednesday June 17, 2015 @11:06PM (#9736631)
http://yosefk.com/blog/redundancy-vs-dependencies-which-is-w...

In an enterprise product, sure, I'd include a logging framework, but for smaller projects, more often than not, it may bring in unnecessary complexity.