VS Code is not fit for professional software development. JetBrains products are far and away superior. Sublime Text is nice as a notepad, extended clipboard, and quick file editor.
I would estimate print debugging is usually twice the work for 30% of the effectiveness of step debugging. It's the screwdriver to step debugging's drill. Fundamental and absolutely necessary sometimes but not the first tool you should be reaching for unless there's a specific reason.
The specific reason I reach for print debugging first is it works literally everywhere across all technology stacks. I regularly work with different projects written in different languages. Printing works across all of them and the logs are easy to aggregate across different parts of the stack (microservices or other service composition patterns) giving you a broader range of data than you typically get from a step debugger. I've personally found that step debuggers are more likely to create Heisenbugs. Especially in multi-threaded applications or dealing with race conditions.
Step debuggers don't "create Heisenbugs", you're just much more likely to notice race conditions while step debugging than print debugging. If anything, print debugging creates more bugs because you're altering the code you're trying to test by definition.
Step debuggers can 100% cause or hide race conditions that are exposed via other mechanisms. Especially in multi-threaded apps as I stated. If you've never encountered it, I'd suggest you've never debugged really nasty race conditions or serious bugs.
VS Code is not fit for professional software development. JetBrains products are far and away superior. Sublime Text is nice as a notepad, extended clipboard, and quick file editor.
I have been through this myself - and after trying out a lot of stuff, I finally settled for Ecode. Very lightweight and extremely fast.
Not perfect but not laggy and memory hungry like a lot of editors these days.
NOTE: I am not associated with this project or its founders in anyway.
https://github.com/SpartanJ/ecode
I've never stopped using Sublime Text. There's no reason. It does everything and also nothing (in all the right ways). Welcome back
Last time I used Sublime text with package control, the plugins created always after updates a new tab with changelog and some with textads.
Pure sublime text is better, but still just a better notepad and no ide.
Check out sublime merge, too. All the goodies from sublime text for a git frontend!
It's still all I use. You know it's good because you can use it to crack itself
So what do you use for debugging?
Printf works just fine in a lot of languages and domains. Not everyone likes to use a step debugger.
I would estimate print debugging is usually twice the work for 30% of the effectiveness of step debugging. It's the screwdriver to step debugging's drill. Fundamental and absolutely necessary sometimes but not the first tool you should be reaching for unless there's a specific reason.
It feels like the option for people who are too lazy to learn their tools to me.
The specific reason I reach for print debugging first is it works literally everywhere across all technology stacks. I regularly work with different projects written in different languages. Printing works across all of them and the logs are easy to aggregate across different parts of the stack (microservices or other service composition patterns) giving you a broader range of data than you typically get from a step debugger. I've personally found that step debuggers are more likely to create Heisenbugs. Especially in multi-threaded applications or dealing with race conditions.
Step debuggers don't "create Heisenbugs", you're just much more likely to notice race conditions while step debugging than print debugging. If anything, print debugging creates more bugs because you're altering the code you're trying to test by definition.
Step debuggers can 100% cause or hide race conditions that are exposed via other mechanisms. Especially in multi-threaded apps as I stated. If you've never encountered it, I'd suggest you've never debugged really nasty race conditions or serious bugs.