I'm gonna go a bit against the grain here and say that I agree. I too think console.log is wrong. In my opinion, console.* methods should never be in a commit (except when commiting a logger class).
Not wrong to use it while debugging local, but logging isn't very useful when you have to scroll through pages filled with various other developers' logs. One have to remember to remove those debugging lines before commiting. If you use chrome debugger instead, you don't need to remember.
If you need console.* for debugging in a production environment, it should be wrapped in a logger class that can easily be toggled on/off for that environment. Even better if it can toggle where the log entries should be sent (a file, a network request, etc) and toggle severity level.
In C# i usually used log4net for that kind of stuff. As a devops I got a bit annoyed when my co-workers built their own logger classes (in a project that had log4net already) just to output to their own logfile. I found multiple log files taking up more and more space on a production server. They each created their own logger classes. And they copied that code into a shared dll too, making it even harder to get rid of.
But, like everything, it always depend on the scope and requirement of the project, of course.
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.
I'm gonna go a bit against the grain here and say that I agree. I too think
console.logis wrong. In my opinion,console.*methods should never be in a commit (except when commiting a logger class).Not wrong to use it while debugging local, but logging isn't very useful when you have to scroll through pages filled with various other developers' logs. One have to remember to remove those debugging lines before commiting. If you use chrome debugger instead, you don't need to remember.
If you need
console.*for debugging in a production environment, it should be wrapped in a logger class that can easily be toggled on/off for that environment. Even better if it can toggle where the log entries should be sent (a file, a network request, etc) and toggle severity level.In C# i usually used log4net for that kind of stuff. As a devops I got a bit annoyed when my co-workers built their own logger classes (in a project that had log4net already) just to output to their own logfile. I found multiple log files taking up more and more space on a production server. They each created their own logger classes. And they copied that code into a shared dll too, making it even harder to get rid of.
But, like everything, it always depend on the scope and requirement of the project, of course.