Development Standards and Practices

Development standards and best practices are essential to building secure, maintainable, and scalable solutions. They provide a common language and structure for developers, ensuring quality and efficiency across teams, projects, and contributors.

Software / Code Standards

Coding Standards are crucial for building a sustainable, maintainable, and collaborative software development process. They serve as a cornerstone for the following:

• Consistency – Ensures that code looks and behaves predictably across the entire codebase regardless of the developer that writes it.
• Readability – Allows developers to understand and review code efficiently, while reducing onboarding time for new developers.
• Maintainability – Simplifies the process of debugging, enhancing, and refactoring existing code.
• Quality Assurance – Applies practices that reduce the risk of bugs and technical debt

By adhering to a set of well-defined coding standards, development teams can deliver solid, scalable, and secure software more effectively.

General Coding Standards

Code Readability

• Code is read more than it is written, therefore, write code for humans first, machines second.
• Use clear and consistent code over tricky or overly optimized solutions.
• Use consistent indentation (ex. 4 spaces per level).
• Remove unused code and dead comments.
• Break down long lines of code to a maximum of 80-120 characters.
• Use meaningful and descriptive names for variables, methods, and classes.

Naming Conventions

see Solution Naming Guidelines for more details.

Comments

• Write comments to explain why code exists; not what the code does (unless it’s not obvious)
• Use XML Documentation
• Avoid excessive or redundant comments

Security by Design

• Follow security coding practices from the start.

Test Early, Test Often

• Ensure thorough automated testing coverage

Coding Best Practices

1. Keep it Simple

• Breakdown large methods and classes into smaller, more manageable components

2. Follow the DRY (Don’t repeat yourself) principle

• Avoiding code duplication increases the code’s maintainability, readability, and quality
• Extract shared functionality into reusable method or classes

3. Single Responsibility

• Each class, method, or module should only have one purpose or responsibility

4. Error and Exception Handling

• Detect and surface errors early
• Use structured error handing processes by using try...catch...finally blocks for exceptions
• Log errors with meaningful messages to assist with troubleshooting

Language-specific Standards

C#

• Use var only when the type is obvious from the right-hand side of an assignment.
• Use using statements for disposable objects to manage resources effectively.

VB.Net

• Use clear Sub/Function blocks with consistent indentation
• Use Using...End Using for disposable objects
• Avoid using Structs

Testing Standards

1. Unit Tests

• Write unit tests for all core logic

2. Descriptive Test Names

• Use descriptive test names, so that it is clear of what is being tested.

3. Code Coverage

• Maintain > 80% code coverage, especially for critical logic

4. Mocking/Stubbing

• Use mocking and stubbing for external dependencies

Security Standards

Security is a shared responsibility and must be considered throughout the entire software development process. All participants must follow security guidelines when debugging, designing, writing, reviewing, and deploying code to ensure that the safety and integrity of our systems, data, and users is met.

Business Rules and Workspace Assemblies are powerful and flexible, but can introduce significant risk if not written securely.

1. Ensure Business Rules cannot be exploited or misused
2. Protect sensitive data handled in rules
3. Enforce access control for rule execution
4. Maintain secure audit and logging practices
5. Reduce risk of unintentional exposure or escalation of privilege

Code Review Standards

1. General

• Every code change must go through a review before being merged into the “main” branches
• No self-approvals unless explicitly allowed
• Peer reviews are required

2. Pull Request (PR) Requirements

• A Pull Request must have a clear title summarizing the change
• A Pull Request must have a detailed description explaining the “what” and “why” of the change
• A Pull Request must include any related issues or Jira ticket numbers
• If applicable, a Pull Request must include relevant designs, specs or screenshots.
• Pull Request should be small and focused
  • Less than 500 lines of code
• Large Pull Requests should be broken up or justified with content
• Pull Request should Not include unrelated changes (ex. Refactoring with New feature changes in the same PR)

3. Reviewers Expectations

• Reviews are responsible for maintaining the code quality and team standards
• Provide feedback withing 1-2 business days
• Read the entire PR description to understand the purpose of the change.
• Check code for the following:
  • Functionality and correctness
  • Code quality and readability
  • Security and performance concerns
  • Ensuring that the team-defined coding style and architecture standards are met.

4. Developers Expectations

• Developers submitting code for review must follow all project/team-defined coding standards.
• All code must compile and build successfully
• All code must pass local unit and integration tests
• Developers must be responsive to the reviewer comments
• Mark comments as Resolved once they are addressed or acknowledged by the review

5. Approval Rules
   • Minimum 1 required approval for non critical changes

Documentation Standards

Guiding Principles

• Clarity: – Documentation should be easy to understand by both technical and business audiences.
• Consistency: – Use consistent formatting, terminology, and naming across the entire document.
• Traceability: – All documentation should map to application components (BRs, Dashboards, Workflows, Data Sources, etc.)
• Version Control: – Documentation should be updated alongside solution changes.