in , , , ,

GameMaker Studio 2 adding C# region type syntax code folding soon

GameMaker Studio 2 Code Folding

Code folding is a pretty simple concept: Condense multiple lines of code into one line that can be expanded again when needed; it keeps large code files neat and clean while allowing a developer to still read over the general logic flow. How you implement code folding, on the other hand, can make or break the entire user experience. Don’t believe me, just look at how upset Mike Dailly gets when thinking about brace syntax style code folding:

“Why not just allow us to fold all code between { }?

Because i hate this with a passion. Allowing folds on a one line section of a nested “for”..nuts. Folds should be foe “chunks” of code, whole areas that do a specific task, not that one line you want to hide and forget about.” – Mike Dailly

Not that Mike doesn’t have his reasons, which are as always, well thought out, logical and most importantly based on experience. While we still do not have a hard ETA on when code folding will be enabled in GMS 2, we do know the reserved keywords (which are the same as C#’s code folding keywords): #region and #endregion are in place and Mike himself said: “it’s coming soon. (no dates yet)” on  Aug 13, 2017. How might code folding work, what does it look like and will it be mandatory for clean code? Read further for some technical details to answer those questions.

Fold your code and put it away

The first thing you need to know about code folding is why would you want to do it the first place. To a programmer, code folding may not have any appeal; after all, folding doesn’t make performance any better nor does it provide shortcuts or features while developing; further, the rules that determine what and when to fold are dependent on language and/or software being used. To give a possible reason, let’s try the following scenario: Picture for a moment that you are in a clothing department store and they are selling different kinds of shirts: T-shirts, Dress Shirts, Sweaters and Polo Shirts. Now as an experiment the store has two different displays for these shirts:

  1. A giant table with all the shirts side by side, in order by type from left to right but with no space in between them. They have a lot of shirts so the table extends to cover the entire aisle.
  2. A giant table with collapsible sections that can expand or contract, each type of shirt is contained in a separately labeled section and can be collapsed or expanded at will by the customer. If all sections are collapsed the table only takes up a small portion of the aisle but when all sections are expanded it takes up the entire aisle.

Let’s also suppose that only 1 customer can shop for shirts at any given time. Given our parameters we should see the following:

  1. [Giant Table] → Browsing customer appreciates the large viewing selection and they slowly go through each part of the table. Customer’s who are only looking for a specific type of shirt, however, need to search through the entire table, sometimes having to walk to the end of the aisle before finding what they need.
  2. [Collapsible Sectioned Table] → Browsing customers expand all sections first and then proceed to slowly go through each part of the table. Customer’s who are only looking for a specific type of shirt simply expand the section they need and immediately get the shirt they want.

Code folding works the same way as our collapsible table; you can take boiler plate code that is normally just sitting there taking up viewable space but not adding any value and fold it away, putting it into a virtual drawer that you can open and close anytime you want. Now, right here we need to stop and take a second to address the “say no to folding” crowd as the strongly negative views about code folding harbor around not doing what is considered best practices. If you use code folding or plan to use it, know that the following might be branded against you:

  • Code Folding hides bad code → Folding sweeps away bad smelling code, eventually leading to code rot. If you don’t want to look at the code you are folding away, then no-one else will either.
    • » Bad code is bad code. Doesn’t matter if it’s folded away, out in the open, or isolated in separate classes. Code folding has to do with how the code is displayed to the programmer and as we already stated, code folding has no effect on the code itself
  • Code Folding encourages large methods → Breaking a method apart into foldable regions is not an excuse to make large methods, instead, think about breaking each section into a new method that only does a specific function
    • » Large methods can be hard to read and test; no argument there, but folding the code doesn’t make something worse than it already is. This is not a reason to ban the use of code folding
  • Code Folding helps create source code growth → When you hide large portions of related code together, like fields or properties than instead of refactoring too large of a code base, you instead just hide it now and add to it later
    • » If someone writes 1000 lines of code, breaks each section of related elements into “foldable regions” and then adds to each region over time until it reaches 2000 lines; that doesn’t mean Code Folding was the blame. It was going to happen with or without the folding, at least with folding there is a minimum of implicit region logic sectioning.

Code Folding is a tool, and a welcome one at that; like all tools, you can choose whether or not you want to use it, along with how to use it. With that out of the way, let us show an example

var playerName = argument0;
var playerHP = argument1;
var playerItem = argument2;
var playerGold = argument3;
var npcItem = argument4;
var npcGold = argument5;

if (...) {
 for (...) {
 if (...) { }
 }
}

Now the above looks pretty standard

  • pass in arguments to a script and assign them to a local variable
  • Begin actual logic functions

If we used code folding we could end up with the following:

C# / (Potentially closest to GameMaker Studio 2 #region Code Folding)

#region Local Variable Assignment
var playerName = argument0;
var playerHP = argument1;
var playerItem = argument2;
var playerGold = argument3;
var npcItem = argument4;
var npcGold = argument5;
#endregion
if (...) {
 for (...) {
 if (...) { }
 }
} 

Which when folded turns into

+ Local Variable Assignment 
if (...) {
 for (...) {
 if (...) { }
 }
} 

If you saw this folded code, you could immediately guess what the folded code was and unless you were adding more local variables you probably would not need to open the folded part very often while working on the logic portions of the code. This not only saves space but time as well, no longer do you need to mentally skip or process the argument assignments. You can use folding for whatever and whenever you want, but no matter what you choose you should at least follow one rule: Be Consistent. Choose definable rules for when you fold and stick with it for the project, this way when someone else reads that code they will quickly understand what to expect.

User-defined or Syntax defined?

The last point I want to say about code folding is the importance of how it is implemented. As I said previously, code folding is a tool and is more about developer preference than anything else; for this reason having a user section defined folding system with clear rules is better than an automatic syntax folding system. In the previous example, we use the tags: #region and #endregion to define our foldable block, this is deliberate and you cannot accidentally type in #region. If instead it was automatic and based on braces, not only could you potentially type in an extra brace but visually distinguishing braces used in control statements vs braces used for code folding is mentally exhausting, even if the syntax is triple braces “{{{…}}}”, the fact that you are reusing control syntax for a different purpose causes intellectual fatigue. We can see why Mike would be opposed to using a brace style of code folding and as said before, such a decision is made through real world experience of what works best.

Just one of many new features on the RoadMap

Like many other GameMaker Studio 2 users, I am pretty excited about the code folding feature and cannot wait for the new update with it to come out. There are, however, other features on the Official 2017 RoadMap including:

  • Room Editor: Static Text on Asset Layers – include Language Resource support
  • Refactor support
  • Code Editor – Pretty Print / Format of selected code.
  • Tile Collision – built in support for tile collision
  • GML: exception support – try… catch… finally… and throw
  • GML: foreach statement to iterate over arrays and data structures

This was an exciting year for GameMaker Studio 2 and the RoadMap shows that it will only be getting better. GMS 2 version 2.1 should be a milestone update and I am anxious to see how many new features end up in it.

Good Luck in all things,
Hikati Games
Hikati Games LLC Logo

What do you think?

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Cook, Serve, Delicious! 2!! firms up release date to September 13th

GameMaker Studio 2 Annouces official Mac version in newly released 2.1 milestone