Skip to content
Atskadan edited this page Mar 25, 2014 · 17 revisions

This page is here to try and help you better your code so that it has a higher chance of getting into the Github repository and to help you understand some of the Quirky/weirdness of the Dream maker (DM) language.

DM is a language that has a lot of options that perform the same action, but some of them are preferred over others.

Typepaths

/mob/living/carbon/human

the above is a FULL typepath, it is preferred over:

mob
    living
        carbon
            human

Variables

mob
    var/health

is preferred over:

mob
    health

When defining variables, it's full typepath must be written out and the var/ prefix must be added. When Typecasting (Changing or working with the type of an object) single, capital letter variable names are allowed e.g.

var/mob/living/carbon/human/H

is perfectly acceptable and the majority of the time seeing a H in the code, you'll know it to mean Human, or M to mean Mob, etc.

Procs and Verbs

The rules of Typepaths and Variables are also true for Procs and Verbs. A Proc's name should be an indication of it's function. if a proc counts the number of legs it's name should reflect that

/mob/proc/return_num_of_legs()
The above makes more sense than say
/mob/proc/legs()

return_num_of_legs() is clearly something that Returns the Number of legs where as legs() could do anything related to legs!

: (colon) operator

The colon operator allows you to tell the DM compiler to "trust" you when it encounters a : A colon allows you to check a variable on something that, by default does not have that variable You would use a Colon here to tell the compiler that the object to the left of the colon WILL have the variable on the right of the colon when that section of code runs. This is useful for large scale work in a short ammount of time, but can cause bugs due to the compiler not checking for errors in that section of code due to the colon.

The colon operator is LAZY coding and a simple 2~ lines can fix it

e.g.

/obj/item
    var/value = 10

for(var/atom/moveable/AM in Chest.contents)
    AM:value += 10

Now, the /atom/moveable/AM covers Mobs, Objects, Anything that has the potential for Movement is a subtype of /atom/moveable (Note, full typepaths do NOT require you to write out the /atom/moveable part)

if an AM that was an /obj/item was passed through this code it's value would go up by ten. but what if the AM was a mob? Mobs don't have a value variable, DM would throw out an error. You can solve this issue like this:

/obj/item
    var/value = 10

for(var/atom/moveable/AM in Chest.contents)
    if(istype(AM, /obj/item))
        var/obj/item/I = AM
        I.value += 10

Now ONLY /obj/item will have their value increased by ten, because only they have the variable!
anything that isn't a /obj/item will not pass the istype() check.

Code Case

doesSomething(), DoesSomething() or does_something()?

the first is camelCase, the second is Pascal case and the third is underscore delimiter case. All of these are accepted but the majority is written in underscore delimiter case, so please try to use that where possible.

Code Readability

Don't be afraid to add blank lines where you feel the code is too cramped together.
Try not to write code results on the same line as a statement e.g.

If(X) return Y

Vs.

If(X)
    return Y

Snowflake code

The act of creating large complex code, that serves only one purpose, this is very much frowned upon.
Please try and make your code modular (useful for other things) as often as you can.

Copy paste (copy pasta)

If you're unsure on how to proceed with something, Ask for help, Do not just copy large chunks of code and attempt to alter them to your needs. if the section of code you copied is bugged or broken, then the copy is also, making it take much longer to get rid of the issues because they're in more than one place.

Code Commenting and Code Ownership

If your code's function is not obvious to someone with functional knowledge of how code works, or if it's just a particularly weird (But functional) way of doing things, make a comment explaining how and WHY you've done it the way you have. If the function of the code is clear to someone with reasonable knowledge of Dream Maker of programming in general then your comment is pointless. If the code says that "H is a human," then don't write a comment saying that H is a human. Placing your name on sections of code you've slightly modified is generally frowned upon, but if you've created the entire section of code yourself you may add your name to it as you see fit.

Clone this wiki locally