```/** * Function which create debug log * * @...
# suitescript
c
Copy code
/**
 *  Function which create debug log
 *
 * @param {String} stLogTittle - logger title
 * @param {String} stLogMessage - message
 */
function debugLogMaker(stLogTittle, stLogMessage) {
    if (BL_DEB_LOG_IS_ENABLED) {
        log.debug(stLogTittle, stLogMessage);
    }
}
Any idea why you'd create this function?
n
This is to control the debug loggin. If BL_DEB_LOG_IS_ENABLED is set to FALSE, this will not be logged.
c
What what is clear, I'm wondering about the why?
n
To easily turn on/off the debug logging.
c
But you can do that on the deployment record
💯 1
or you could hold the true/false in a script param. It's hardcoded into the actual script
FYI: it's NetSuite ACS that wrote this....
😆 1
And that variable name?
I can't see a single reason for this to exist.
n
That's true but I have seen similar implementations done for logging. That's why I know.
I personally just remove all the debug logs or change the log level to error.
I don't a single reason for ACS to exist either 😄
c
The script also executes for every action e.g. CREATE, EDIT, XEDIT etc.
I would have bounced this in code review 😄
ACS are great, if they introduce bugs, they then burn your hours to fix those bugs.
😆 1
Or if they produce a design document that makes no sense, they'll burn your hours to rewrite the doc.
n
I didn't know that about ACS, thanks for the insight.
They burn your hours for their mistake, That's a good business model.
c
Exactly that.
e
The check for Log levels on the Deployment record is done on the server side, thus every unguarded
log
method call is still submitted to the server, even if it is a lower level than what the Deployment states, so you still take a performance hit for that log call. An implementation like this prevents that.
☝️ 1
👍 1
n
Thanks @erictgrubaugh
c
So ACS did this for performance reasons. I am very impressed.
I wonder what the total performance gain is across the whole NS account if this was applied to every script.
s
Wow, I did not know that. My scripts are full of debug level logs I never bothered to remove.
e
It is such that part of our code review standards are that all
debug()
logs must either be removed or upgraded to a higher level before it can be merged
n
I did an analysis once where I ran the scheduled script 3 times; 1st with debug logs, 2nd time with log level set to Error, 3rd time without any logs. The script ran fastest without any logs. With logs and log level set to Error didn't have any significant difference.
👍 1
r
@erictgrubaugh If you remove all the debug logs, won't it make it hard to troubleshoot production issues?
n
You can add the logs back if there is a production issue. @rustyshackles I follow the same approach and remove all the logs.
c
Yes, it does make it harder.
Adding logs and trying to recreate the error may or may not be easy/doable etc.
e
Yes, it absolutely makes it harder, but we have some very time-sensitive operations that don't leave us any other choice.
I would much prefer to leave them in.
c
As always, a tradeoff