Talk:03 Coding Standards & Guidelines

1. Purpose

This document defines the coding standards and guidelines to ensure consistency, readability, maintainability, and quality across all software development projects within the organization.

2. Scope

These standards apply to all developers, contractors, and third parties who contribute to software development for Hein Fricke.

3. General Principles

• Code must be clean, consistent, and self-explanatory.
• Follow the DRY (Don't Repeat Yourself) principle.
• Optimize for readability over cleverness.
• Include meaningful comments where necessary.
• Ensure cross-platform and cross-browser compatibility where applicable.

4. Coding Conventions

4.1 Naming Conventions

Element	Convention	Example
Classes	PascalCase	EmployeeManager
Functions/Methods	camelCase	calculateSalary()
Variable	camelCase	employeeName
Constants	UPPER_CASE_SNAKE_CASE	MAX_RETRIES
Files	kebab-case or snake_case	employee-manager.js

4.2 Indentation and Spacing

• Use 4 spaces per indentation level (no tabs).
• Place opening braces on the same line.
• Leave a blank line between method definitions.

4.3 Line Length

• Maximum of 120 characters per line.

4.4 File Structure

• One class/component per file.
• Keep imports at the top.
• Group logically related functions and classes.

5. Language-Specific Standards

5.1 JavaScript/TypeScript

• Use `const` and `let`, avoid `var`.
• Prefer arrow functions.
• Use strict equality (===).
• Use ES6+ syntax.

5.2 Python

• Follow PEP8 standards.
• Use type hints for function signatures.
• Document functions with docstrings.

5.3 Java

• Follow Oracle Java Code Conventions.
• Use JavaDocs for documentation.
• Use appropriate access modifiers.

5.4 HTML/CSS

• Use semantic HTML tags.
• Use external stylesheets.
• Use BEM naming for CSS classes.

6. Version Control

• Use Git for source control.
• Commit messages should be clear and follow the format:

<type>: <short description>

[optional body]

[optional footer]

• Common commit types: feat, fix, docs, style, refactor, test, chore.

7. Code Review

• All code must be reviewed via pull requests.
• At least one peer reviewer is required before merging.
• Reviewers should check for:
  • Adherence to coding standards
  • Readability and clarity
  • Test coverage and documentation
  • Security and performance issues

8. Testing

• Write unit tests for all functions/methods.
• Maintain at least 80% code coverage.
• Include integration and end-to-end tests where applicable.
• Use automated CI pipelines for running tests.

For more details refer document JUnit_Test_Cases_Document.docx

9. Documentation

• All public APIs, classes, and modules must be documented.
• Use tools like JSDoc, Sphinx, or Swagger as appropriate.
• Maintain a project README.md with:
  • Project purpose
  • Setup instructions
  • Usage examples

10. Security Practices

• Validate all user input.
• Use parameterized queries to prevent SQL injection.
• Never store passwords in plain text.
• Sanitize data before rendering on the UI.

11. Compliance & Enforcement

• All developers must acknowledge this document.
• Non-compliance may result in code rejection or disciplinary action.
• Regular audits will be conducted.

12. References

• PEP8 - Python Style Guide: https://peps.python.org/pep-0008/
• Google Java Style Guide: https://google.github.io/styleguide/javaguide.html
• Airbnb JavaScript Style Guide: https://github.com/airbnb/javascript