Code Organization - is there a #Region C# Equivalent in Lua?

I used a lot of C# in college before I graduated this past spring. I grew to like C#'s #Region feature that lets you create collapsible sections of code. It helped me organize longer blocks of code into sections of similar tasks which could be collapsed to only show a title/header that I gave the Region. With this, I could quickly skim through blocks of collapsed code and find the part I needed to work on and expand it.

It behaves the same way as if you collapse a function or an if-statement, hiding everything inside the function or inside the if-statement. But as mentioned, it also allows you to give the region of collapsed code a name of your choice.

I tried searching around to see if I could find an equivalent in Lua but with no luck. Are my search skills lackluster or does Lua just not have such a thing?

2 Likes

There’s nothing like that unfortunately. If the blocks of code can act in isolation from each other, then you could use a do...end block w/ a comment.

5 Likes

I remember one or more of the Roblox corescripts used this at some point in the past. E.g.

local avatarStuff do
    ...
end

which can also be used similarly to a module:

local avatarStuff do
    local defaultScale = 1;

    avatarStuff = {
        Scale = defaultScale;
    }
end

print(defaultScale)
print(avatarStuff.Scale)
avatarStuff.Scale = 9
print(avatarStuff.Scale)

nil
1
9

However, I don’t recommend either of these. You should use an actual ModuleScript for the second case, and the first’s syntax is not good practice because it’s not readable. When I first saw it I didn’t understand what it was – I thought it was new syntax I didn’t know about. It makes a lot more sense when you use:

local avatarStuff; do
    ...
end

but if you’re not using the variable (which you shouldn’t – if you do, use a modulescript), what crazyman suggested is the best option:

do --avatarStuff

end
4 Likes

Can confirm, I just use do…end for this.

I do that for organizing my code. Like you said about variables, I don’t make any where there would be none - which means it doesn’t look very consistent but the only time when that happens is usually for the “main” code so that’s fine. I find it’s really useful for organising my code, for me it’s much easier to read and go through than your average Lua script.

It’s also a quick way to make objects, e.g:

local Interface ={} do
    -- methods, private variables, etc. here
end

Use modules!

3 Likes

Mm yeah but I often use global variables for things. In situations like that I won’t even consider a ModuleScript because I cannot give them any variables (in a way that isn’t stupid).

Global variables commonly being constants, a shared data table, etc.

And objects aren’t the only reason I use do end blocks, they also are just great for organising and garbage collecting temporary vs will-be-used-later variables.

In some circles, C# regions are seen as a code smell that your module is becoming too complex.

I think you can also apply this to Roblox Lua. I recommend you split your code into more modules if you find that you need regions as a feature.

This may not be exactly what you’re looking for, but there are other benefits to keeping your modules simple. So this is my recommendation.

4 Likes

I dont use global variables (never had a need to) and i dont see any problem with indexxing a module instead of the environment or arbitrary object

Not talking about _G or anything like that, I’m just talking about variables within the script that can be accessed from anywhere within it.

The issue lies when you have interconnected (not ‘pure’) code. In my case it’s not like a massive mess, but there a few things specific to each script that get used and would simply be a hassle to be passed into child modules (as you can’t do it directly, you need to make your own code for that).

Personally, I think Roblox isn’t really designed to work properly with modules. You can do stuff with them, but they aren’t as good compared to other languages and environments. So I do the closet approximation without losing any functionality.