10 ms·

Birth of Prettier

77 points by garretruh 1y ago

TranquilMarmot 1y ago
When I first tried out Prettier back in the 2010s, I was immediately hooked on the idea of using an opinionated formatter. We had constant arguments about formatting, and our many JS codebases were a complete disaster as they had been worked on for many years by many people with nobody overseeing any of the formatting. I was a zealot - I spent weeks going into every single one of our JS codebases, running Prettier on all of the files, setting up CI/CD rules to enforce it, and teaching everybody how to set up format-on-save in their editors. Some people whined about it ("I don't like the way it does curly braces! Waaah!") but I was persistent and unwavering. All these years later, I'm elated that whenever I join a new company - engineering orgs almost always have all of this already set up, not just with JS/TS but almost every language out there. It makes getting up to speed on the actual content of the code so much faster. If I join your engineering org and you aren't using enforced, automatic, opinionated formatting on every single line of code that gets written that's a huge smell.
- DanielHB 1y ago
  One of my main pet peeves of working with other developers is people breaking from conventions because "it is not good". Yes even if a convention is bad you should still follow it, unstandardized codebase is the main root of all evil in large codebases. I try to avoid setting up conventions that can't be statically enforced (or at least enforced through tests/assertions). So yes, auto-formatters are a godsend because they statically enforce code-style. It has become standard feature in most languages stacks these days because of Prettier and gofmt.
  - whstl 1y ago
    +1. I'm a huge fan of custom linter rules. Instead of going through PRs and nit-picking stuff, I just create new custom linter rules that catch those team-specific or project-specific things. This has the positive effect of making things way more welcoming for junior devs and newcomers. Nothing replaces getting the first PR with almost no PR comments thanks to a linter. I hate that a lot of people read the assertion that "PR reviews are a form of creating an internal coding culture" and become human linters, only nit picking PRs for the power trip. This is not only annoying but also makes people ignore the more important parts of the review. I even made it a rule in every team I managed: if something is bothering you constantly in PRs and it can be replaced by a custom linter rule, let it go and write a linter rule for that later. I only met two people in my career who opposed this, and that was 100% because it made their nit-picking redundant.
    - schwartzworld 1y ago
      I often say that “nit” comments on prs are bad. It’s either important enough to make a linter rule, or not important enough to mention.
      - fenomas 1y ago
        I wouldn't go that far - to me what's important is that nits must be non-blocking. I.e. the author is free to ignore them if they disagree, and a PR review with only nit comments should be an approval. If those things are true, it's fine to have gray area between what's linted and what's mentioned in PR review.
        waisbrot 1y ago
        +1 For example, "nit: maybe call the function updateCreditCard instead of updateCard" If you disagree and think your function name is better (or that the two are equally bad), then I'm happy to go along with what you've got. But maybe you didn't think of this name or maybe I've convinced you. Either it's a quick fix (and no re-review needed) or you just dismiss my comment.
        harimau777 1y ago
        100% agree! The pattern that I've found works well is: Reviewing a PR with "Approval" status means that the comments are just suggestions. Choosing "Comment" status means that the comments are optional but important enough that I want to make sure that you read them. If you come back and say "I read them but decided not to make any changes" then I'm happy to approve the PR. Choosing "Request changes" means that the comments aren't just nits.
    - harimau777 1y ago
      The difficulty that I've run into is that one person's nit is another person's essential change. My experience has led me believe that there are several different ways that developers approach reading code; resulting in developers placing different value on different style rules. For example, when I am skimming code I primarily look at the code's "shape" and "flow". Where is there iteration? What code blocks are mutually exclusive? How does the code bail if there's an error? Etc. Therefore, things like indentation style and function decomposition are important to me because I need to be able to quickly see the overall layout of the code. As far as I can tell, other developers read code using more of a "depth first" style where the overall layout isn't as important. As a result, they tend not to care much about things like indentation style or decomposition.
  - throw45524947 1y ago
    I've recently worked for a company that had no linter and no formatter. It was Java backend, but we have those tools too :) My first PR received 70 comments, 98% was nit-picking. Things like "Rename `MyDomainEntity source` to `MyDomainEntity myDomainEntity`" (it was a MapStruct mapper). I was also asked to remove a simple parent class that I used (in tests!) to reduce duplicated code, something like `MyNewFeatureBaseTest`, because Create, Get, Update, Patch, Delete test classes where sharing some functionalitites. They fired me during the trial period after this PR. Before this experience I was also "let's follow conventions even if they are bad", but now that I saw this argument applied so blindly against me, where I wasn't even allowed to use a common class to avoid duplicated code, I don't know, it just feels wrong. 3 weeks later and I'm still unsure if I was really wrong or just being gaslighted. I get conventions like "we split tests in create, get, etc. classes" or "the type of the incoming payload must be called `SomeEntityInput` and the output must be called `SomeEntityOutput`", but 70 comments? And you want me to duplicate code because that's what you did until now, "because conventions"?
    - DanielHB 1y ago
      I am sorry for your experience but I do agree with you, the conventions you were dealing with are bad. It is preferable to avoid conventions that can't be statically enforced specifically to avoid this kind of scenario you are describing.
- normie3000 1y ago
  > format-on-save A dystopian feature!
  - whstl 1y ago
    I'll do one better: In the recent teams I worked, we even had "organize imports on save".
  - speed_spread 1y ago
    Fight the power, setup format on checkout with your own rules.
  - jjj123 1y ago
    I love format on save. I can type (or paste) ignoring whitespace, hit save, and everything pops right into place for me. Also, stuff not auto formatting is usually immediate feedback that I didn’t match my parenthesis or have some other major syntax error.
    - 1718627440 1y ago
      I do care about my whitespace and it does have meaning. Throwing it all away on safe sounds annoying.
      - rkomorn 1y ago
        I care about my vertical white space (eg: grouping some things together gives me some logical separation). I don't care about horizontal white space. That should just properly get indented and spaced into a consistent block format.
        1718627440 1y ago
        Fine, I do. Also most tools don't get the difference between indenting and aligning and mess that up.
      - jjj123 1y ago
- CaptainOfCoit 1y ago
  Sounds similar to my personal history of adopting StandardJS (https://github.com/standard/standard https://github.com/standard/standard) as soon as it appeared, doing the same at the org I was at the time. Based on memory, seems StandardJS appeared before Prettier in the ecosystem? It seems weird that StandardJS wasn't mentioned in this article, as surely the author must have known about it before starting Prettier. Still to this day I just use StandardJS when starting a new project, not even sure what the difference against Prettier is, it's more or less the same as far as I can tell but maybe faster?
  - nxrabl 1y ago
    Standard always struck me as kind of scummy - it tries to present itself as something bigger than what it really is, which is a tiny CLI wrapper around one guy’s ESLint config. You have to scroll way down the FAQ section before ESLint even gets mentioned. The author is just squatting on the “standard” namespace and using it to blag his way into relevance. Think how much more good it would do if the sponsors of this project were actually supporting ESLint directly instead of this useless middleware.
    - floydnoel 1y ago
      this 100% is why it isn't mentioned. StandardJS is just a scam that nobody uses except new devs who get tricked by its pervasive marketing.
dSebastien 1y ago
What I love about those tools is that you get the best of both worlds when you use them right. If you apply auto formatting in a pre commit hook, then you can format any way you want locally but whatever is in the repo is formatted uniformly. Fewer noise in diffs and total freedom
- dleeftink 1y ago
  Wouldn't that result in having to reorient yourself between the formatted/non-formatted files when comparing commits and messy code that is being worked on? Mind, I do value auto-formatting but wonder about the navigational costs when used this way.
  - jacknews 1y ago
    maybe code should be stored with no formatting, only the required whitespace, and the editors/viewers are responsible for applying formatting. Then formatting will never cause confusion in diffs.
  - nicbou 1y ago
    The hook is just a safeguard, but ideally your editor should run the same code.
foofoo12 1y ago
My love for Prettier went to hate when they started fucking up my parenthesis in calculations. Still an open issue from 2017: https://github.com/prettier/prettier/issues/187 https://github.com/prettier/prettier/issues/187
- lifestyleguru 1y ago
  A lot of tools are fucking up the parentheses and apostrophes. Unnecessarily adding, removing, matching, or closing them. In terms of parentheses and apostrophes I know what I'm doing, stop "helping".
  - maratc 1y ago
    It's just not a big issue today if you know what you're doing or not, as everyone now seems to care about "consistency" only. My personal pet peeve is python's formatter named "black" (mentioned in TLA) that converts this: important_numbers = { "x": 3, "y": 42, # Answer to the Ultimate Question! "z": 2 } into this: important_numbers = {"x": 3, "y": 42, "z": 2} # Answer to the Ultimate Question!
    - ezarowny 1y ago
      I imagine if you add a comma to the end of the `"z": 2` line, Black will not try and push the dict onto a single line.
- moring 1y ago
  That Github issue doesn't really stress how serious he problem is. They make it sound like unnecessary parentheses get removed when they should be kept for clarify. What actually happens is that necessary parentheses get removed, altering the meaning of the expression. The example I encountered myself was this or similar to it (can't remember exactly): (a || b) && c --> a || b && c which then gets interpreted as a || (b && c)
  - Guillaume86 1y ago
rendall 1y ago
> One interesting side effect is that I changed the most number of lines of code company wide that year and got my name on the "blame" for most of the JavaScript files that existed at that time. So over the years I kept getting random people or scripts pinging me about code I had no idea about! Not sure who needs to hear this, but in case anyone runs into this problem, you can create a list of commit hashes that `git blame` will ignore. Commit all of your formatting changes in one push and then put its hash in the ignore file. https://git-scm.com/docs/git-blame#Documentation/git-blame.txt---ignore-revs-fileltfilegt https://git-scm.com/docs/git-blame#Documentation/git-blame.t... This feature was created as a direct response to automated formatters like Prettier!
- zbycz 1y ago
  Wow! Definitely will use, when enforcing new eslint rules. Thanks for sharing this, i just love git :)
  - rendall 1y ago
    github uses it too https://docs.github.com/en/repositories/working-with-files/using-files/viewing-and-understanding-files#ignore-commits-in-the-blame-view https://docs.github.com/en/repositories/working-with-files/u...
harimau777 1y ago
I strongly dislike and disagree with Prettier. From a practical standpoint, I disagree with the idea that coding style is just "bikeshedding". Coding style has a DRAMATIC impact on how readable code is and therefore how easy it is to understand. In my experience, fighting to keep code understandable is one of the most difficult and important parts of software engineering. In particular, by not allowing the user to change indentation style Prettier makes JavaScript much more difficult to read. From a social standpoint, I think that by labeling things "bikeshedding", Prettier represents a toxic approach to team dynamics. Just because something isn't important to you doesn't mean that it's not essential to someone else. IMHO, Prettier was a massive setback for the JavaScript community.
- CodingJeebus 1y ago
  The challenge is that it’s easy to find fundamental disagreements on a team on how a codebase should be styled, especially when the language itself doesn’t provide much guidance on styling convention. When that happens, it’s easy for a debate around styling to go on without ever finding consensus. I’m way more open to adopting coding style that’s not my personal taste as long as it’s consistent and tools like prettier really help with that.
  - harimau777 1y ago
    I can see how that would be a challenge. I think the key may be to focus on identifying which things are just a given developer's preference and which are essential to their productivity. Like you said, I'm more than happy to adopt a style that isn't my personal taste. The problem comes when the style prevents me from doing my job.
- cheema33 1y ago
  > I strongly dislike and disagree with Prettier. Have you ever worked in a large team where everybody has their own idea on how code should be formatted? If not, then I can understand your position. Do you get to review PRs where formatting changes make majority of the changes? Because some people don't use code formatters, others do but use different rules from each other. You may call this freedom, others may call it hell.
Aldipower 1y ago
Someone remembers 'perltidy'? :-) Was this the birth of code formatters?
eps 1y ago
Never heard of it. Apparently it's "an opnionated code formatter" - https://prettier.io https://prettier.io
ieie3366 1y ago
Looking back at it, just crazy how much effort and man-hours went to manually editing whitespace and arguing/nitpicking about it. This is something that should have been automated by the 90s.
hownowbrowncow 1y ago
Prettier and other format-on-save tools remain a huge quality of life improvement. I also think it found success because the defaults and choices outlined in the article were very wisely chosen: very readable in almost every context. The right tradeoffs were made both in printing logic and psychology with options/rollout. One other subtle interaction that is hard to live without now: watching code shift with format-on-save is the fastest feedback on whether code will build/run. Don’t need to look at another console for a syntax error almost ever.
NoSalt 1y ago
The formatting "standard" simply boils down to who the biggest fish in the small pond happens to be at the current location in time and space.
andrewmcwatters 1y ago
Je n'ai jamais vu un jeu de mots comme celui-ci où « i » a été remplacé par un « j » pour créer l'expression « vieux jeux ». C'est créatif.

77 points by garretruh 1y ago

When I first tried out Prettier back in the 2010s, I was immediately hooked on the idea of using an opinionated formatter. We had constant arguments about formatting, and our many JS codebases were a complete disaster as they had been worked on for many years by many people with nobody overseeing any of the formatting. I was a zealot - I spent weeks going into every single one of our JS codebases, running Prettier on all of the files, setting up CI/CD rules to enforce it, and teaching everybody how to set up format-on-save in their editors. Some people whined about it ("I don't like the way it does curly braces! Waaah!") but I was persistent and unwavering. All these years later, I'm elated that whenever I join a new company - engineering orgs almost always have all of this already set up, not just with JS/TS but almost every language out there. It makes getting up to speed on the actual content of the code so much faster. If I join your engineering org and you aren't using enforced, automatic, opinionated formatting on every single line of code that gets written that's a huge smell.

DanielHB 1y ago
One of my main pet peeves of working with other developers is people breaking from conventions because "it is not good". Yes even if a convention is bad you should still follow it, unstandardized codebase is the main root of all evil in large codebases. I try to avoid setting up conventions that can't be statically enforced (or at least enforced through tests/assertions). So yes, auto-formatters are a godsend because they statically enforce code-style. It has become standard feature in most languages stacks these days because of Prettier and gofmt.
- whstl 1y ago
  +1. I'm a huge fan of custom linter rules. Instead of going through PRs and nit-picking stuff, I just create new custom linter rules that catch those team-specific or project-specific things. This has the positive effect of making things way more welcoming for junior devs and newcomers. Nothing replaces getting the first PR with almost no PR comments thanks to a linter. I hate that a lot of people read the assertion that "PR reviews are a form of creating an internal coding culture" and become human linters, only nit picking PRs for the power trip. This is not only annoying but also makes people ignore the more important parts of the review. I even made it a rule in every team I managed: if something is bothering you constantly in PRs and it can be replaced by a custom linter rule, let it go and write a linter rule for that later. I only met two people in my career who opposed this, and that was 100% because it made their nit-picking redundant.
  - schwartzworld 1y ago
    I often say that “nit” comments on prs are bad. It’s either important enough to make a linter rule, or not important enough to mention.
    - fenomas 1y ago
      I wouldn't go that far - to me what's important is that nits must be non-blocking. I.e. the author is free to ignore them if they disagree, and a PR review with only nit comments should be an approval. If those things are true, it's fine to have gray area between what's linted and what's mentioned in PR review.
      - waisbrot 1y ago
        +1 For example, "nit: maybe call the function updateCreditCard instead of updateCard" If you disagree and think your function name is better (or that the two are equally bad), then I'm happy to go along with what you've got. But maybe you didn't think of this name or maybe I've convinced you. Either it's a quick fix (and no re-review needed) or you just dismiss my comment.
      - harimau777 1y ago
        100% agree! The pattern that I've found works well is: Reviewing a PR with "Approval" status means that the comments are just suggestions. Choosing "Comment" status means that the comments are optional but important enough that I want to make sure that you read them. If you come back and say "I read them but decided not to make any changes" then I'm happy to approve the PR. Choosing "Request changes" means that the comments aren't just nits.
  - harimau777 1y ago
    The difficulty that I've run into is that one person's nit is another person's essential change. My experience has led me believe that there are several different ways that developers approach reading code; resulting in developers placing different value on different style rules. For example, when I am skimming code I primarily look at the code's "shape" and "flow". Where is there iteration? What code blocks are mutually exclusive? How does the code bail if there's an error? Etc. Therefore, things like indentation style and function decomposition are important to me because I need to be able to quickly see the overall layout of the code. As far as I can tell, other developers read code using more of a "depth first" style where the overall layout isn't as important. As a result, they tend not to care much about things like indentation style or decomposition.
- throw45524947 1y ago
  I've recently worked for a company that had no linter and no formatter. It was Java backend, but we have those tools too :) My first PR received 70 comments, 98% was nit-picking. Things like "Rename `MyDomainEntity source` to `MyDomainEntity myDomainEntity`" (it was a MapStruct mapper). I was also asked to remove a simple parent class that I used (in tests!) to reduce duplicated code, something like `MyNewFeatureBaseTest`, because Create, Get, Update, Patch, Delete test classes where sharing some functionalitites. They fired me during the trial period after this PR. Before this experience I was also "let's follow conventions even if they are bad", but now that I saw this argument applied so blindly against me, where I wasn't even allowed to use a common class to avoid duplicated code, I don't know, it just feels wrong. 3 weeks later and I'm still unsure if I was really wrong or just being gaslighted. I get conventions like "we split tests in create, get, etc. classes" or "the type of the incoming payload must be called `SomeEntityInput` and the output must be called `SomeEntityOutput`", but 70 comments? And you want me to duplicate code because that's what you did until now, "because conventions"?
  - DanielHB 1y ago
    I am sorry for your experience but I do agree with you, the conventions you were dealing with are bad. It is preferable to avoid conventions that can't be statically enforced specifically to avoid this kind of scenario you are describing.
normie3000 1y ago
> format-on-save A dystopian feature!
- whstl 1y ago
  I'll do one better: In the recent teams I worked, we even had "organize imports on save".
- speed_spread 1y ago
  Fight the power, setup format on checkout with your own rules.
- jjj123 1y ago
  I love format on save. I can type (or paste) ignoring whitespace, hit save, and everything pops right into place for me. Also, stuff not auto formatting is usually immediate feedback that I didn’t match my parenthesis or have some other major syntax error.
  - 1718627440 1y ago
    I do care about my whitespace and it does have meaning. Throwing it all away on safe sounds annoying.
    - rkomorn 1y ago
      I care about my vertical white space (eg: grouping some things together gives me some logical separation). I don't care about horizontal white space. That should just properly get indented and spaced into a consistent block format.
      - 1718627440 1y ago
        Fine, I do. Also most tools don't get the difference between indenting and aligning and mess that up.
    - jjj123 1y ago
CaptainOfCoit 1y ago
Sounds similar to my personal history of adopting StandardJS (https://github.com/standard/standard https://github.com/standard/standard) as soon as it appeared, doing the same at the org I was at the time. Based on memory, seems StandardJS appeared before Prettier in the ecosystem? It seems weird that StandardJS wasn't mentioned in this article, as surely the author must have known about it before starting Prettier. Still to this day I just use StandardJS when starting a new project, not even sure what the difference against Prettier is, it's more or less the same as far as I can tell but maybe faster?
- nxrabl 1y ago
  Standard always struck me as kind of scummy - it tries to present itself as something bigger than what it really is, which is a tiny CLI wrapper around one guy’s ESLint config. You have to scroll way down the FAQ section before ESLint even gets mentioned. The author is just squatting on the “standard” namespace and using it to blag his way into relevance. Think how much more good it would do if the sponsors of this project were actually supporting ESLint directly instead of this useless middleware.
  - floydnoel 1y ago
    this 100% is why it isn't mentioned. StandardJS is just a scam that nobody uses except new devs who get tricked by its pervasive marketing.

dSebastien 1y ago

What I love about those tools is that you get the best of both worlds when you use them right. If you apply auto formatting in a pre commit hook, then you can format any way you want locally but whatever is in the repo is formatted uniformly. Fewer noise in diffs and total freedom

dleeftink 1y ago
Wouldn't that result in having to reorient yourself between the formatted/non-formatted files when comparing commits and messy code that is being worked on? Mind, I do value auto-formatting but wonder about the navigational costs when used this way.
- jacknews 1y ago
  maybe code should be stored with no formatting, only the required whitespace, and the editors/viewers are responsible for applying formatting. Then formatting will never cause confusion in diffs.
- nicbou 1y ago
  The hook is just a safeguard, but ideally your editor should run the same code.

foofoo12 1y ago

My love for Prettier went to hate when they started fucking up my parenthesis in calculations. Still an open issue from 2017: https://github.com/prettier/prettier/issues/187 https://github.com/prettier/prettier/issues/187

lifestyleguru 1y ago
A lot of tools are fucking up the parentheses and apostrophes. Unnecessarily adding, removing, matching, or closing them. In terms of parentheses and apostrophes I know what I'm doing, stop "helping".
- maratc 1y ago
  It's just not a big issue today if you know what you're doing or not, as everyone now seems to care about "consistency" only. My personal pet peeve is python's formatter named "black" (mentioned in TLA) that converts this: important_numbers = { "x": 3, "y": 42, # Answer to the Ultimate Question! "z": 2 } into this: important_numbers = {"x": 3, "y": 42, "z": 2} # Answer to the Ultimate Question!
  - ezarowny 1y ago
    I imagine if you add a comma to the end of the `"z": 2` line, Black will not try and push the dict onto a single line.
moring 1y ago
That Github issue doesn't really stress how serious he problem is. They make it sound like unnecessary parentheses get removed when they should be kept for clarify. What actually happens is that necessary parentheses get removed, altering the meaning of the expression. The example I encountered myself was this or similar to it (can't remember exactly): (a || b) && c --> a || b && c which then gets interpreted as a || (b && c)
- Guillaume86 1y ago

rendall 1y ago

> One interesting side effect is that I changed the most number of lines of code company wide that year and got my name on the "blame" for most of the JavaScript files that existed at that time. So over the years I kept getting random people or scripts pinging me about code I had no idea about! Not sure who needs to hear this, but in case anyone runs into this problem, you can create a list of commit hashes that `git blame` will ignore. Commit all of your formatting changes in one push and then put its hash in the ignore file. https://git-scm.com/docs/git-blame#Documentation/git-blame.txt---ignore-revs-fileltfilegt https://git-scm.com/docs/git-blame#Documentation/git-blame.t... This feature was created as a direct response to automated formatters like Prettier!

zbycz 1y ago
Wow! Definitely will use, when enforcing new eslint rules. Thanks for sharing this, i just love git :)
- rendall 1y ago
  github uses it too https://docs.github.com/en/repositories/working-with-files/using-files/viewing-and-understanding-files#ignore-commits-in-the-blame-view https://docs.github.com/en/repositories/working-with-files/u...

harimau777 1y ago

I strongly dislike and disagree with Prettier. From a practical standpoint, I disagree with the idea that coding style is just "bikeshedding". Coding style has a DRAMATIC impact on how readable code is and therefore how easy it is to understand. In my experience, fighting to keep code understandable is one of the most difficult and important parts of software engineering. In particular, by not allowing the user to change indentation style Prettier makes JavaScript much more difficult to read. From a social standpoint, I think that by labeling things "bikeshedding", Prettier represents a toxic approach to team dynamics. Just because something isn't important to you doesn't mean that it's not essential to someone else. IMHO, Prettier was a massive setback for the JavaScript community.

CodingJeebus 1y ago
The challenge is that it’s easy to find fundamental disagreements on a team on how a codebase should be styled, especially when the language itself doesn’t provide much guidance on styling convention. When that happens, it’s easy for a debate around styling to go on without ever finding consensus. I’m way more open to adopting coding style that’s not my personal taste as long as it’s consistent and tools like prettier really help with that.
- harimau777 1y ago
  I can see how that would be a challenge. I think the key may be to focus on identifying which things are just a given developer's preference and which are essential to their productivity. Like you said, I'm more than happy to adopt a style that isn't my personal taste. The problem comes when the style prevents me from doing my job.
cheema33 1y ago
> I strongly dislike and disagree with Prettier. Have you ever worked in a large team where everybody has their own idea on how code should be formatted? If not, then I can understand your position. Do you get to review PRs where formatting changes make majority of the changes? Because some people don't use code formatters, others do but use different rules from each other. You may call this freedom, others may call it hell.

Aldipower 1y ago

Someone remembers 'perltidy'? :-) Was this the birth of code formatters?

eps 1y ago

Never heard of it. Apparently it's "an opnionated code formatter" - https://prettier.io https://prettier.io

ieie3366 1y ago

Looking back at it, just crazy how much effort and man-hours went to manually editing whitespace and arguing/nitpicking about it. This is something that should have been automated by the 90s.

hownowbrowncow 1y ago

Prettier and other format-on-save tools remain a huge quality of life improvement. I also think it found success because the defaults and choices outlined in the article were very wisely chosen: very readable in almost every context. The right tradeoffs were made both in printing logic and psychology with options/rollout. One other subtle interaction that is hard to live without now: watching code shift with format-on-save is the fastest feedback on whether code will build/run. Don’t need to look at another console for a syntax error almost ever.

NoSalt 1y ago

The formatting "standard" simply boils down to who the biggest fish in the small pond happens to be at the current location in time and space.

andrewmcwatters 1y ago

Je n'ai jamais vu un jeu de mots comme celui-ci où « i » a été remplacé par un « j » pour créer l'expression « vieux jeux ». C'est créatif.