From b6db1aa372ec382b928daec2950558903a16677a Mon Sep 17 00:00:00 2001 From: Hyper_ <40342021+NotHyper-474@users.noreply.github.com> Date: Tue, 30 Jun 2026 15:30:34 -0300 Subject: [PATCH 1/3] Good Coding Practices Guide --- .../Expert/-07.GoodCodingPractices.md | 65 +++++++++++++++++++ 1 file changed, 65 insertions(+) create mode 100644 assets/content/cookbook/Expert/-07.GoodCodingPractices.md diff --git a/assets/content/cookbook/Expert/-07.GoodCodingPractices.md b/assets/content/cookbook/Expert/-07.GoodCodingPractices.md new file mode 100644 index 00000000..b748e580 --- /dev/null +++ b/assets/content/cookbook/Expert/-07.GoodCodingPractices.md @@ -0,0 +1,65 @@ +[tags]: / "expert,misc,hscript" + +# Good Coding Practices + +This article will go over practices that can be applied to your code, improving its quality. + +These are not mandatory, so it's up to the programmer whether to make use of them. + +# Be Fairly Local! + +A feature of many programming languages is local variables, which are variables that you define inside of functions. + +One advantage of using them is making the code cleaner, a topic we will address in this sub-article. Let's take this code snippet as an example of how local variables can be of use. + +```haxe +function foo() +{ + if (FlxG.state?.subState is FreeplayState) + { + if (FlxG.state.subState.ostName.length > 8) + { + FlxG.state.subState.ostName.size = 0.5; + } + } +} +``` + +At a first glance, we can see a lot of repetitive references to `FlxG.state.subState`. This doesn't hurt, but is not desirable. Now let's see the same snippet, but with a local variable being used instead. + +```haxe +function foo() +{ + var currentSubstate:FlxSubState = FlxG.state?.subState; + if (currentSubState is FreeplayState) + { + if (currentSubState.ostName.length > 8) + { + currentSubState.ostName.size = 0.5; + } + } +} +``` + +As it can be seen, we are now storing the result of `FlxG.state.subState` inside of a variable. You may notice we didn't do the same to `ostName`, since it's not really referenced a lot. In a real scenario, the current substate could be referenced much more depending on what the code needs, which is why we store it. + +This is actually more efficient too! For every instance of `FlxG.state.subState`, each field has to be obtained individually; a local variable essentially stores the result of that. + +Have in mind that storing a value (like a number or a text string) you got from an object in a variable, then assigning another value to it, will not affect the object. + +Below is an example of that. `titleText` is an `FlxText` whose `text` field contains the content. Modifying `text` will _not_ modify the contents of `titleText`. +```haxe +var text:String = FlxG.state.titleText.text; +text = 'My Awesome Mod'; +``` +# Explicit Types + +Unlike Haxe, in hscript there's usually no need to specify variables types, whether those are local variables, parameters, or even class-level fields, because as a scripting language it is dynamically typed. So they are simply ignored. + +However, it might be useful to do this if you decide to revisit your code later, as they can help you understand what the code is doing. + +A type is specified using the `:TypeName` syntax. For instance, a variable for a piece of text can be represented as `var text:String`. + +Since these are ignored, you can put pretty anything for the type name... except for `Map`, which does get interpreted, however it's a bit unreliable. + +> Author: [NotHyper-474](https://github.com/NotHyper-474) \ No newline at end of file From 28d0cfe0a52441858c1db2e3263939f3246abf4e Mon Sep 17 00:00:00 2001 From: Hyper_ <40342021+NotHyper-474@users.noreply.github.com> Date: Tue, 30 Jun 2026 22:28:27 -0300 Subject: [PATCH 2/3] move some stuff around --- assets/content/cookbook/Expert/-07.GoodCodingPractices.md | 8 +++----- 1 file changed, 3 insertions(+), 5 deletions(-) diff --git a/assets/content/cookbook/Expert/-07.GoodCodingPractices.md b/assets/content/cookbook/Expert/-07.GoodCodingPractices.md index b748e580..51164edb 100644 --- a/assets/content/cookbook/Expert/-07.GoodCodingPractices.md +++ b/assets/content/cookbook/Expert/-07.GoodCodingPractices.md @@ -54,12 +54,10 @@ text = 'My Awesome Mod'; ``` # Explicit Types -Unlike Haxe, in hscript there's usually no need to specify variables types, whether those are local variables, parameters, or even class-level fields, because as a scripting language it is dynamically typed. So they are simply ignored. +Unlike Haxe, in hscript there's usually no need at all to specify variables types, whether those are local variables, parameters, or even class-level fields, because, as a scripting language, it is dynamically typed. So they are simply ignored, except for `Map<..., ...>`, which does get interpreted, however it's a bit unreliable. -However, it might be useful to do this if you decide to revisit your code later, as they can help you understand what the code is doing. +Nonetheless, it might be useful to do this if you decide to revisit your code later, as they can help you understand what the code is doing. -A type is specified using the `:TypeName` syntax. For instance, a variable for a piece of text can be represented as `var text:String`. - -Since these are ignored, you can put pretty anything for the type name... except for `Map`, which does get interpreted, however it's a bit unreliable. +A type is specified using the `:TypeName` syntax. For instance, a variable for a piece of text can be represented as `var text:String`. Since these are ignored in nearly all cases, you can put pretty much anything for the type name. > Author: [NotHyper-474](https://github.com/NotHyper-474) \ No newline at end of file From 5436693484968ddc3edb4c49256541b7be245832 Mon Sep 17 00:00:00 2001 From: Hyper_ <40342021+NotHyper-474@users.noreply.github.com> Date: Tue, 30 Jun 2026 23:15:23 -0300 Subject: [PATCH 3/3] unfinished stuff I'd rather continue tomorrow --- .../Expert/-07.GoodCodingPractices.md | 81 +++++++++++++++++-- 1 file changed, 76 insertions(+), 5 deletions(-) diff --git a/assets/content/cookbook/Expert/-07.GoodCodingPractices.md b/assets/content/cookbook/Expert/-07.GoodCodingPractices.md index 51164edb..afd1a6d8 100644 --- a/assets/content/cookbook/Expert/-07.GoodCodingPractices.md +++ b/assets/content/cookbook/Expert/-07.GoodCodingPractices.md @@ -2,9 +2,7 @@ # Good Coding Practices -This article will go over practices that can be applied to your code, improving its quality. - -These are not mandatory, so it's up to the programmer whether to make use of them. +This article will go over practices that can be applied to your code, improving its quality. These are not mandatory, so it's up to you whether to make use of them. # Be Fairly Local! @@ -13,7 +11,7 @@ A feature of many programming languages is local variables, which are variables One advantage of using them is making the code cleaner, a topic we will address in this sub-article. Let's take this code snippet as an example of how local variables can be of use. ```haxe -function foo() +function foo():Void { if (FlxG.state?.subState is FreeplayState) { @@ -28,7 +26,7 @@ function foo() At a first glance, we can see a lot of repetitive references to `FlxG.state.subState`. This doesn't hurt, but is not desirable. Now let's see the same snippet, but with a local variable being used instead. ```haxe -function foo() +function foo():Void { var currentSubstate:FlxSubState = FlxG.state?.subState; if (currentSubState is FreeplayState) @@ -48,6 +46,7 @@ This is actually more efficient too! For every instance of `FlxG.state.subState` Have in mind that storing a value (like a number or a text string) you got from an object in a variable, then assigning another value to it, will not affect the object. Below is an example of that. `titleText` is an `FlxText` whose `text` field contains the content. Modifying `text` will _not_ modify the contents of `titleText`. + ```haxe var text:String = FlxG.state.titleText.text; text = 'My Awesome Mod'; @@ -60,4 +59,76 @@ Nonetheless, it might be useful to do this if you decide to revisit your code la A type is specified using the `:TypeName` syntax. For instance, a variable for a piece of text can be represented as `var text:String`. Since these are ignored in nearly all cases, you can put pretty much anything for the type name. +## Function Return Types + +Functions can also have **return types**, and the syntax is pretty much identical to variables. +```haxe +override function getPipis():Array +{ + if (scene == null) + { + return super.getPipis(); + } + return scene.pipisList; +} + +function spareEnemy(?enemy:Enemy):Void +{ + if (enemy == null) + { + enemy = scene.enemies[0] ?? return; + } + + enemy.performSpareAnimation(); + scene.remove(enemy); + // ... +} +``` + +Just like with variables, these types don't actually do anything, but they make it clearer what each function may do and whether to expect them to return something. + +# Formatting Rules + +Formatting rules are a set of standardized guidelines for structuring code. In this article, we'll go over two common styles for styling your code. + +## Allman Style + +```haxe +function foo(params:FooParams):Void +{ + if (condition) + { + // Pretend this does something. + } + else + { + // Ditto. + } + + var validatedParams:FooParams = { + bar: params.bar ?? new Bar() + // ... + }; +} +``` + +## K&R Style + +```haxe +function foo(params:FooParams):Void { + if (condition) { + // Pretend this does something. + } else { + // Ditto. + } + + var validatedParams:FooParams = { + bar: params.bar ?? new Bar() + // ... + }; +} +``` + + + > Author: [NotHyper-474](https://github.com/NotHyper-474) \ No newline at end of file