Coding Conventions (Mobiloan)

This standard is derived from current repo patterns and sets the forward standard.

1) Naming Convention Standard (Required)

Functions

  • Use camelCase for all function names.

  • Examples in repo:

    • getSASSADate (mobile/app.js)

    • updateInformalIncomes (mobile/origination_affordability.js)

    • saveDocument (mobile/document_capture.view.xml action targets)

Variables

  • Use camelCase for JS local/global variables in new code.

  • Existing repo uses mixed styles (snake_case + legacy suffixes like _boo).

  • Forward rule:

    • New JS vars: camelCase

    • Schema/view-bound data keys: keep existing names where required for compatibility.

Schema / field names

  • Use snake_case for model and field identifiers in schema.xml.

  • Evidence:

    • model name="affordability"

    • field name="gross_income", field name="other_accounts_expense" (schema.xml)

View params/vars (*.view.xml)

  • Follow existing Journey binding style with snake_case for bound names to match schema and existing JS bindings.

  • Evidence:

    • <param name="client_loans" ...>

    • <var name="gross_income" ...> (mobile/origination_affordability.view.xml)

Constants

  • Use UPPER_SNAKE_CASE for immutable constants introduced in JS modules.

  • If constant is config-driven, prefer reading via config('<key>') instead of hardcoding.

2) Function Design Rules

  • Keep functions focused on one concern (validation, mapping, persistence, UI updates).

  • Max guideline: ~60 lines before splitting into helper functions.

  • Avoid hidden side-effects; if mutating view.*, name function to reflect mutation.

  • For transformation logic, extract named helpers (do not bury in inline callbacks).

3) Data Handling Rules

  • Parse once, pass structured object forward (e.g., JSON.parse(view.session.client_json) pattern).

  • Null/empty handling must be explicit.

  • Numeric formatting must be centralized where possible (roundToTwo, etc.) instead of repeated ad-hoc rounding.

4) Error Handling Rules

  • No empty catch blocks.

  • User-actionable errors: show clear message + next action.

  • Non-actionable/logic errors: log with context (view/module, action, ids).

5) Compatibility Rules (Important)

  • Do not mass-rename existing snake_case bindings in live flows.

  • Any renaming/refactor touching schema fields or bindings must include migration and regression testing.

6) Evidence References

  • mobile/app.js

  • mobile/origination_affordability.js

  • mobile/origination_affordability.view.xml

  • mobile/document_capture.view.xml

  • schema.xml

Last updated