When coding in LPC or in any other programming language you need to have some kind of standard. This is to allow other programmers to look and understand your code, and most important of all to set up a structure in the coding language that is general and easy to follow.

General guidelines to follow:

• Indenting code
• Type declaration
• Structure
• Conventions
• Rules for settings certain properties

Indenting code

This is one of the most important things when coding and still people never seem to understand that. To make the code easy to read and understand indenting the code is a must.

This is an example of how you could indent your code.

if (str == "get") {
    if (this_player()->query_level() > STUDENT) {
        write("this is a test\n");
        return 1;
    }
}

if(str=="get"){
if(this_player()->query_level()>STUDENT){
write("this is a test\n");
return 1;
}
}

Generally indent four spaces (use spaces, don't use tabs) and put closing brackets on extra lines. If you have short if- while- or for-clauses (or anything else) avoid putting all code in one line.

if (!param)
    return 1;

for (j=1;j<10;j++) 
    do_something(j);

if (!param) return 1;

for (j=1;j<10;j++) do_something(j);

Type declaration

Type declarations is a neccessary evil in the coding. Fortunately LPC is not as strict on this as, for example, C. There are different kinds of type declarations depending on what you're declaring.
Generally speaken each function type should be declared to clarify the type of returned values.

An example may be:

int
query_value() {
    int a;

    // some code

    return a;
}

Structure

The main purpose for a structure in your code is to make the code readable for everyone and to make it easier when looking for errors. Always try to keep to a given structure, it might feel strange in the beginning but you will soon get used to it and see the advantages of having one.

Structure rules (order of code) for standard LPC objects

1. inherits
2. includes
3. defines
4. global variables
5. create()
6. reset()
7. init()
8. local functions

Conventions

When coding in a mud together with numerous other programmers it is not only convenient but very useful to stick to certain standards. These standards are not strict coding rules, rather 'traditional' ways on 'how to do things'. Lots of those have been used many times in numerous LPC objects and once you got used to them you will find it much easier to follow code by other programmers who use the same 'standards' (and it will improve your code, too).

Some examples:

#define TWENTY 20
// Use upper case for defines!

#include "defines.h"
/* Include the quasi-standard define file 
   provided in the crashcourse, it contains defines that 
   are frequently used!
*/

#define TREASURE "/d/exampleregion/obj/goldscepter"
.
.
.
treasure_obj=clone_object(TREASURE);
/* Do not hard code file and path names! 
   Have defines for all filenames (except all file and 
   path names used in the create function, thus appearing 
   early in the code file)
*/

#define FUNC "/d/exampleregion/obj/goldscepter_func"
.
.
.
add_trigger("melt",(:call_other,FUNC,"melt_scepter":));
/* Name your define for the function file 
   'FUNC'! It simplifies the debugging process (anyone 
   will know to look for the function file whenever the 
   define FUNC appears in the code)
*/

Rules for settings certain properties

Some properties cause strange behaviour or looks if set wrong. So remember the following guidelines:

/* Never use capitals in short descriptions */

set_short("a mage");

/* Never use capitals in names, except the "names" are REALLY names */

set_name("mage");

  - but -

set_name("Hilarious");

The crashcourse files may serve as examples for the guidelines above. Since there have been used numerous different layouts and conventions during the past years I would recommend only to use the conventions/rules described in this document and given as examples in the crashcourse. Although it may take some time to get used to these recommendations you will find it much easier once everyone uses them (for one reason it will ease the work of the QC Arches and last but not least yourself when looking for errors).