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

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

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.

Line Length

• Maximum of 120 characters per line.

File Structure

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

5 Language-Specific Standards

JavaScript/TypeScript

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

Python

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

Java

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

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 are mentioned in JUnit_Test_Cases_Document.docx document

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