Coding Standards - Revision history

Imsynthex: "/tg/station" replaced with "BeeStation" (because this page was copied from tg)

2023-03-11T22:01:45Z

"/tg/station" replaced with "BeeStation" (because this page was copied from tg)

← Older revision		Revision as of 22:01, 11 March 2023
Line 1:		Line 1:
	=Specification=		=Specification=

	You are expected to follow these specifications in order to make everyone's lives easier, it will also save you and us time, with having to make the changes and us having to tell you what to change. Thank you for reading this section.		You are expected to follow these specifications in order to make everyone's lives easier, it will also save you and us time, with having to make the changes and us having to tell you what to change. Thank you for reading this section.

	* As BYOND's Dream Maker is an object oriented language, code must be object oriented when possible in order to be more flexible when adding content to it. If you are unfamiliar with this concept, it is highly recommended you look it up.		* As BYOND's Dream Maker is an object oriented language, code must be object oriented when possible in order to be more flexible when adding content to it. If you are unfamiliar with this concept, it is highly recommended you look it up.

Line 8:		Line 6:

	* It is rarely allowed to put type paths in a text format, as there are no compile errors if the type path no longer exists. Here is an example:		* It is rarely allowed to put type paths in a text format, as there are no compile errors if the type path no longer exists. Here is an example:

	<pre>		<pre>
	//Good		//Good
Line 16:		Line 13:
	var/path_type = "/obj/item/weapon/baseball_bat"		var/path_type = "/obj/item/weapon/baseball_bat"
	</pre>		</pre>

	* You must use tabs to indent your code, NOT SPACES.		* You must use tabs to indent your code, NOT SPACES.

	* Hacky code, such as adding specific checks, is highly discouraged and only allowed when there is no other option. You can avoid hacky code by using object oriented methodologies, such as overriding a function (called procs in DM) or sectioning code into functions and then overriding them as required.		* Hacky code, such as adding specific checks, is highly discouraged and only allowed when there is no other option. You can avoid hacky code by using object oriented methodologies, such as overriding a function (called procs in DM) or sectioning code into functions and then overriding them as required.

	* Duplicated code is 99% of the time never allowed. Copying code from one place to another maybe suitable for small short time projects but ~~/tg/station~~ focuses on the long term and thus discourages this. Instead you can use object orientation, or simply placing repeated code in a function, to obey this specification easily.		* Duplicated code is 99% of the time never allowed. Copying code from one place to another maybe suitable for small short time projects but BeeStation focuses on the long term and thus discourages this. Instead you can use object orientation, or simply placing repeated code in a function, to obey this specification easily.

	* Code should be modular where possible, if you are working on a new class then it is best if you put it in a new file.		* Code should be modular where possible, if you are working on a new class then it is best if you put it in a new file.
Line 30:		Line 26:

	* Follow the stylesheet. Changing formatting with \red or other tags is not allowed. You must use [[Text Formatting\|span classes]], which are defined in interface/stylesheet.dm.		* Follow the stylesheet. Changing formatting with \red or other tags is not allowed. You must use [[Text Formatting\|span classes]], which are defined in interface/stylesheet.dm.


	[[Category:Game Resources]] [[Category:Guides]]		[[Category:Game Resources]] [[Category:Guides]]
	{{Contribution guides}}		{{Contribution guides}}

imported>LiamLime: /* Specification */

2015-10-04T04:45:32Z

Specification

← Older revision		Revision as of 04:45, 4 October 2015
Line 29:		Line 29:
	* You are expected to help maintain the code that you add, meaning if there is a problem then you are likely to be approached in order to fix any issues, runtimes or bugs.		* You are expected to help maintain the code that you add, meaning if there is a problem then you are likely to be approached in order to fix any issues, runtimes or bugs.

	* Follow the stylesheet. Changing formatting with \red or other tags is not allowed. You must use span classes, which are defined in interface/stylesheet.dm.		* Follow the stylesheet. Changing formatting with \red or other tags is not allowed. You must use [[Text Formatting\|span classes]], which are defined in interface/stylesheet.dm.


	[[Category:Game Resources]] [[Category:Guides]]		[[Category:Game Resources]] [[Category:Guides]]
	{{Contribution guides}}		{{Contribution guides}}

imported>MisterPerson: Added the colons are ok exception for expensive stuff like the lighting subsystem

2015-01-15T16:39:46Z

Added the colons are ok exception for expensive stuff like the lighting subsystem

← Older revision		Revision as of 16:39, 15 January 2015
Line 5:		Line 5:
	* As BYOND's Dream Maker is an object oriented language, code must be object oriented when possible in order to be more flexible when adding content to it. If you are unfamiliar with this concept, it is highly recommended you look it up.		* As BYOND's Dream Maker is an object oriented language, code must be object oriented when possible in order to be more flexible when adding content to it. If you are unfamiliar with this concept, it is highly recommended you look it up.

	* You must not use colons to override safety checks on an object's variable/function, instead of using proper type casting.		* You must not use colons to override safety checks on an object's variable/function, instead of using proper type casting, unless the code in question is a known resource hog.

	* It is rarely allowed to put type paths in a text format, as there are no compile errors if the type path no longer exists. Here is an example:		* It is rarely allowed to put type paths in a text format, as there are no compile errors if the type path no longer exists. Here is an example:

imported>MisterPerson: Removed absolute pathing requirement

2015-01-10T15:18:53Z

Removed absolute pathing requirement

← Older revision		Revision as of 15:18, 10 January 2015
Line 4:		Line 4:

	* As BYOND's Dream Maker is an object oriented language, code must be object oriented when possible in order to be more flexible when adding content to it. If you are unfamiliar with this concept, it is highly recommended you look it up.		* As BYOND's Dream Maker is an object oriented language, code must be object oriented when possible in order to be more flexible when adding content to it. If you are unfamiliar with this concept, it is highly recommended you look it up.

	* You must write BYOND code with absolute pathing, like so:

	~~<pre>~~

	~~/obj/item/weapon/baseball_bat~~
	~~name = "baseball bat"~~
	~~desc = "A baseball bat."~~
	~~var/wooden = 1~~

	~~/obj/item/weapon/baseball_bat/examine()~~
	~~if(wooden)~~
	~~desc = "A wooden baseball bat."~~
	~~else~~
	~~desc = "A metal baseball bat."~~
	~~..()~~

	~~</pre>~~

	* You must not use colons to override safety checks on an object's variable/function, instead of using proper type casting.		* You must not use colons to override safety checks on an object's variable/function, instead of using proper type casting.

imported>Rockdtben: /* Specification */

2014-06-03T13:57:44Z

Specification

← Older revision		Revision as of 13:57, 3 June 2014
Line 1:		Line 1:
	=Specification=		=Specification=

	~~As mentioned before, you~~ are expected to follow these specifications in order to make everyone's lives easier, it will also save you and us time, with having to make the changes and us having to tell you what to change. Thank you for reading this section.		You are expected to follow these specifications in order to make everyone's lives easier, it will also save you and us time, with having to make the changes and us having to tell you what to change. Thank you for reading this section.

	* As BYOND's Dream Maker is an object oriented language, code must be object oriented when possible in order to be more flexible when adding content to it. If you are unfamiliar with this concept, it is highly recommended you look it up.		* As BYOND's Dream Maker is an object oriented language, code must be object oriented when possible in order to be more flexible when adding content to it. If you are unfamiliar with this concept, it is highly recommended you look it up.

imported>Rockdtben at 13:52, 3 June 2014

2014-06-03T13:52:17Z

← Older revision		Revision as of 13:52, 3 June 2014
Line 48:		Line 48:

	* Follow the stylesheet. Changing formatting with \red or other tags is not allowed. You must use span classes, which are defined in interface/stylesheet.dm.		* Follow the stylesheet. Changing formatting with \red or other tags is not allowed. You must use span classes, which are defined in interface/stylesheet.dm.


	[[Category:Game Resources]] [[Category:Guides]]		[[Category:Game Resources]] [[Category:Guides]]
	{{Contribution guides}}		{{Contribution guides}}

imported>Rockdtben at 13:52, 3 June 2014

2014-06-03T13:52:06Z

← Older revision		Revision as of 13:52, 3 June 2014
Line 48:		Line 48:

	* Follow the stylesheet. Changing formatting with \red or other tags is not allowed. You must use span classes, which are defined in interface/stylesheet.dm.		* Follow the stylesheet. Changing formatting with \red or other tags is not allowed. You must use span classes, which are defined in interface/stylesheet.dm.

			[[Category:Game Resources]] [[Category:Guides]]
			{{Contribution guides}}

imported>Rockdtben at 13:34, 3 June 2014

2014-06-03T13:34:52Z

← Older revision		Revision as of 13:34, 3 June 2014
Line 46:		Line 46:

	* You are expected to help maintain the code that you add, meaning if there is a problem then you are likely to be approached in order to fix any issues, runtimes or bugs.		* You are expected to help maintain the code that you add, meaning if there is a problem then you are likely to be approached in order to fix any issues, runtimes or bugs.

			* Follow the stylesheet. Changing formatting with \red or other tags is not allowed. You must use span classes, which are defined in interface/stylesheet.dm.

imported>Rockdtben: Created page with "=Specification= As mentioned before, you are expected to follow these specifications in order to make everyone's lives easier, it will also save you and us time, with having ..."

2014-06-03T13:27:54Z

Created page with "=Specification= As mentioned before, you are expected to follow these specifications in order to make everyone's lives easier, it will also save you and us time, with having ..."

New page

=Specification=

As mentioned before, you are expected to follow these specifications in order to make everyone's lives easier, it will also save you and us time, with having to make the changes and us having to tell you what to change. Thank you for reading this section.

* As BYOND's Dream Maker is an object oriented language, code must be object oriented when possible in order to be more flexible when adding content to it. If you are unfamiliar with this concept, it is highly recommended you look it up.

* You must write BYOND code with absolute pathing, like so:

<pre>

/obj/item/weapon/baseball_bat
name = "baseball bat"
desc = "A baseball bat."
var/wooden = 1

/obj/item/weapon/baseball_bat/examine()
if(wooden)
desc = "A wooden baseball bat."
else
desc = "A metal baseball bat."
..()

</pre>

* You must not use colons to override safety checks on an object's variable/function, instead of using proper type casting.

* It is rarely allowed to put type paths in a text format, as there are no compile errors if the type path no longer exists. Here is an example:

<pre>
//Good
var/path_type = /obj/item/weapon/baseball_bat

//Bad
var/path_type = "/obj/item/weapon/baseball_bat"
</pre>

* You must use tabs to indent your code, NOT SPACES.

* Hacky code, such as adding specific checks, is highly discouraged and only allowed when there is no other option. You can avoid hacky code by using object oriented methodologies, such as overriding a function (called procs in DM) or sectioning code into functions and then overriding them as required.

* Duplicated code is 99% of the time never allowed. Copying code from one place to another maybe suitable for small short time projects but /tg/station focuses on the long term and thus discourages this. Instead you can use object orientation, or simply placing repeated code in a function, to obey this specification easily.

* Code should be modular where possible, if you are working on a new class then it is best if you put it in a new file.

* Bloated code may be necessary to add a certain feature, which means there has to be a judgement over whether the feature is worth having or not. You can help make this decision easier by making sure your code is modular.

* You are expected to help maintain the code that you add, meaning if there is a problem then you are likely to be approached in order to fix any issues, runtimes or bugs.