And then, there’s also the thing we already talked about earlier – the file won’t always be syntactically valid after an auto-save, and the auto-formatter will fail. However, this feature isn’t very compatible with auto-save, and that’s why editors/IDEs like WebStorm and VSCode do not format your code for you on auto-save (you can still press Ctrl (Cmd) + S for it to happen, but isn’t one of the reasons for enabling auto-save to avoid this over-used keyboard shortcut?).įor one, it would probably be annoying for the cursor to change position due to auto-formatting as you’re typing. This seems like a great point for formatting, so it’s a great idea to combine it with the saving action so there’s no need to think about it.
#Auto format visual studio code on save manual#
For manual saving, this makes sense, as usually you Ctrl/Cmd + S after making a small working change to a file and stop typing. These editors typically provide an option to format the file when it is saved. For example, VSCode has built-in auto-formatting functionality, and also allows extensions to be written to provide more advanced or opinionated auto-formatters for various languages and file extensions. Many IDEs and text editors have a feature that automatically formats your code, so you can focus on the task at hand. So if you want to continue enjoying the benefits of auto-save while minimizing the possibility of this issue occurring, it’s best if you always use source control and have a frequent commit schedule. Still, the previous working version of the file you would want to recover could be one with uncommitted changes, not available from version control, especially if you don’t commit very frequently or you have a commit scheduling determined by more than just the code working after small changes, e.g., committing when a mini milestone is reached, committing after every successful build, etc. Of course, using version control tools like Git and Mercurial significantly decrease the chances of this happening. You might even forget how the code used to look before the change, and then have to expend some mental effort to take the code back to what it was. What if you make an unintended and possibly buggy change, maybe from temporarily trying something out, and then close the file accidentally or unknowingly (autosave makes this more likely to happen)? With your Undo history wiped out, it will be harder to recover the previous working version of the file. This makes it harder to recover from unwanted changes. With autosave enabled, any single change you make to your code file is written to disk, whether these changes leave your file in a valid state or not. But depending on your particular situation, you might want to conserve these things as much as possible. Admittedly, this will continue to become less and less of an issue as computers increase in processing power, memory capacity, and battery life across the board. With greater CPU and memory usage comes lower battery usage and more heat from higher CPU temperature. Run PHPUnit Tests Whenever Your Files Change
0 kommentar(er)
