Hey hey @joegaudet
. Yeah, definitely the solution wouldn't work for that since the regex matches starting from console.log till the end of line. I suppose the regex could be tweaked to account for the pattern of the closing parenthesis and semicolon or what not. I'm not savvy with regex, but came to this solution that seems to work for me.
Do you mind elaborating on the "better solution"? I'm unfamiliar with what logger and levels is and so doesn't really help me. It seems you're familiar with other tools to get the job done better, mind writing a post and linking it here?
Happy to provide further context, my apologies for being terse I was on my phone :)
As for regex, you could do something like this:
/console.log([^;]+;/
The character class:
[^;]
Will match against any character except a semi colon. The + indicates that it will match at least one non semi colon character. This of course assumes you are terminating all of your console logs with semi colons.
As for using loggers, there are two issues with leaving log statements around in production.
a) They can cause performance issues - you can pretty easily profile this in chrome or V8 a program that is aggressively logging will execute slower than the same program that is not. This is because logging is not a free operation.
b) Much of what you are logging will be noise in a production environment, and potential leak internal code details that aught to be secure
Usually people solve this problem by wrapping the language logging mechanisms in a logger.
If you're just leaving log statements around to print variable values, I'd suggest understanding break points and the debugger, as they will allow you to inspect the whole stack and not just some variables.
If the log statements you are making could be useful at a later date, but should not be present in production, a logger is probably what you need.
Hey hey Joe! Thanks for coming back and elaborating your response. This is really good stuff. I especially appreciate the two issues regarding leaving logs in production.
I've never come across a logger but can see it's usefulness. Thanks so much for sharing this, definitely something I can implement into projects developed with other devs.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Hey hey @joegaudet . Yeah, definitely the solution wouldn't work for that since the regex matches starting from
console.log
till the end of line. I suppose the regex could be tweaked to account for the pattern of the closing parenthesis and semicolon or what not. I'm not savvy with regex, but came to this solution that seems to work for me.Do you mind elaborating on the "better solution"? I'm unfamiliar with what logger and levels is and so doesn't really help me. It seems you're familiar with other tools to get the job done better, mind writing a post and linking it here?
Thanks again Joe for your feedback :)
Follow on with a JavaScript logging library:
github.com/winstonjs/winston
Hey Mike,
Happy to provide further context, my apologies for being terse I was on my phone :)
As for regex, you could do something like this:
The character class:
Will match against any character except a semi colon. The + indicates that it will match at least one non semi colon character. This of course assumes you are terminating all of your console logs with semi colons.
As for using loggers, there are two issues with leaving log statements around in production.
a) They can cause performance issues - you can pretty easily profile this in chrome or V8 a program that is aggressively logging will execute slower than the same program that is not. This is because logging is not a free operation.
b) Much of what you are logging will be noise in a production environment, and potential leak internal code details that aught to be secure
Usually people solve this problem by wrapping the language logging mechanisms in a logger.
A trivial example:
If you're just leaving log statements around to print variable values, I'd suggest understanding break points and the debugger, as they will allow you to inspect the whole stack and not just some variables.
If the log statements you are making could be useful at a later date, but should not be present in production, a logger is probably what you need.
In Java land: slf4j.org/
(edited for regex cleanliness)
Hey hey Joe! Thanks for coming back and elaborating your response. This is really good stuff. I especially appreciate the two issues regarding leaving logs in production.
I've never come across a logger but can see it's usefulness. Thanks so much for sharing this, definitely something I can implement into projects developed with other devs.