-
Notifications
You must be signed in to change notification settings - Fork 199
Code Standards
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 and weird qualities 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.
/mob/living/carbon/human
The above is a FULL typepath, it is preferred over:
mob
living
carbon
human
in addition to Typepaths, the placement of the block(s) of code is standardised also (However Byond can still compile if you ignore this, but Standards and rules are what separate order from chaos!)
~80% of the game's code is written with Full paths, and the code block indented in (written one "tab" under) the definition. (This cannot be ignored, byond will not compile the code if it's incorrectly indented)
Byond also allows procs and verbs to be defined with themselves Indented by one "tab" under the initial define of the object they are attached to.
Type path combinations (Indent numbers from the left of the file):
- (1)Full Type paths and code blocks indented by 1 -- This One is our favourite! 👍
- (2)Non/Indented paths with code indented by 2 -- A few sections of the "Old code" is written in this form, don't continue their tradition 👎
- (3)Full Type paths and code blocks indented by 2 -- Apparently this compiles, but it's ugly as sin 👎
- (4)Non/Indented paths with code indented by 1 -- This won't assign the code block to the path definition, which is functionally wrong! 👎
As special note is that if you alter a section of code (eg, fixing a bug, adding a feature) that is written
case (2), you are Heavily encouraged to alter it to case (1), It helps you and future coders!
mob
var/health
is preferred over:
mob
health
When defining variables, its 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 means human, or M to mean Mob, etc.
The rules of Typepaths and Variables are also true for Procs and Verbs.
A Proc's name should be an indication of its function.
If a proc counts the number of legs, its 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!
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.
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.
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
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.
This also applies to things which have a standardized way of being done but the standardized form is not used.
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.
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 or 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.