5 ms·

Unfortunately in the JS community you cannot say these things without being punished. If you do anything else than strict eslint with "airbnb settings", or defa

Unfortunately in the JS community you cannot say these things without being punished. If you do anything else than strict eslint with "airbnb settings", or default prettier settings, your head goes off! Don't ever say this to your JS team mate. It's a very rigid community if it comes to these futilities.

Waterluvian 8y ago
This is... puzzling. Where do you see these attitudes? Both ways are perfectly cromulent and it's fine for people to have opinions. In my years of JS dev the main thing I've seen from the community is "pick a style and stick to it. Be consistent." And that's pretty typical and sage advice of all programming. The reason to downvote parent is that it's bringing up a tired debate. We may as well discuss tabs vs. spaces while we're at it.
- wanted2 8y ago
  > The reason to downvote parent is that it's bringing up a tired debate. Do you mean that even when it is scientifically proved that your code is more readable when using more white space like in: console.log( "Hello world!" ); we are not even allowed to mention that because some random dudes decided we have to adhere to the "airbnb" settings? I bring this up because I think it's pathetic, like many other things in the JS community. Tired debate or not, we should have freedom of thinking and speech please! Programming is also a very creative activity, we should not destroy that with these kind of silly rules that make it more of an administrative activity.
  - matthewmacleod 8y ago
    No, you’re free to talk about whatever you want. But don’t expect pointless bikeshedding to be well-received. First, it’s not a real problem. The JS community is pretty much equivalent to any other of this matter. Second, it’s not a big issue. Use a code formatter to make sure shared code is in the agreed style for whatever project you are contributing to. Third, this does not affect your own code. You are free and encouraged to use whatever formatting convention works for your own teams. Just make sure it’s consistent and enforced. Keeping consistent style is anything but a “silly rule” and it’s essentially no effort.
    - wanted2 8y ago
      It is a real problem, I've seen heated discussions in a few companies, and it can take out a big part of the fun you have in your work. We really need to write an editor plugin/solution for this. Your editor should show the code in your preferred style, but saving it in the team's agreed style. And then a local-style.js for your own settings, and a team-style.js for the team settings. local-style.js in the .gitignore. Should be possible though?
      - Waterluvian 8y ago
        You could absolutely make that. It sounds neat.
      - acdha 8y ago
        It'd be possible but it's a non-trivial amount of work: think about things like linting or debuggers where line numbers might vary substantially, sequencing things in tools around merges and code review, etc. The option you can do right now is to use something like Prettier where everyone's experience is entirely consistent and you have no cognitive load switching styles or dealing with inconsistency. This is basically free and means that there's a whole slew of high-emotion discussions which you can stop having for the rest of your career, in favor of working on things which actually matter. The older I get, the more that looks like pure win.
- runarberg 8y ago
  If I remember correctly it used to be the case that every JavaScript repo came with it's own eccentric style. I'm certainly guilty of that. Now -- when we have these style "standard" style guides -- we've sort of settled on 3 or 4 competing standards. None of them look particularly bad (or at least not worse then my personal style cerca 2012). Don't get me wrong. We still engage in stupid bikeshedding about semi vs. no semi, tabs vs. spaces etc. but I feel overall we've embiggened our spirit when it comes to code style debates.

Waterluvian 8y ago

This is... puzzling. Where do you see these attitudes? Both ways are perfectly cromulent and it's fine for people to have opinions. In my years of JS dev the main thing I've seen from the community is "pick a style and stick to it. Be consistent." And that's pretty typical and sage advice of all programming. The reason to downvote parent is that it's bringing up a tired debate. We may as well discuss tabs vs. spaces while we're at it.

wanted2 8y ago
> The reason to downvote parent is that it's bringing up a tired debate. Do you mean that even when it is scientifically proved that your code is more readable when using more white space like in: console.log( "Hello world!" ); we are not even allowed to mention that because some random dudes decided we have to adhere to the "airbnb" settings? I bring this up because I think it's pathetic, like many other things in the JS community. Tired debate or not, we should have freedom of thinking and speech please! Programming is also a very creative activity, we should not destroy that with these kind of silly rules that make it more of an administrative activity.
- matthewmacleod 8y ago
  No, you’re free to talk about whatever you want. But don’t expect pointless bikeshedding to be well-received. First, it’s not a real problem. The JS community is pretty much equivalent to any other of this matter. Second, it’s not a big issue. Use a code formatter to make sure shared code is in the agreed style for whatever project you are contributing to. Third, this does not affect your own code. You are free and encouraged to use whatever formatting convention works for your own teams. Just make sure it’s consistent and enforced. Keeping consistent style is anything but a “silly rule” and it’s essentially no effort.
  - wanted2 8y ago
    It is a real problem, I've seen heated discussions in a few companies, and it can take out a big part of the fun you have in your work. We really need to write an editor plugin/solution for this. Your editor should show the code in your preferred style, but saving it in the team's agreed style. And then a local-style.js for your own settings, and a team-style.js for the team settings. local-style.js in the .gitignore. Should be possible though?
    - Waterluvian 8y ago
      You could absolutely make that. It sounds neat.
    - acdha 8y ago
      It'd be possible but it's a non-trivial amount of work: think about things like linting or debuggers where line numbers might vary substantially, sequencing things in tools around merges and code review, etc. The option you can do right now is to use something like Prettier where everyone's experience is entirely consistent and you have no cognitive load switching styles or dealing with inconsistency. This is basically free and means that there's a whole slew of high-emotion discussions which you can stop having for the rest of your career, in favor of working on things which actually matter. The older I get, the more that looks like pure win.
runarberg 8y ago
If I remember correctly it used to be the case that every JavaScript repo came with it's own eccentric style. I'm certainly guilty of that. Now -- when we have these style "standard" style guides -- we've sort of settled on 3 or 4 competing standards. None of them look particularly bad (or at least not worse then my personal style cerca 2012). Don't get me wrong. We still engage in stupid bikeshedding about semi vs. no semi, tabs vs. spaces etc. but I feel overall we've embiggened our spirit when it comes to code style debates.