---

Tobit.Labs™ Development Guidelines

This repository provides a central collection of development guidelines, conventions, and best practices used across Tobit.Labs projects.

The goal is to establish a consistent and maintainable foundation for software development while keeping individual projects flexible. These guidelines define common expectations for code structure, naming, architecture, design, and development workflows.

They are intended as a shared baseline rather than a rigid rulebook. Project-specific requirements may justify deviations when they result in a clearer or more appropriate solution.

Overview

Frontend

Guidelines for building modern frontend applications.

Topics include:

• React
• TypeScript
• Components and props
• Hooks and effects
• State management
• Redux
• Styling
• Project and folder structures
• Naming conventions
• Performance

→ frontend/

Backend

Common conventions for backend development and service architecture.

Topics may include:

• Project structure
• API design
• Data models
• Error handling
• Validation
• Authentication and authorization
• Logging
• Security

→ backend/

Git & Commits

Conventions for working with Git and maintaining a clean and understandable project history.

Topics include:

• Commit messages
• Branch naming
• Pull requests
• Merge strategies
• Repository conventions

→ git/

---

Guiding Principles

Across all guidelines, a few principles take precedence:

1. Clarity over cleverness Code should be easy to understand for developers who did not write it.

2. Consistency over personal preference Shared conventions reduce unnecessary decisions and make projects easier to navigate.

3. Maintainability over short-term convenience Solutions should remain understandable and adaptable as a project grows.

4. Automation over documentation where possible Rules that can reliably be enforced by tooling should be handled by tools such as ESLint, Prettier, TypeScript, or CI rather than relying solely on written guidelines.

5. Pragmatism over dogma Guidelines provide a common baseline. A justified exception is preferable to blindly following a rule that makes the resulting code worse.

---

Clear · Consistent · Scalable