Following a standard of identifier naming conventions in your source code helps during maintenance, integration, and group collaborative projects.

When source code has been gaining dust for a few months and you need to go back to make a change, or someone new takes over your source code, its beneficial to have followed a recognized standard in your naming conventions. This way you know that “sName” is a string that's probably someone or something's name, and not have to dig through code to find out if it was “__NAME”, “name”, “Name”, or any one of the other derivitives.

Variables should note their appropriate data type at the beginning of their name, followed by intercapitalization (Hungarian notation). A table of naming prefixes appears below.

All Cerea scripts begin with C
next is type of script:

followed by a _g_ for generic, _m_ for module scripts or _tag_ where tag is builder tag for non generic scripts

followed by script type:(only for generic scripts):

Followed by actual name(all scripts)

so builder weby building a placeable script that does a special teleport, name could be:
cp_weby_telehome

Will have names like
cd_tag_more

with tag being the builder tag and more being the name/explanation of the dialog.

It is strongly recomended to use the form: cd_tag_area_unique where the area is the area of the NPC/thing using the convo

Placeables should have tag,resource name and template resref all as: cpl_tag_unique

You should set the classification correctly, see the classifications heading in this page.

It is strongly recomended to use the form: cpl_tag_area_unique where the area is the area where it is used.

All transition doors should have unique tags on the form d_tag_unique

You should set the classification correctly, see the classifications heading in this page for any doors in the palette.

It is strongly recomended to use the form: d_tag_area_unique where the area is the area where it is used.

all items should have tag,resource name and template resref all as: i_tag_unique or if it is a quest item it should have qi_tag_unique

You should set the classification correctly, see the classifications heading in this page.

for items the classification is the thing to try to make meaningfull. You should add | and your buildertag as minimum to the given ones, you can add undercategries under them, thus forexample all the keys for a given quest with many keyscould be in c-Quest|weby|keys|manykeyquest

NPC items should be under: c-NPCitems (these are the items worn only by NPCs/creatures and should have Base = -1) all kinds of keys should be in: c-Keys all generic quest items should be under c-Quest

The below categories should not contain any quest items or items without Price(and Base).

tools should be in: c-Tools
armors: c-Armor
boots: c-Boots
gloves c-Gloves
cloaks: c-Cloaks
potions: c-Potions
traps: c-Traps
jewelry: c-Jew
hats: c-Hats
clothing: c-Clothing
blunt weapons: c-Weapon-blunt
ranged weapons and ammo: c-Weapon-ranged
bladed weapons: c-Weapon-bladed

NPCs should be in a path c-npc-(mainareaname/groupname)
Generic ones:
c-npc-Banditpass
c-npc-Cerea
c-npc-Vesper (should definitely use subcategories here)
c-npc-NayeBay
c-npc-Gohem
c-npc-Greiburg
c-npc-Greywoods
c-npc-Dyoa
c-npc-OrcValley
c-npc-GoblinValley

Current group based:(if you make a npc group of some sort, feel free to add a new one like this for them)
c-npc-Bandits
c-npc-Barbarian
c-npc-Belwar
c-npc-Corsairs
c-npc-Darkelf
c-npc-Dwarf
c-npc-Gypsie
c-npc-Hobbit
c-npc-Monk
c-npc-Pirates
c-npc-Scavenger

Creatures should likely go to one of these: (again feel free to do subcategries)

c-Animals
c-Demons (and other planars)
c-Dragons
c-Elementals (also for elemental beings)
c-Ghosts (note that ghosts should have spirit override on and not be unlife)
c-Giants
c-Gnoll
c-Goblin
c-Kobolds
c-Lizardfolk
c-Orc
c-Wisps
c-Unlife-lesser (skeletons, zombies, ghouls, mummies and such “stupid unlife”)
c-Unlife-greater(vampires, Liches, spectres and other “smart unlife)

or a similary named category

Also there is the c-Quest category for creatures that might break things if spawned by DMs.. in the quest category is is defintely suggested to use c-Quest|buildertag|questname for organisation

A starting brace appears on the same line as if or such, so an “if” statement would be structured as follows:

            if (TRUE) { 
                 // ...
            }

Only a single statement should appear per line. An exception would be when readability is greatly enhanced, for example in a “switch” statement:

            switch (iCondition) {
                 case 1: sVariable = "one"; break;
                 case 2: sVariable = "two"; break;
                 case 3: sVariable = "three"; break; 
            }

Statements should be indented an appropriate number of levels according to the nested depth. So, an “if” statement in our void main would appear as follows:

           void main() {
                 if (TRUE) {
                      // ...
                 }
            }

(optional) Smart use of white space and carriage returns can help break up a large function call or nested function call, making it easier to make changes to and read.

           action aConvo = ActionStartConversation(
                 GetObjectByTag("SOME_TAG"),
                 "Hey you!",
                 FALSE
           );

In general, identifiers should be declared at the top of the function. This makes it easy to find the identifier's type and it's initial value. If an identifer is only used once, inside a small block, it can be declared at the point where it is used.

The names of functions should Capitalise the first letter of each word.

         int DoSomething(int nKills) {
                 return nKills - 9;
         }

Use “iCondition” (or ”!iCondition“) is used.

            int iTest = TRUE;
            // boolean test:
            if (iTest){
                 // ...
            }

Each script should have general purpose at top
each function should have its purpose and arguments and return values documented

Each major variable in the functions documented.
each major part of the function documented as to what it does(includes loops, calculation blocks and such)

Any additional information to help DMs and builders should be in { } in the name. Thus is is much metter to have: robber {ranged} and robber {melee} than just two “robber” entries that way the dm will know what of those to place close and what far..

should have the Mainarea:subarea type set as display name.