4 ms·

I'm more troubled that we might be banishing perfectly good features for the flimsiest of reasons. Take, for example, JavaScript's double-equals == versus trip

by jt2190 7y ago

I'm more troubled that we might be banishing perfectly good features for the flimsiest of reasons. Take, for example, JavaScript's double-equals == versus triple-equals === comparison operators. (I already know you have a strong opinion on these!) The language designer saw fit to include both. Now, if I introduce one bug where I need to use === explicitly instead of ==, should I advocate for a ban the use of == across the entire program? How about if I introduce this bug twice? Three times? What if I've only heard from a senior dev that triple-equals is "bad"? Or should we test the least-experienced member of the team and let their understanding make the decision for us? What happens when that team member gets more experience, do we lift the ban? Double- versus triple-equals example is probably one of the most clear cut trade-offs and worth exploring. What about all of the other rules? Double versus single quotes, for example? What about declaring arrays using array-literal syntax versus using the new operator?

matthewmacleod 7y ago
The threequal operator aside, my experience is that none of these decisions really matter in themselves. What is far more important is agreement and consistency. Use the same style everywhere, enforce it automatically, don’t bikeshed over it, and get on with doing actual things that matter.
deleted 7y ago
[deleted]
nixpulvis 7y ago
Safety pretty much always comes at a cost (of some kind) Even if that cost is just being forced into a more restrictive model. In some cases this actually limits what you can do, but in the case of JS's === it's about doing what the programmer is expecting. I think many people would agree that JS casts types too liberally at times [1], and using === is a good way to avoid the confusion that can cause. Other language features cause other confusions. Quotes generally boil down to arguments about escaping, and have good reason for existing. Having a rule for when to use what quotes should be pretty inferable from when you need to use what quote to escape the data in question. New array vs literal is more a pure aesthetics issue, and I can only really say, choose whatever you think the majority of people would read faster. Don't be different just to be different, and move on. 1: https://www.destroyallsoftware.com/talks/wat https://www.destroyallsoftware.com/talks/wat
mrmr1993 7y ago
> The language designer saw fit to include both. === wasn't introduced until ECMAScript 3 in 1999, originally there was only == when the language was created in '95. The accepted wisdom is to prefer the newer === in the interest of clarity and consistency. With ==, it's easy to forget about one of the types it overloads (e.g. string vs. number) when making changes to existing code, and correct-looking code may behave unexpectedly for one of these types.

by jt2190 7y ago

matthewmacleod 7y ago

The threequal operator aside, my experience is that none of these decisions really matter in themselves. What is far more important is agreement and consistency. Use the same style everywhere, enforce it automatically, don’t bikeshed over it, and get on with doing actual things that matter.

deleted 7y ago

[deleted]

nixpulvis 7y ago

Safety pretty much always comes at a cost (of some kind) Even if that cost is just being forced into a more restrictive model. In some cases this actually limits what you can do, but in the case of JS's === it's about doing what the programmer is expecting. I think many people would agree that JS casts types too liberally at times [1], and using === is a good way to avoid the confusion that can cause. Other language features cause other confusions. Quotes generally boil down to arguments about escaping, and have good reason for existing. Having a rule for when to use what quotes should be pretty inferable from when you need to use what quote to escape the data in question. New array vs literal is more a pure aesthetics issue, and I can only really say, choose whatever you think the majority of people would read faster. Don't be different just to be different, and move on. 1: https://www.destroyallsoftware.com/talks/wat https://www.destroyallsoftware.com/talks/wat

mrmr1993 7y ago

> The language designer saw fit to include both. === wasn't introduced until ECMAScript 3 in 1999, originally there was only == when the language was created in '95. The accepted wisdom is to prefer the newer === in the interest of clarity and consistency. With ==, it's easy to forget about one of the types it overloads (e.g. string vs. number) when making changes to existing code, and correct-looking code may behave unexpectedly for one of these types.