Code Review Checklist

This page is a practical checklist for reviewing code in Oidis projects. Use it before submitting changes or when reviewing a colleague's work. Each item links to the full rule in the Conventions section.

Quick check — run the linter

Most formatting rules are enforced automatically. Run the linter before committing:

oidis test lint

The pre-commit hook runs this automatically. If the commit is rejected, the linter output tells you exactly what to fix.

What the linter catches

These rules are enforced by oidis test lint — the linter will reject your code if violated:

Rule	Example violation	Correct form
Space before and after type colon	name: string	name : string
Double quotes for strings	'hello'	"hello"
Semicolons required	const x = 1	const x = 1;
No trailing commas	{ a: 1, b: 2, }	{ a: 1, b: 2 }
Member ordering (static → decorated → instance → accessors → constructor → methods)	Methods before fields	Fields before methods
File header present	Missing copyright	BSD-3-Clause header
Import extensions	import { Foo } from "./Foo"	import { Foo } from "./Foo.js"

Full formatting rules: TypeScript Formatting | File Headers

What the linter does NOT catch

These rules require manual review:

Naming

Element	Convention	Wrong	Right
Public methods	PascalCase	fetchData()	FetchData()
Private/protected methods	camelCase	FetchData()	fetchData()
Getters/setters	get/set + camelCase	GetName()	getName()
Method parameters	$ prefix	name	$name
Enum values	UPPER_CASE	active	ACTIVE
Classes	PascalCase	userModel	UserModel

Full rules: Naming Conventions

Framework usage

Instead of...	Use...	Why
document.createElement()	new Button(), new Container()	Framework OOP pattern for interactive elements
innerHTML for interactive content	.AddChild(), .SetContent()	Event binding, lifecycle management
console.log()	LogIt utility	Structured logging with levels and context
JSON.parse() / JSON.stringify()	JsonUtils	Error handling, JSONP support
Raw string manipulation	StringUtils	Null-safe, tested utilities
Manual type checking	ObjectValidator	Declarative validation

Full rules: Vanilla vs Framework

tip

Raw HTML via innerHtml() is acceptable for static Bootstrap layout (containers, rows, columns). Use framework OOP for anything interactive.

Documentation

• Public APIs must have JSDoc with @param, @returns, @deprecated tags
• All code must be in English — names, comments, JSDoc, logs, error messages
• Exception: user-facing hardcoded text may use the app's target language when no localization system is in place

Full rules: JSDoc

Review workflow

1. Author runs oidis test lint and fixes all violations
2. Author self-reviews against the manual checks above
3. Reviewer focuses on naming, framework usage, and documentation (the linter handles formatting)
4. Reviewer checks that new public APIs have JSDoc and that code uses framework utilities over vanilla equivalents

---

See also: Conventions Overview | TypeScript Formatting | Naming Conventions | Vanilla vs Framework