Coding Practice - log.*

What is the general consensus/best practice regarding the usage of the log command? When and for what do you suggest to use the different log types to improve code readability and execution overview? Looking through the different Smartthings developed and shared SmartApps and SmartDevices I see very different practices.

log.debug
log.info
log.error
log.trace
log.warn

Are there more versions?

Regards,
Rikard

1 Like

Good question.

It is typical for companies to have a wide variety of coding styles internally, regardless of company size. Combine that with the variety of experience levels of the Community developers, minimal published API documentation … there’s no published coding standards and guidelines yet.

There are some really experienced coders here and there examples are a good bet … but there are plenty of functional hackers too, and their priority is to “make it work”, and that’s fine too.

Perhaps published good standards will arise out of the SmartApp and Device Handler submission approval process. The documentation writer and various experienced coders can certainly come up with "musts’ and “shoulds” for your question and similar. Right @Ben?

But nothing exists at this time – at least that I can find using the “search” function.

Where we work, the use is typically as below.

trace - function tracing, entering, exiting functions, etc, e.g. entering foo(), exiting foo(). Can be used to trace the functional execution of the program. Often turned off in final production.

debug - used more during debugging, should be turned off for final production, can help to solve problems if turned on. Lots of examples of that in the code.

info - general logging to get an idea of what the software is doing.

warn - error conditions which are recoverable, may lead to loss of function but not failure of software.

error - error conditions which are not recoverable. result is program function failure. E.g. required device is not set in smartapp.

2 Likes

Is there a way to set your logging level in the app so for example if you set it to “info”, you’d only see info/warn/error or would you need to write a wrapper function for the log statements?

1 Like

I use wrapper functions and just comment out the log.* as desired. The advantage is that I can prefix log entries with app and instance name, maybe even app version

Ideally, the live logging viewer would also have log type filtering on the fly.

See def myDebug() etc in this SmartApp.