Skip to content
GitHubLinkedIn

Coding guidelines

These guidelines are defaults for Thinkwise + SQL Server projects. Follow them unless you have a clear reason not to — and document exceptions.

  • One rule, one home: avoid duplicating the same rule in multiple concepts.
  • Keep concepts thin: UI concepts call into reusable logic instead of embedding business rules.
  • Prefer clear models over clever code: the model should express the concept unambiguously.
  • Optimize for change: strong defaults beat one-off exceptions.
NeedPreferAvoid
Reusable value / label / statusFunction (scalar or inlineable)Copy-paste expressions
Reusable base queryInline table-valued function (TVF) or viewRepeating joins across views
Side effects (insert/update/send)ProcedureHiding writes in views
UI-only behaviorLayouts, actions, report templatesBusiness rules in UI
GuardrailsValidations, constraints, prefilters“Magic” behavior without rules
  • If you’re copy-pasting logic, extract it. Use Reusable functions and views as the default pattern.
  • Prefer composing multiple small functions over building one mega-function.
  • Keep integrations and side effects explicit (procedures), and keep reads composable (views/TVFs).
  • Use lowercase SQL keywords.
  • Prefer leading commas in multi-line select lists.
  • Avoid select *; list columns explicitly.
  • Avoid magic numbers; use lookup tables/domains and named values.
  • Use -- comments to explain why, not what.
select
    c.customer_id
  , c.name
  , dbo.fn_customer_status(c.status_code) as status
from customer c
where c.active = 1
  • Run impact analysis before changing shared functions/procedures.
  • Keep deployments safe to re-apply (idempotent where possible).
  • Integrate early; validate core flows with real-ish data.
  • For performance-sensitive changes, check the execution plan in context (views/reports).