IDE & Developer Tooling Standards
Developer tooling guidelines eliminate environmental friction so engineers can focus on building correct software. By standardizing editor extensions, automated formatting on save, pre-commit validation hooks, and containerized debugging environments, every team member works in an identical, audit-compliant development environment.
Tooling Philosophy: Automation Over Manual Discipline
Human willpower is an unreliable mechanism for enforcing coding conventions. If a standard can be automated via a language server, linter, or pre-commit hook, it must be automated. The goal is to catch syntax issues, type errors, security vulnerabilities, and formatting inconsistencies within the local editor before code ever reaches a pull request.
Mandatory & Recommended IDE Extensions
Linters & Formatters
- ESLint / Stylelint: Static error checking
- Prettier: Code formatting on save
- SonarLint: Local clean-code analysis
Security & Secrets
- GitGuardian / TruffleHog: Secrets detection
- Snyk / Trivy: Vulnerability scanning
- Even Better TOML / DotENV: Config safety
Productivity & Testing
- Vitest / Jest Runner: 1-click test execution
- GitLens: Inline blame and revision history
- Remote - Containers: DevContainer execution
Standardized Workspace Settings (.vscode/settings.json)
Pre-Commit Hooks with Husky & lint-staged
To prevent broken builds or formatting regressions from being committed, all repositories enforce pre-commit validation using Husky and lint-staged:
Reproducible DevContainers (.devcontainer/)
Complex microservices or multi-runtime projects must include a .devcontainer/devcontainer.json specifying Node, Python, and database dependencies so any engineer can spin up a fully isolated, working environment in VS Code or GitHub Codespaces with zero host contamination.
Copy this prompt to generate reproducible container configurations.
Community Discussion & Feedback
Attributed peer feedback and official Netspective architecture notes.