Sandman's code convention - Revision history

Sandman: /* Indenting */

2008-04-06T10:57:15Z

Indenting

←Older revision		Revision as of 10:57, 6 April 2008
Line 2:		Line 2:

	== Indenting ==		== Indenting ==
-	Indenting is done with four spaces or a tab of four spaces wide. The [[Program]]-, [[Process]]-, [[Function]]-, [[Global]]-, [[Local]]-, [[Public]]-, [[Private]]- and [[Begin]]-statements are always completely to the left, with no indentation at all. Declaration of variables are indented once. Precompiler-statements are generally to the left as well, but for small blocks they can be indented. The code between Begin and [[End]] statements are indented once at first.	+	Indenting is done with four spaces or a tab of four spaces wide. The [[Program]]-, [[Process]]-, [[Function]]-, [[Global]]-, [[Local]]-, [[Public]]-, [[Private]]- and [[Begin]]-statements are always completely to the left, with no indentation at all. The exception to this is inside the [[Declare]] block, in which case [[Public]] and [[Private]] are indented once. Declaration of variables are indented once. Precompiler-statements are generally to the left as well, but for small blocks they can be indented. The code between Begin and [[End]] statements are indented once at first.

	See the example for a visual representation.		See the example for a visual representation.

Sandman: /* Example */

2008-04-06T10:56:40Z

Example

←Older revision		Revision as of 10:56, 6 April 2008
Line 59:		Line 59:
	Const		Const
	KEY_TARGET = _a;		KEY_TARGET = _a;
		+	End
	Global		Global
	int key_pressed;		int key_pressed;
		+	End
		+
		+	Process Main()
	Begin		Begin
	keyInput(KEY_TARGET,&key_pressed);		keyInput(KEY_TARGET,&key_pressed);

Sandman at 00:53, 13 May 2007

2007-05-13T00:53:58Z

←Older revision		Revision as of 00:53, 13 May 2007
Line 17:		Line 17:
	Variables are written in lower case, whether they are private, local or global. When defining a [[struct]], the name of the struct start with a capital and is accessed with a capital as well. For example "Mouse.left". "Mouse" is a struct, so it's typed with a capital and "left" is a normal variable, so it's in lower case.		Variables are written in lower case, whether they are private, local or global. When defining a [[struct]], the name of the struct start with a capital and is accessed with a capital as well. For example "Mouse.left". "Mouse" is a struct, so it's typed with a capital and "left" is a normal variable, so it's in lower case.

-	The datatype of the variables are always noted when declaring them, even when they're integers.	+	The [[datatype]] of the variables are always noted when declaring them, even when they're integers.

	Like: [[ctype]], [[graph_mode]], [[Scroll]]		Like: [[ctype]], [[graph_mode]], [[Scroll]]
Line 43:		Line 43:
	Functions are written in both cases. Defining a function or process goes like so:		Functions are written in both cases. Defining a function or process goes like so:
	<pre>keyInput( int keycode, int pointer status)</pre>		<pre>keyInput( int keycode, int pointer status)</pre>
-	The "(" comes directly after the function name, followed by a " " (space) and the datatype of the first parameter, before a space and the name of the first parameter. Then a "," and the whole thing starts again, ending with a ")".	+	The "(" comes directly after the function name, followed by a " " (space) and the [[datatype]] of the first parameter, before a space and the name of the first parameter. Then a "," and the whole thing starts again, ending with a ")".

	While a process is declared using [[Process]] in all versions of Fenix, it is not so simple with functions. When the [[Function]] statement wasn't used, the functions were to be defined by putting the return type in front of it, which mostly was an integer. Later, when the Function statement came effective, that statement was to be used before the function name instead of the return type.		While a process is declared using [[Process]] in all versions of Fenix, it is not so simple with functions. When the [[Function]] statement wasn't used, the functions were to be defined by putting the return type in front of it, which mostly was an integer. Later, when the Function statement came effective, that statement was to be used before the function name instead of the return type.

Sandman at 00:26, 9 May 2007

2007-05-09T00:26:25Z

←Older revision		Revision as of 00:26, 9 May 2007
Line 2:		Line 2:

	== Indenting ==		== Indenting ==
-	Indenting is done with four spaces or a tab of four spaces wide. The [[Program]]-, [[Process]]-, [[Global]]-, [[Local]]-, [[Private]]- and [[Begin]]-statements are always completely to the left, with no indentation at all. Declaration of variables are indented once. Precompiler-statements are generally to the left as well, but for small blocks they can be indented. The code between Begin and [[End]] statements are indented once at first.	+	Indenting is done with four spaces or a tab of four spaces wide. The [[Program]]-, [[Process]]-, [[Function]]-, [[Global]]-, [[Local]]-, [[Public]]-, [[Private]]- and [[Begin]]-statements are always completely to the left, with no indentation at all. Declaration of variables are indented once. Precompiler-statements are generally to the left as well, but for small blocks they can be indented. The code between Begin and [[End]] statements are indented once at first.

	See the example for a visual representation.		See the example for a visual representation.

Sandman: coding -> code

2007-05-08T23:47:55Z

coding -> code

←Older revision		Revision as of 23:47, 8 May 2007
Line 1:		Line 1:
-	Fenix ~~Coding~~ Convention by Sandman (work in progress)	+	Fenix Code Convention by Sandman (work in progress)

	== Indenting ==		== Indenting ==

Sandman: /* Defines */ pre tag

2007-05-08T23:45:43Z

Defines - pre tag

←Older revision		Revision as of 23:45, 8 May 2007
Line 31:		Line 31:
	// Place the file's code here.		// Place the file's code here.
	#endif		#endif
-	<pre>	+	</pre>
	This is done in [[Network.dll]]:		This is done in [[Network.dll]]:
	<pre>		<pre>

Sandman: Sandman's coding convention moved to Sandman's code convention

2007-05-08T23:41:37Z

Sandman's coding convention moved to Sandman's code convention

←Older revision

Revision as of 23:41, 8 May 2007

Sandman: pre tag

2007-05-08T20:56:57Z

pre tag

←Older revision		Revision as of 20:56, 8 May 2007
Line 38:		Line 38:
	// Network.fh code		// Network.fh code
	#endif		#endif
-	<pre>	+	</pre>

	== Functions and Processes ==		== Functions and Processes ==

Sandman at 10:39, 8 May 2007

2007-05-08T10:39:00Z

←Older revision		Revision as of 10:39, 8 May 2007
Line 1:		Line 1:
	Fenix Coding Convention by Sandman (work in progress)		Fenix Coding Convention by Sandman (work in progress)
		+
		+	== Indenting ==
		+	Indenting is done with four spaces or a tab of four spaces wide. The [[Program]]-, [[Process]]-, [[Global]]-, [[Local]]-, [[Private]]- and [[Begin]]-statements are always completely to the left, with no indentation at all. Declaration of variables are indented once. Precompiler-statements are generally to the left as well, but for small blocks they can be indented. The code between Begin and [[End]] statements are indented once at first.
		+
		+	See the example for a visual representation.

	== Names ==		== Names ==
	Separating sections of a name is done by use of the "_" character. An easy example is the [[function]] [[NET_Init]]. "NET" is a different section than "Init", because the first denotes the origin of the function and the second denotes what the function does. Another example is [[NET_ERROR_CONNECTING]]: "NET" denotes the origin, "ERROR" denotes a more precise origin (an error) and "CONNECTING" denotes what the constant means (error while connecting).		Separating sections of a name is done by use of the "_" character. An easy example is the [[function]] [[NET_Init]]. "NET" is a different section than "Init", because the first denotes the origin of the function and the second denotes what the function does. Another example is [[NET_ERROR_CONNECTING]]: "NET" denotes the origin, "ERROR" denotes a more precise origin (an error) and "CONNECTING" denotes what the constant means (error while connecting).
-	Separating some words does not need a "_", but simple can be put together, making the first character of the second word a capitol. For example [[NET_SendVar]]. Here we see the section "NET" and the section "SendVar", which is further cut down to "Send" and "Var"

	== Constants ==		== Constants ==
-	Constants are written in ~~ALL CAPS~~.	+	Constants are written in all upper case.

	Like: [[C_SCREEN]], [[NET_ERROR_CONNECTING]], [[B_ALPHA]]		Like: [[C_SCREEN]], [[NET_ERROR_CONNECTING]], [[B_ALPHA]]

	== Variables ==		== Variables ==
-	Variables are written in ~~low caps~~, whether they are private, local or global.	+	Variables are written in lower case, whether they are private, local or global. When defining a [[struct]], the name of the struct start with a capital and is accessed with a capital as well. For example "Mouse.left". "Mouse" is a struct, so it's typed with a capital and "left" is a normal variable, so it's in lower case.

-	Like: [[ctype]], [[graph_mode]]	+	The datatype of the variables are always noted when declaring them, even when they're integers.
		+
		+	Like: [[ctype]], [[graph_mode]], [[Scroll]]
		+
		+	== Types ==
		+	Types are written in both case, but mostly in lower case. A type starts with a "_", for example, [[Network.dll]] has the type "_IPaddress".
		+
		+	== Defines ==
		+	Defines are, like constants, written in all upper case. On top of this, the following way of defining can be used, to prevent multiple includes of the same file. Note the "__".
		+	<pre>
		+	#ifndef __MYFILENAME_MYFILEEXTENSION
		+	#define __MYFILENAME_MYFILEEXTENSION
		+	// Place the file's code here.
		+	#endif
		+	<pre>
		+	This is done in [[Network.dll]]:
		+	<pre>
		+	#ifndef __NETWORK_FH
		+	#define __NETWORK_FH
		+	// Network.fh code
		+	#endif
		+	<pre>

	== Functions and Processes ==		== Functions and Processes ==
-	Functions are written in ~~low caps as well~~. Defining a function or process goes like so:	+	Functions are written in both cases. Defining a function or process goes like so:
-	<pre>~~key_input~~( int keycode, int pointer status)</pre>	+	<pre>keyInput( int keycode, int pointer status)</pre>
	The "(" comes directly after the function name, followed by a " " (space) and the datatype of the first parameter, before a space and the name of the first parameter. Then a "," and the whole thing starts again, ending with a ")".		The "(" comes directly after the function name, followed by a " " (space) and the datatype of the first parameter, before a space and the name of the first parameter. Then a "," and the whole thing starts again, ending with a ")".

-	Calling a function or process isn't bound to any rules, because in many cases, the clarity of the code is different, even though the code is written the same. So just best suit the layout of the code to the environment. In general though, a good look is created by the use of a " " (space) before every ~~parameter~~.	+	While a process is declared using [[Process]] in all versions of Fenix, it is not so simple with functions. When the [[Function]] statement wasn't used, the functions were to be defined by putting the return type in front of it, which mostly was an integer. Later, when the Function statement came effective, that statement was to be used before the function name instead of the return type.
		+
		+	For naming a function or process, separating some words with a "_" is not needed, but can simply be put together, making the first character of the second word a capital. For example [[NET_SendVar]]. Here we see the section "NET" and the section "SendVar", which is further cut down to "Send" and "Var".
		+	First sections denoting the origin are typed in capitals, while the other sections only begin with a capital.
		+
		+	Calling a function or process isn't bound to any rules, because in many cases, the clarity of the code is different, even though the code is written the same. So just best suit the layout of the code to the environment. In general though, a good look is created by the use of a " " (space) before every [[argument]].

	== Control-flow keywords ==		== Control-flow keywords ==
-	Control-flow keywords can be typed in two ways. The difference denotes the importance of the statement. The important control-flow statements are typed with the first character a ~~capitol~~, while the less important ones are only ~~low caps~~.	+	Control-flow keywords can be typed in two ways. The difference denotes the importance of the statement. The important control-flow statements are typed with the first character a capital, while the less important ones are only lower case.

	== Example ==		== Example ==
	<pre>		<pre>
		+	Const
		+	KEY_TARGET = _a;
		+	Global
		+	int key_pressed;
	Begin		Begin
-	~~key_input~~(_a);	+	keyInput(KEY_TARGET,&key_pressed);
	Loop		Loop
		+	if(key_pressed)
		+	say("Key pressed!");
		+	end
	frame;		frame;
	End		End
	End		End

-	Process ~~key_input~~( int keycode, int pointer status)	+	Process keyInput( int keycode, int pointer status)
	Begin		Begin
	Loop		Loop
Line 45:		Line 82:
	End		End
	End		End
		+	</pre>

Sandman at 00:51, 8 May 2007

2007-05-08T00:51:52Z

New page

Fenix Coding Convention by Sandman (work in progress)

== Names ==
Separating sections of a name is done by use of the "_" character. An easy example is the [[function]] [[NET_Init]]. "NET" is a different section than "Init", because the first denotes the origin of the function and the second denotes what the function does. Another example is [[NET_ERROR_CONNECTING]]: "NET" denotes the origin, "ERROR" denotes a more precise origin (an error) and "CONNECTING" denotes what the constant means (error while connecting).
Separating some words does not need a "_", but simple can be put together, making the first character of the second word a capitol. For example [[NET_SendVar]]. Here we see the section "NET" and the section "SendVar", which is further cut down to "Send" and "Var"

== Constants ==
Constants are written in ALL CAPS.

Like: [[C_SCREEN]], [[NET_ERROR_CONNECTING]], [[B_ALPHA]]

== Variables ==
Variables are written in low caps, whether they are private, local or global.

Like: [[ctype]], [[graph_mode]]

== Functions and Processes ==
Functions are written in low caps as well. Defining a function or process goes like so:
<pre>key_input( int keycode, int pointer status)</pre>
The "(" comes directly after the function name, followed by a " " (space) and the datatype of the first parameter, before a space and the name of the first parameter. Then a "," and the whole thing starts again, ending with a ")".

Calling a function or process isn't bound to any rules, because in many cases, the clarity of the code is different, even though the code is written the same. So just best suit the layout of the code to the environment. In general though, a good look is created by the use of a " " (space) before every parameter.

== Control-flow keywords ==
Control-flow keywords can be typed in two ways. The difference denotes the importance of the statement. The important control-flow statements are typed with the first character a capitol, while the less important ones are only low caps.

== Example ==
<pre>
Begin
key_input(_a);
Loop
frame;
End
End

Process key_input( int keycode, int pointer status)
Begin
Loop
if(key(keycode))
*status = true;
else
*status = false;
end
frame;
End
End