Jump to content

Talk:03 Coding Standards & Guidelines: Difference between revisions

From HEIN+FRICKE
Artha.kadamb@heinfricke.team (talk | contribs)
Artha.kadamb@heinfricke.team (talk | contribs)
Line 6: Line 6:


== 3 General Principles ==
== 3 General Principles ==
Code must be clean, consistent, and self-explanatory.


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


== 4 Coding Conventions ==
== 4 Coding Conventions ==

Revision as of 09:57, 22 December 2025

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