Accepted Conventions

To improve code readability and ensure compatibility between modules developed by different teams, we strongly recommend following these naming conventions.

File Names

Root scripts and HTML templates — lowercase, words separated by underscores:

index.php
page_catalog.php
main.htm
page_404.htm
item_product.htm

Modular scripts follow a three-part naming scheme, separated by underscores:

{company}_{group}_{purpose}.php

Examples:

melbis_base_page.php       — base page router
melbis_store_card.php      — product card
melbis_cataloge.php        — catalog
melbis_inc_logic.php       — business logic library
kasdim_block_slider.php    — slider (kasdim project)
kasdim_client_auth.php     — client authentication

Each modular script has a configuration file with the same name and a .json extension:

melbis_store_card.php
melbis_store_card.json

Editing .json files manually is not recommended — all module parameters can be conveniently set directly in the “Development Environment” window, in the right panel next to the code editor. This is described in detail in the “Modular Scripts” section.

Module Groups

The group in a module’s name carries semantic meaning and determines how the module is displayed in the “Development Environment” tree. Only one group name is reserved — inc (also accepted: include or an empty value). Modules with this group are displayed in the inc folder and act as libraries: they cannot have HTML templates, and the parser does not call them directly — their functions are used by other modules.

All other group names (base, store, cataloge, basket, client, block, cron, and any others) are defined by you based on your project’s architecture. A group is simply a way to organize modules in the file tree.

melbis_inc_logic.php       — library (inc group, no templates)
melbis_inc_callback.php    — library
melbis_base_page.php       — regular module (base group)
melbis_store_card.php      — regular module (store group)
kasdim_block_slider.php    — regular module (block group)

Functions in Modular Scripts

Each regular module contains a main function — its name exactly matches the module’s filename written in uppercase. This is the function the parser calls:

// File: melbis_store_card.php
function MELBIS_STORE_CARD($mVars)
{
    ...
}

The exception is library modules in the inc group. The parser does not call them, so they have no main function. Instead, they contain a set of helper functions that are explicitly called from other modules.

Helper functions within the same module are named with the main function’s name as a prefix:

function MELBIS_STORE_CARD_price($mTpl, $mId)
{
    ...
}

function MELBIS_STORE_CARD_features($mTpl, $mId)
{
    ...
}

This approach guarantees unique function names in PHP’s global namespace and makes it immediately clear which module any given function belongs to.

Functions in library modules (inc) follow the same naming scheme — prefixed with the library name:

// File: melbis_inc_logic.php
function MELBIS_INC_LOGIC_order_create(...)  { ... }
function MELBIS_INC_LOGIC_order_calc(...)    { ... }
function MELBIS_INC_LOGIC_order_edit(...)    { ... }

Variables in PHP Scripts

Variable Type Rule Example
Function input parameters Start with $m, followed by camelCase $mVars, $mTopicId, $mTpl
Local variables Lowercase, words separated by _ $id, $item_count, $command
PHP constants Uppercase, words separated by _ MELBIS_CACHE, MELBIS_LANG

In a module’s main function, the input parameter array is conventionally named $mVars.

Keys in HTML Templates

All template engine keys are written in uppercase, with words separated by underscores:

{TITLE}
{PAGE_NAME}
{PRODUCT:PRICE_OLD}
{#ITEMS}
    <a href="?id={ID}">{NAME|html}</a>
{ITEMS#}