-
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
When writing a string in Byond/DM you have a list of built in text macros to apply to add unique things to your text string, some add icons into the text and some change the colour of the text and other nice things.
What were talking about here though, are the text ones \red \blue \green etc.
Don't use them. Just don't. Almost all of SS13's text that is not pure black uses a stylesheet specifically setup for SS13 so all text of the same "type" matches. These are used with HTML spans.
HTML Span quick course:
"<span class='NAME_OF_SPAN_CLASS'>your text here. some more text. maybe a little more</span>" with the text going inside the "s of byond strings (as shown)
the span classes are stored in stylesheet.dm
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.
There are a few files that we only want committing in special circumstances or we never want them committed, as it causes issues later down the line for other coders.
NTstation.dme:
This file should only be committed when Adding (ticking the file in DM) or Removing (Unticking the file in DM) files.
Eg:
You add a new mob, in it's own new file: example_mob.dm
This file doesn't already exist in the repository's version of NTstation.dme, but it does in your local version, you should commit the .dme
For extra information on the .dme, /tg/station Coder Cheridan has a thread up on the Joint Forums:
http://tgstation13.org/phpBB/viewtopic.php?f=5&t=321
NTstation.int:
This file changes to reflect the last thing you had open in DM, it's so you can quickly get back to your work without having to remember the files you were working on, just leave them open and close DM itself and Voila, they'll all be open for you when you open DM. The problem is, It's almost 100% likely that two coders .int files will NOT match, which causes Github to view it as a change, which causes overwrite issues when committing. you cannot prevent this file from changing, however you can simply not commit it (Unticking it in the Commit window)
DO NOT WRITE ANY MORE TOPIC PROCS
Currently being written code is fine, But There will be a lockdown on Topic procs soon.
Topic procs are the important code keeping the Black/grey Popup boxes working. However they hold deep
within their code MASSIVE EXLPOITS. spawning anything /obj for free, for example.
When the Topic lockdown happens There will be a large incentive to fix all the current Topic procs