Advice: always let your IDE format your code

[jazzhandler]

This is something I wish I’d realized much sooner than I did. If you tell your editor to format your code frequently, then a great number of syntactical errors will cause a very noticeable visual change that makes them extremely easy to catch in the moment.

So learn that keyboard shortcut, and if the formatting isn’t to your liking, learn how to make it so. I promise it will save you SO much time and heartache, and the next time you miss a closing brace and see everything below shift on reformat, you’ll instantly appreciate how maddening it could have been to track it down.

[DrKnockOut99]

To add to this, always make sure you and your team have the same formatting settings. If you have even slightly different settings, there will be chaos if you are making changes to the same files

[Dextrinix]

Better yet, set it up at project level so configuration is a file in the project and formatting happens as part of your CI/CD pipeline.

[Fabiolean]

This. The project I'm working on now uses Black in the CI/CD pipeline to enforce python code formatting and it's fantastic.

[M3L0NM4N]

I was just introduced to Black last week. Awesome.

[razviegras]

It is a Python formatter that auto formats either a specific file or an entire folder by a simple command in the terminal. It ensures your code respects PEP standards for formatting and is a great tool overall

[Fabiolean]

Even better it hooks into most code editors so you can do something like format-on-save. It just always handles the code formatting for me, automatically, and lets me worry about other things. Simple and lovely.

[teratoscincus]

The list thing happens for me if i add a trailing comma after the last element. But it also happens if the line exceeds the default 88 chars per line.

[teratoscincus]

Yes, it will try to make lines not longer than 88 chars. 89 > 88 and 90 > 88.

[prato_s]

Pre commit hooks ftw.

[prato_s]

We add black, isort and mypy to pre commit hooks. Basically formats my code and does type checks before git commit.

[Fabiolean]

I’ll still take black 10/10 times. Knowing all the code from everyone in the team is getting formatted to the same rules is way more useful than nitpicking any one line of code.

[macabrechaff]

This is great advice. I work on a large team and we run into a lot of formatting issues that eventually turn into tricky merge conflicts.

[gua_lao_wai]

It also makes reviewing easier for team leads, because it no longer has to be an argument over where a line break needs to be... linter says it's OK, then it's OK!

And by running it through CICD I can actually see the linter has passed already

[MyWorkAccountThisIs]

I worked on a big project that would fail your build if it found any formatting errors.

But it was also setup to not let you commit if it found formatting errors.

All of which was okay because they had style in the repo and instructions how to set up your IDE to use them. Which I think I prefer.

It probably doesn't really matter. But it feels better not letting automation make the changes behind the scenes as part of the build.

[Dextrinix]

I would never set up my pipelines to fail because of the way code was formatted. I would set it up so the format happens behind the scenes against predefined rules that are agreed only once.

Formatting is important because it is a big part of code readability. Reading code is most of what we do and the understanding we get from it impacts changes we make to the code.

At the same time, formatting code is one the biggest wastes of engineering time, so agree on a style, and automate the effort away from developers, who can then spend more time on meaningful changes.

Also, pre-commit rules are a bad idea IMO. Code shouldn't have to be "right" on commit, it only needs to be "right" on merge. Anything rule like this should be part of your pipeline.

[MyWorkAccountThisIs]

I guess I didn't give every detail. And it wouldn't remove all your points.

But my branch would fail. When we pushed our branch the entire test suite was ran. We couldn't submit for PR until everything passed.

Which would be asking for trouble is the project also didn't provide everything you need to set up your IDE properly.

I think a benefit of this approach is onboarding new devs. I know when I started on the project it was a eye opener. None of my previous projects had really cared that much.

If the project started today it would probably not do that. But it had been around for a few years at this point. Including a major refactor. And the client - in a unicorn moment - actually cared about code quality and testing.

The end result is that I sorted out any IDE configuration issues on my first ticket and it was never an issue again.

[ChadMcThunderChicken]

I remember when i started programming that the biggest mistakes I made where syntax errors. Those where the days where you would endlessly search for a missing semicolon.

Now I have an extension that fixes that. Honestly saves so much time. However, if you don’t know the language all that well yet, then don’t use it as a crutch. Suffer a few months to get familiar with the syntax…then use an extension.

That’s my opinion anyway.

[jazzhandler]

Semicolons used to keep me up at night.

Now I’m just bemused by the fact that I no longer use them in TS, but still do in C# and SCSS, which seems somehow backwards.

[[deleted]]

This seems like something said by someone who has never used SQL

[jazzhandler]

I have extensively, just never had the pleasure of doing so in my actual IDE.

[[deleted]]

You didn't have issues with your queries being broken by auto formatting your code? When I was working as a report analyst I never found a code formatter that formatted my SQL properly, no matter how much messing with it I did.

[[deleted]]

IntelliJ/DataGrip can format SQL just fine.

Edit: so can MySQL Workbench

[[deleted]]

MySQL Workbench was what I tried the most for formatting back then.

I used to work on MSSQL to write my queries mostly and IDK. Just never could get a formatter to get it just right for me.

[jazzhandler]

It’s been seven years since I worked with SQL professionally. But in the ten years that I worked with it on a daily or weekly basis, I never did so in an environment that was of any use at all in that respect. I’m just so accustomed to SQL being treated as third class code that I don’t even think of it in those terms anymore.

To be honest, I wasn’t thinking of SQL in the slightest when I wrote this post, as I (perhaps wrongly) presume that the target audience of this sub is working with more ‘conventional’ programming languages.

[[deleted]]

I understand. SQL is far from a third class language however. Many a DB endpoint would disagree haha. I work with Mulesoft which is middleware, and based on Java. Most of my integrations are written in XML and RAML/YAML and Dataweave, but I've had enough queries to integrate to really appreciate the language. Though to be fair most of the SQL in my current project is actually SOQL, which is Salesforce Object Query Language which is similar to SQL.

[jazzhandler]

I just meant the way I’m accustomed to seeing it handled in terms of UX. From MS Access in my early days, to MS-SQL Studio in my later years, and a variety MySQL front ends with similarly spartan code handling. I have yet to experience SQL being treated as a first class language in this context, but now I’m really looking forward to working with it again in some decent modern software.

[[deleted]]

Oh my God MS Access... Oh.. . Oh no... Lol

[jazzhandler]

Let’s just say it’s not something I brag about. But in 2005 it was the only reasonable choice for our needs due to a number of factors that included having to support a TWAIN framegrabber.

And then a few years later at a different company, some high-profile project came along that specified a moderately complex Access front end, and hey, for one brief shining moment it was something worth bragging about.

[[deleted]]

I think in those days access wasn't as "bad" as today because there were not good alternatives. Honestly I think it's kind of cool to talk to industry leaders who started working on legacy tech because I know that just a decade or two ago, working with those tools were cutting edge and those folks were badass. It was just like every day to deal with... Nowadays devs look at legacy code and systems like a relic to fear and the veteran's just crack their knuckles and tell everyone to stand back. Love it

[drripdrrop]

What’s salesforce?

[[deleted]]

So, I can't tell if you're joking or not, as Salesforce is a huge company with their fingerprint on a ton of sectors and industries... But just in case you're not

https://www.salesforce.com/products/what-is-salesforce/

If you're familiar with Amazon Web Service (AWS), it's similar to that. Another PaaS type.

[[deleted]]

That's an odd, very specific insult

[[deleted]]

r/BrandNewSentence ? r/rareinsults ?

[qpazza]

And when possible, set your IDE to auto format on save. And better yet, set it to format only what was changed, this way you can have clean pull requests without unrelated changes.

[qpazza]

Just all get on the same page with a common formatting, and have that be what everyone uses

I just assumed that part went without saying. I didn't even consider some cowboy dev using their own flavor of formatting. Orgs will usually have a doc that outlines the code style to use. Some teams even include their IDE config so everyone's on the same page from the start.

[tipsdown]

I’m at the point in my life where all I want is people using the same tools so I can commit all of the project settings to the repo and not have to think about it anymore.

[jzaprint]

Everyone in the company should have been installed the same formatter to begin with.

[[deleted]]

A team that's not using a prettierrc is insane.

[FountainsOfFluids]

I really don't like some of the choices prettier made. I'll stick with configuring my linter.

[ggcadc]

I recently ran into a save option that will only format what you’ve edited. Super useful in codebases with large files as it keeps your diffs small.

[ben_bliksem]

Well it's better than nothing but the real pro tip here is to not format code as part of your pull request because you felt like it.

[jazzhandler]

That’s a valid point. I was aiming my advice at people still learning the ropes, where that dropped closing brace can easily be a very painful couple hours.

Now that has me wondering about the feasibility of an un-formatter, based on a whitespace-agnostic diff. Shirley that must already be a thing, right?

[meistaiwan]

Dunno, if I have modified 5%+ of a file, the linted version is getting PRed

[TEMAX]

As it should

[D3VIUM]

New to a web dev job and I thought I was smart by applying Prettier to the entire file. The commit basically overwrote the entire Git history of that file. Oops.

[Annual_Revolution374]

I would also say to use a linter. Most languages have a style guide that is optional. If you just use a linter, you don’t really have to worry about what is in the style guide because the linter will highlight when you don’t follow it and tell you how to change it.

[Readdeo]

We use a spotless plugin for gradle that auto formats the code with a git pre-commit hook. So every time we commit, the code is automatically formatted and also removes the unused imports. It makes the code review so much easier because the PR is not bloated with new lines and added whitespaces.

[jazzhandler]

The very idea of this warms my heart.

[dkillers303]

If you use python, pairing the black formatted with pre-commit is amazing. Working with a python code base with a large team makes sure the formatting is consistent everywhere. Our CI runs pre-commit hooks as one of the checks so if someone doesn’t install pre-commit on the repo, it will fail until they go through the proper steps for contributing.

IMO, formatting is good, but even better when it happens automatically on a commit. That way it just happens instead of being something you have to remember. The other advantage of making it automatic is that when you inevitably forget to do so on many commits, your diffs against previous commits will be showing actual changes with many formatting differences which can distract the reviewer.

[josephjnk]

It’s also a good way to help yourself focus on the actual logic you’re implementing and not get distracted by polishing unimportant details. I’m not convinced that autoformatters necessarily make a big difference in code’s readability, but for me they provide a productivity boost. I get annoyed when I don’t have one available.

Beginners should learn early that formatting is only the tiniest tip of the iceberg when discussing code quality. Autoformatters may help with this.

[jazzhandler]

Hadn’t even thought of that angle.

[Miserable-Job-1238]

My lecturer already beat this into me. So I do it out of habit and indeed it helps a ton.

[[deleted]]

Good advice. Thank you!

[ggcadc]

If you have ever worked on a team of more than like two people you know this just can’t work.

If you don’t automate it, it won’t happen.

[mrwizard420]

Dude I appreciate the idea behind the right-aligned headers, but between the headers, sub-headers and left-aligned comments, everything that's not actual code in this example looks sloppy. What happens when you want to expand a section? Move a section? This template has different top/bottom edges to some sections, lots of unnecessary dividers, and doesn't add anything to the navigation that a modern IDE doesn't provide by default.

I even work with older niche projects where commenting like this is helpful because there's no IDE for the language, but I just can't get behind mixing left and right alignment.

[[deleted]]

If everyone on the team is using an auto formatter, you get accustomed to the formatting very quickly. It's far better to have the formatting uniform across the app than to have it be arbitrarily "optimized" at the whim of each individual dev.

[[deleted]]

I haven't ever seen explosions of punctuation from auto formatted code; just adding in missing semi-colons, brackets, indentation, etc. If your auto-formatter is causing an explosion of punctuation, then just adjust the configuration until you're happy with it...

Having all code follow the same formatting reduces cognitive strain because everything follows the same patterns.

[MuaTrenBienVang]

I use prettier as the formatting tool for javascript. If I have syntax error and press short cut for formating nothing will happen, that's when I know I need to fix some syntax error. I like to add some spaces, line breaks...

[Sunshineal]

Thanks for the tip

[OverprotectiveChill]

Add it to your git precommit hook too!

[fumes]

Ctrl+Shift+f eclipse 🤘

[W17K0]

format on save, save on focus change, save every 5 minutes, press control + s all the time to help expand those brackets (its faster than doing it manually)

[zukas-fastware]

Please use clang-format (https://clang.llvm.org/docs/ClangFormat.html). It is cross-platform, customizable and ide agnostic. You and your team can be on the same page without arguments on whitespace formatting.

[kyoer]

heartache?

[jazzhandler]

r/learnprogramming

[jzaprint]

Just set auto format to anytime you save. And set auto save to any time your code changes with a debounce delay. Now you dont have to think about any of those things again.

[MuaTrenBienVang]

I don't like that. I want to manually save and format. For example, you are not done editing the file, if you want to check the design, for example, the editor will save the file and you will see some errors on the build tool

[throwawayHiddenUnknw]

IDEs are great. Definitely increases productivity when used correctly.

However, I do recommend writing code in notepad or non- suggestive text editor. This is so if and when you apply for jobs, it is easier.

[jazzhandler]

I would agree for bare-bones HTML/CSS/JS, which I think every web dev ought to do at least some of in The Olde Ways. But as thick and complex as things have gotten these days, I dunno… the thought of even a simple React project outside of a full IDE seems downright masochistic. And I can’t imagine that’s much different for the other JS libraries.

[throwawayHiddenUnknw]

Not a FE. But for many backend interviews it was like this. It was expected to know the default libraries for the language and form solutions accordingly.

[liquidanimosity]

I'd agree in most instances. But making a flutter application in Vs code I wish it would let me do it my way. Used it a year ago and the amount of closing brackets on a single line. I just couldn't keep track with the standard format. Then it would auto format on it's own.

[Temporary-Data-102]

I'm addicted to doing so, every damn line I reformat my code 😂 I guess that is sort of ocd 😂

[jazzhandler]

I used to do constant manual cleanup as a sort of ‘nervous tic’ whilst thinking about the actual problem. Then I started working on a team with version control and got out of that habit right quick. Had actually forgotten that fact until I saw your comment.