Code

1. Use a clear and descriptive title for the PR.

Avoid vague titles like Updated — they don’t communicate what changed. A good PR title summarizes the intent of the changes.

✅ Good examples: - Fix: Remove __pycache__ and .db files - Refactor: Rename component files for consistency - Chore: Clean up console.log statements

---

2. Don’t commit __pycache__ or .pyc files.

These are automatically generated by Python and should not be versioned. They clutter the repo and vary across environments.

• Add these to .gitignore:

  __pycache__/
  *.pyc
  

• Set this in your environment to prevent local writes:

  export PYTHONDONTWRITEBYTECODE=1
  

---

3. Don’t commit venv/ or .venv/ folders.

Virtual environments are local to your machine. They contain OS-specific binaries and shouldn't be checked into git.

Add to .gitignore:

venv/
.venv/

---

4. Don’t include .db files or other binary files.

SQLite or binary files are not portable, cause merge conflicts, and should never be committed.

✅ Instead:

• Use seed scripts or migrations
• Add to .gitignore:

  *.db
  

---

5. Don’t commit machine-dependent or generated files.

Avoid committing: - IDE configs (e.g. .vscode/) - Build outputs (*.log, *.bin, compiled files) - .DS_Store, .log, etc.

Keep your commits clean and portable across systems.

---

6. Remove console.log() statements before submitting.

These should not be left in the production code unless explicitly needed for logging. Use a logging utility if required.

---

7. Fix spelling mistakes in filenames and identifiers.

Example: ❌ VedioPlayer.svelte ✅ VideoPlayer.svelte

Spelling mistakes hurt searchability and reflect poorly on code professionalism.

---

8. Use consistent capitalization for component files.

Follow PascalCase for Svelte components: ✅ Button.svelte ❌ button.svelte

• Backend python files should be all smalls. For eg: renders.py
• Multi word file names should be avoided. If absolutely needed, _ should be used for space. For eg: api_routes.py

This avoids confusion and bugs on case-sensitive filesystems (e.g., Linux) and keeps the file structure consistent.

---

9. Follow RESTful naming conventions for API routes.

We already discussed this during your interview assignment. Avoid actions like /getProjectDetails. Instead:

Action	Method	RESTful Route
Get user info	GET	/users/:id
Create project	POST	/projects
Update project	PUT	/projects/:id
Delete a resource	DELETE	/resources/:id

---

10. Avoid Adding Unnecessary Dependencies.

❗ Always avoid introducing plugins, architectural patterns, or external libraries unless absolutely necessary.

Why it matters: - Every dependency increases maintenance and onboarding complexity - It adds abstraction that may not be justified for smaller projects - Makes debugging and testing more complex

✅ For eg: Stick with Flask’s built-in @app.route decorators unless: - No need to use flask-blueprints plugin - The project is large enough to benefit from modular separation (e.g., auth, user, admin) - There is a real and current need for abstraction

Before adding a dependency, ask: - Can this be done simply with what's already available? - Will this make the project harder to maintain? - Are there multiple contributors familiar with this tool?

🧠 Keeping things simple makes the project easier to maintain and scale.