Skip to content

Language Specific Standards

Jesse edited this page Dec 8, 2025 · 2 revisions

Consistent coding standards help ensure that every team member writes clear, maintainable, and predictable code β€” regardless of language or IDE.
These guidelines give you a solid foundation of best practices, while separate subpages contain deeper explanations, examples, and project-specific requirements.

Use the sections below to learn the expectations for each language used in the practicum.


General Overview of Language Standards

View General Coding Standards Overview

Regardless of language, our coding standards focus on:

1. Readability

  • Write code for humans first, compilers second
  • Favor clarity over clever tricks
  • Keep line lengths reasonable and indentation consistent

2. Maintainability

  • Use meaningful names
  • Keep functions and classes small
  • Follow consistent patterns across files and folders

3. Predictability

  • Use the same structure other developers expect
  • Follow naming conventions (camelCase, snake_case, PascalCase)
  • Avoid reinventing patterns your project or community already solved

4. Shared formatting rules

  • Prettier for auto-formatting
  • ESLint for JavaScript/TypeScript
  • Pylint/Black for Python (if applicable)
  • SQL capitalization and indentation conventions

5. Documentation & comments

  • Write comments that explain WHY, not WHAT
  • Use docstrings (Python) or JSDoc/TSdoc for JS/TS
  • Comment complex queries in SQL

These principles apply to all languages across the practicum.


JavaScript / TypeScript

View JavaScript / TypeScript Standards

JavaScript and TypeScript are used across many practicum projects:
web apps, mobile apps (Expo), APIs, and class assignments.

Key Standards

  • Use ES Modules (import / export)
  • Prefer const and let instead of var
  • Use arrow functions for inline and callback code
  • Enforce consistent typing in TypeScript
  • Use async/await instead of .then()
  • Keep React/Expo components small and readable
  • Organize code by feature or module

Naming Conventions

  • camelCase for variables and functions
  • PascalCase for components and classes
  • SCREAMING_SNAKE_CASE for global constants

Recommended Tools

  • ESLint
  • Prettier
  • TypeScript compiler diagnostics

Read More:


Python

View Python Standards

Python is used for scripting, automation, data science, and backend components.

Key Standards

  • Follow PEP 8 style guidelines
  • Use 4-space indentation
  • Use snake_case for variables and functions
  • Use PascalCase for classes
  • Add docstrings using triple quotes
  • Keep modules focused and short
  • Use type hints (def add(x: int, y: int) -> int:)

Virtual Environments

Always create a virtual environment:

python -m venv venv

Read More:


SQL

View SQL Standards

SQL is used in data-related assignments, backend services, and analysis tasks.

Key Standards

  • Use UPPERCASE for SQL keywords (SELECT, JOIN, WHERE)
  • One clause per line for readability
  • Use table aliases (short, meaningful)
  • Prefer CTEs (WITH statements) for complex queries
  • Avoid SELECT * unless exploring or debugging
  • Indent subqueries consistently

Example Formatting

WITH active_users AS (
    SELECT id, name
    FROM users
    WHERE status = 'active'
)
SELECT *
FROM active_users
ORDER BY name;

Naming Conventions

  • snake_case for table and column names
  • avoid spaces or uppercase identifiers

Read More:


Additional Languages

View Additional Languages Standards

Some practicum tracks or elective projects may use additional languages such as:

  • Java / Kotlin (Android development)
  • Swift (iOS prototype work)
  • C# (Unity or desktop tooling)
  • Go (backend microservices)
  • C++ (systems or performance-based modules)

For each language, you should document:

What to Include

  • Structure of files and folders
  • Naming conventions
  • Indentation style
  • Common patterns or frameworks used
  • Required tools (linters, formatters, compilers)
  • Sample code formatting
  • Any project-specific rules established by the team

Clone this wiki locally