Whatever stops my linter complaining. Seriously though, it's arbitrary, especially when a lot of code might be processed compiled or minified. If your project has a particular standard, I'd use that, it's good to adapt and be able to stick to new rules, it increases your familiarity with other styles, and over time, who knows, you might discover the perfect syntax. A buddha of code. If it's my own project, it's a case of what seems logical- obviously stick to the same rule all the time, but does the rule make sense given how you're styling the rest of your code. Is it, as a whole, pleasing to read and easy to visually pick apart?

I'd say the biggest issue I run into tracking down bugs is that I focus on the specific areas where I've made changes recently. Almost always, the problem involves taking several steps back- thinking about what dependencies are involved, whether I've changed git branches recently, checking a wider range of error logs and even whether any system services are halted. See if another machine or context produces the same error. Frankly, I can never get there in one session, or if I do I only end up feeling exhausted. Taking a break, a long lunch, doing something novel generally helps. Of course that's not always an option, but changing to a different part of the project, or a different project for a while can give you that cognitive 'reset'. To this day I've never found a bug which wasn't easily soluble once it left alone for a week. The other side of this is how do you actually break apart your code. You know its broken, but the bug seems to squirm as you segment off areas of code, move to different lines (if it's moving to preceding lines it's almost always a syntax error), and generally show resistance. The old school approach would be to make an isolated test case of just a few lines at a time, adding in more until you see the issue; or break up your code into modules and test each one. If you're going down this road, make sure you actually log the inputs and outputs of data through a function or module- often the data type or structure is doing something you didn't expect or had forgotten about. Given that sometimes your code can end up like a woven rug (hard to pull apart), I sometimes just rewrite a section of code entirely instead of trying to trace a problem through it. Generally speaking, if you wrote it once you can write it again much faster, and even if your new code isn't great, you can learn from comparing your two attempts and HOW they fail. Hopefully they don't fail.