4 ms·

these are all features you can blithely ignore: don't use backticks, and stick to native JS prototypes and the thin arrow. Without taking a personal stance on

these are all features you can blithely ignore: don't use backticks, and stick to native JS prototypes and the thin arrow. Without taking a personal stance on these features, I suggest that “You can ignore Language Feature X” is often a weak argument. If you feel X is harmful, not only must you ignore it, but you must consider all of the other developers, maintainers, and so forth who interact with your code. You personally may not use X, but what about your team mates? Your team (of 1+) may not use X, but do you ever have to debug modules or plugins written with X? If you really think X is a terrible idea, it’s in your best interests to discourage its existence, not just ignore it :-)

stcredzero 14y ago
Without taking a personal stance on these features, I suggest that “You can ignore Language Feature X” is often a weak argument. If you feel X is harmful, not only must you ignore it, but you must consider all of the other developers, maintainers, and so forth who interact with your code. There are tools that can cover this. You personally may not use X, but what about your team mates? Team leads should tell team members to use automated tools for coding standards. This takes care of most of this. Your team (of 1+) may not use X, but do you ever have to debug modules or plugins written with X? The Node.js community has a way of dealing with non evented-friendly code. Programming as a whole would probably benefit from more things like this.
- Scriptor 14y ago
  There are tools that can cover this. I'm curious, which tools can you use for this?
  - stcredzero 14y ago
    There are tons of these. Pycharm and related IDEs have Lint style tools for Javascript, for example. If your needs aren't met by existing tools, you can also roll your own. Many Lint-style programs have ways of coding your own checks.
- raganwald 14y ago
  I think we’re making the same point, namely that if “X” is harmful, simply ignoring X is insufficient, you must take active measures to avoid being “contaminated” by X. We can debate how much effort is involved firewalling your code from X. It obviously varies depending on what precisely X is and how popular X is, but you clearly have to do more than simply “ignore” it.
  - stcredzero 14y ago
    We can debate how much effort is involved firewalling your code from X. Well, this thread has brought me to the awareness that there is always going to be some effort in this regard. Whichever programming language is used makes no difference.
    - raganwald 14y ago
      FWIW, I agree about tools. I’ve certainly experimented with integrating Lint-like tools into the build process. Every team ought to have coding standards they enforce, whether mechanically, by eye, or a combination of both.

stcredzero 14y ago

Without taking a personal stance on these features, I suggest that “You can ignore Language Feature X” is often a weak argument. If you feel X is harmful, not only must you ignore it, but you must consider all of the other developers, maintainers, and so forth who interact with your code. There are tools that can cover this. You personally may not use X, but what about your team mates? Team leads should tell team members to use automated tools for coding standards. This takes care of most of this. Your team (of 1+) may not use X, but do you ever have to debug modules or plugins written with X? The Node.js community has a way of dealing with non evented-friendly code. Programming as a whole would probably benefit from more things like this.

Scriptor 14y ago
There are tools that can cover this. I'm curious, which tools can you use for this?
- stcredzero 14y ago
  There are tons of these. Pycharm and related IDEs have Lint style tools for Javascript, for example. If your needs aren't met by existing tools, you can also roll your own. Many Lint-style programs have ways of coding your own checks.
raganwald 14y ago
I think we’re making the same point, namely that if “X” is harmful, simply ignoring X is insufficient, you must take active measures to avoid being “contaminated” by X. We can debate how much effort is involved firewalling your code from X. It obviously varies depending on what precisely X is and how popular X is, but you clearly have to do more than simply “ignore” it.
- stcredzero 14y ago
  We can debate how much effort is involved firewalling your code from X. Well, this thread has brought me to the awareness that there is always going to be some effort in this regard. Whichever programming language is used makes no difference.
  - raganwald 14y ago
    FWIW, I agree about tools. I’ve certainly experimented with integrating Lint-like tools into the build process. Every team ought to have coding standards they enforce, whether mechanically, by eye, or a combination of both.