In a previous post, VS Code: You don't need that extension part 2, I discussed how you may not need an extension for (prettily) formatting your cod...
For further actions, you may consider blocking this person and/or reporting abuse
OR....just hear me out...
You could hit "tab" when typing and also the "," and "enter"....and get pretty much the same results. With some practice you'll get it all right automatically and you'll also understand your code better because it wasn't a tool that organized it for you. The experience of formatting it yourself helps your brain remember it better, just like taking notes in class helps you learn the material better. There's little to no effort to doing this as you go and it can be very beneficial to your skills as a developer in the long run.
Something to think about before you install that next helpful tool.
I tend to disagree that there is little to no effort in manually formatting your code. In my own experience, formatting code takes up precious cognitive load that I'd rather spend working through my code logic.
For example, I know I want to:
All of the above are just personal preferences, but I don't want to have to think about any of this. Instead, I want to focus on converting business logic into coding syntax, and having to pause every few moments to throw in an arbitrary semicolon or fix the indentation of an entire block just takes me out of "the flow".
I'd suggest taking the extension settings a step further—configuring Prettier not only to auto-format your code on save, but to also display formatting suggestions inline using yellow wiggly underlines. That way you have the benefit of learning why a formatting rule is getting applied, as well as the auto-format on save. You get the learning plus the time savings.
You mention in a later comment that:
Again, I'd argue that extensions like Bracket Colorizer (which is now a built in function of VS Code) helps immensely with block scope visibility.
Lastly, your comment regarding "complex tasks" in relation to web dev is quite dismissive:
Complex tasks come in all shapes and sizes. They can be laborious and intensive, such as refactoring a legacy component for use in a newer framework. They can be more investigative, such as debugging a complex pipeline build issue with Webpack. Or they might have nothing to do with the code at all, such as having to sporadically context switch between development tasks, support tasks, meetings and the other umpteen distractions flowing through the door. All of these things have something in common—they take up precious cognitive load and focus. Adding manual code formatting on top of that seems like an extra burden to me.
Work smarter, not harder. 🤓
Great response.
I still avoid Prettier like hell, because working for an agency i have to work with client code across various platforms, codebases, often in different languages, etc etc. Worse, some clients enforce their own rules like "standards js" or some other configurationg for formatting that i have to follow.
Getting yelled at by "avoiding insulting people here" because my formatting didn't match their is low on my list of things i like, so i look at the code i'm editing and make my changes match as best i can.
Funny thing, in some cases i make my formatting absolutely different on purpose because I want to come back later and go "This is my code, that is not my code" especially in really old applications that i have to still support, or when clients get to be a pain and nitpick every bug as "you made a change last week, this is your fault". Anywho, that's a different discussion altogether.
You're right, i was being dismissive with the "web dev is easy" bit.
Frankly, I'd say 99% of what we do is easy, once you've gotten good at it, or maybe it's "once you've seen enough bugs to recognize them before you know the details"
There are times when bugs stump people and can take days to resolve, but those are few and far between.
The industry is largely people with less than 10, or less than 5 years exp and a lot of things seem hard during those years, but with enough experience i think most of it is pretty damn easy.
eg. Centering a div is a nightmare for newbies, but a year or two in, you copy paste a solution you've used fifty times before and don't even think about it.
In JS you can say arrays and loops are hard when you start, but a few years in and you don't even think twice when using the various looping methods and you've realized everything is an object.
In PHP handling session variables, setting cookies, writing crons all seem complex, until you've done em a few dozen times.
As for VSCode extensions, i'd recommend checking out "indent-rainbow" , "power mode" for fun, and "indented block hightlighting". And yea the bracket colorizing they added is nice and useful.
I try to work smarter not harder :)
Whenever I get to code from scratch i write it as simple as possible with the goal being "Me or anyone else has to understand this 6 months or a year from now".
I avoid tools because the way i code hardly requires them. My frontend code requires no build tools, to deploy i use github actions, to debug i run the web pages, use browser dev tools, check the network tab and look at the console log. For backend i've got my server error logs configured and usually SSH in and go
"tail -20 /var/log/apache2/error.log" and fix whatever pops up in there.
I really think web dev has been made overly complex by implementing more and more "programming" things that work well for desktop applications and computer programs, but have only added weight and bloat to the web. Things it's never really needed. But again, that's a discussion for another time.
Have a good day :)
Usually .prettierrc and/or .eslintrc files take care of that.
I always say: i dont care whats the code style, as long as its standarized and everyone has a software that does it for us (ie. no manual labor and thinking involved)
Umm, no. That's like saying there is a benefit for not using snippets for the things you already know pretty well. Sure, a junior student shouldn't use snippets in Visual Studio for
forloops but learn how to write them, but if you're seasoned developer you get absolutely nothing by doing such trivial tasks by hand. On the contrary, you lose the time you could have spent solving the problem.My thoughts exactly. I've been writing code for too damn long to be manually formatting it these days. I can only imagine the amount of total hours wasted when I used to have to do this in the past.
I see it akin to not using a linter. Sure, I can do it without one, but having it allows me to free up my mental state for more complex tasks.
Using less plugins & dependencies is a laudable goal, but as some people pointed out, I don't want to become overly dependent on VSCode for formatting.
Formatting should work just as well in other editors or as a CLI tool/library, for example in commit hooks. You could argue that the CSS mentioned solution here is also externally available, but I don't think the same counts for the built-in JS/TS formatter.
Another (small) problem with using the built-in formatter is that the formatting rules depend on your VSCode version. They may be somewhat configurable, but most rules are decided by VSCode and might change in future versions. If you reopen a 2-year-old file in the latest VSCode, can you guarantee will it be formatted in the same way?
What would solve this:
editorconfig helps with broad configuration in an editor-agnostic way. The Deno platform also took a good step with their code formatter, which is both available in their VSCode extension and as the
deno fmtCLI tool.But for node.js/frontend projects, I think I'm stuck with Prettier or
RomeBiome for the moment.For us, its a pre-commit hook to format with pretty-quick on all staged files. Use whatever IDE you want (although I recommend VScode for the team), but our code will be formatted the same regardless.
And that works well too. If you work on a team and on a product/platform, one code base, autoformatting helps everyone stay consistent. I won't disagree there.
Once you start splitting projects and switching between teams and other products you'll quickly find the code doesn't keep the same formatting, even if you enforce the hell out of it, in the long term it won't stay that way, someone will mess it up along the way and you'll spend more time arguing about how to fix the formatting than it's even worth doing. Seeing this with a current client whose dev team spends more time doing code reviews than actually building anything.
We've been using nx.dev/ for our mono repo for all of our front-end work.
You deserve a coffee.
Thanks Carlota :-)
This is okay if the whole team uses VS Code, but I'm much more comfortable in having a IDE agnostic specification regarding formatting (like
.editorconfig).Ya when it comes to a team project, there are these considerations. In another post in this series, I spoke about project-specific settings.
Customise VS Code for a project, or per language
Rob OLeary ・ Sep 17 '20 ・ 3 min read
I agree it is not cool to force someone to use a particular IDE in a team. Git commit hooks are used to remedy this also. It depends on the project. It is good to have simple and clear standards.
Code formatting is, obviously, strongly opinionated. If you are only working on your code and that is all that ever will be - go for whatever you want.
The more people who interact with your code - the more reason to use a very standarized code-formatter. Prettier seems to be the most used, at least in a lot of languages. You have newer languages like GoLang who put immediate thought into providing a formatter.
The reason to use a standard formatter is that it helps others in reading code. While people might disagree on how much to indent, where to break lines, etc... the fact is that a general format allows us all to recogize what we are looking at better.
Just like your post here. You used paragraphs, bulleted lists, headers, etc... You could have formatted things in your own special way I suppose. Instead you followed the conventions set by the other thousands of posts to Dev.to. A tool like Prettier just makes it easier for us all to follow the conventions that thousands of others are using as well.
This kind of "light touch" formatting is more akin to autocorrecting typo's with more granular control, and it's a welcome addition 👍
Impossible to use prettier, it does weird shit to arrays and style selectors.
Earlier this year vscode added multi-lang definitions, you can significantly shorten the config required in settings.json, instead of the above do the following:
"[javascript][javascriptreact][typescript]": {
"editor.defaultFormatter": "vscode.typescript-language-features"
},
"[json][jsonc]": {
"editor.defaultFormatter": "vscode.json-language-features"
},
"[css][scss][less]": {
"editor.defaultFormatter": "vscode.css-language-features"
},
Thanks for sharing the multi-lang syntax! I had wondered why it wasn't supported in the past! 🤔
Question: "vscode.typescript-language-features" formatter *.js files?
I tested as below settings.
"[javascript]": {
"editor.defaultFormatter": "esbenp.prettier-vscode", // worked!
//"editor.defaultFormatter": "vscode.typescript-language-features" //Not worked?
},
"vscode.typescript-language-features" does not work for javascript file!?
Thanks in advance!
Yes, that builtin extension formats JavaScript and TypeScript code.
If you want to configure the default formatter for a JavaScript file that is open, right-click inside and select the option "Format document with.." from the context menu.
That will show a quickpick in the command palette with the available formatters, you can select the option "Configure default formatter.." to set the default formatter. The second option for me is: "TypeScript and JavaScript Features". Selecting it will add this snippet to your Settings.json:
Running the command "Format document" from the command palette should format your code then.
If it does not work for you, something else is probably up! Prob best to post your issue on Stackoverflow in that case.
Prettier integrated into ESLint and automatically executed on File Save and Git Commit 🚀
I use shift+alt+f and it does it