There should be some discussion around selecting 3rd party dependencies. In general we do not dictate a specific tool chain (such as particular IDE) but some technology choices whilst appearing to offer a better API fail to work nicely when combined with common practices such as code analysis. Likewise the decision not to embrace the oldest, most established unit testing framework in favour of a newer frameworks effectively means that we reduce the number of platforms our tests can run on.
Bottom line: where a capability / API exists in the languages 'standard library' you should think twice, or three times, before choosing to replace it with a 3rd party alternative. We stand a better chance of leveraging customers existing skills if we use as much of the standard library as we can, rather than idiosyncratic 3rd party options.
There should be some discussion around selecting 3rd party dependencies. In general we do not dictate a specific tool chain (such as particular IDE) but some technology choices whilst appearing to offer a better API fail to work nicely when combined with common practices such as code analysis. Likewise the decision not to embrace the oldest, most established unit testing framework in favour of a newer frameworks effectively means that we reduce the number of platforms our tests can run on.
Bottom line: where a capability / API exists in the languages 'standard library' you should think twice, or three times, before choosing to replace it with a 3rd party alternative. We stand a better chance of leveraging customers existing skills if we use as much of the standard library as we can, rather than idiosyncratic 3rd party options.