should consider the ability to synchronize between IDEs and scripts to be a high priority as IDEs and other build tools serve complimentary purposes, and are of the most value when their configurations match as much as possible.
You can benefit by versioning configurations relating to style that can be universally used by all team members. It’s important to keep the build scripts as the source of build and dependency configuration as much as you can. Bridging The Gap between IDE and Build Tools The private build pattern gives the most concise guidance for how to ensure that a build is sync: run a build in your workspace with the same toolset that works in the integration build. A continuous integration process (running the integration build patterns) provides a backstop for when you goof. Incremental builds are fine in an IDE when you are coding, and the instant compilation that occurs after a change helps to maintain flow when coding. There can be subtle, and not so subtle, differences on the build environments, though, that range from specific compiler implementations to path configurations. This means that what works in your IDE may not work in your build and broken builds slow everyone down
As long as the contract of the integration build being successful is honored, we should not need to overly constrain how developers work.
What To Do? IDEs are a common part of a developer's tool kit. They are highly customizable, increase productivity, and help enforce coding standards. Some developers have very strong opinions about what the best one is. Every team struggles with development standards. Standards affect communication (coding standards) and execution (tool standards). Standards can help a team be more effective by eliminating discussion on matters that are less important to the end result and also by enhancing communication by establishing a common style and language.
Too many standards, or standards applied to appropriate concepts can have the effect, reduce productivity and cause the team to spend a disproportionate time coding to the standard, rather than delivering value. Let's wrap up by offering some recommendations on the questions we raised at the start of this article. We recommend:
• Allow team members to work with whatever development environment toolset that is most productive for them, given the constraints of the project.
• Define your workspace set up process in terms of the least common demominator: getting the files on disk using command line tools for example. This will help establish consistency with the Integration Build environment.
• Focus on defining end results, not mechanisms. If indentation is important, specify the rules, not the IDE. Recommendations are fine, but if someone is more productive with a different toolset than the recommended one, it should be fine.
• If something is really important, add it to the build. There are plugins that will run style checks (both cosmetic and functional) at build time, generating warnings or failing the build if something is amiss. The integration build is the one point in the process where a consistent environment is guaranteed, so it’s good to use as a gate.
• Version only primary artifacts and use tools to generate secondary ones, such as build settings for an IDE, where feasible. Primary artifacts include build files, but not IDE configuration files relating to build settings. If the IDE has the ability to version style related artifacts independently of the project configurations, these should be treated as versioned artifacts.
The measure of whether the toolset works is whether the code meets the standards set by the build and also whether those using other tools can