Is it bad practice to set a variable type as a string "Description"?

[fighterkirbyzx]

To get right into it, take a look at the following code:

local selection = {}

export type SelectionParams = typeof(setmetatable({} :: {
	Radius: "number | Default 10 | The size of the mouse's radius for selection in studs",
	MaxTargets: "number > 0 | Default 1 | The maximum targets the camera can hit",
	SelectionBehavior: "string | Closest, Farthest | Default 'Closest' | Changes selection priority when dealing with multiple targets"
}, selection)) 

function selection:FindCharacter(Params: SelectionParams, mouse: Mouse)
	--Unfinished and irrelivant for the question
end

return selection

Which I use to do this:

(Aka set easy to read variables for module scripts)

Is it good practice to set the type of a variable as a string that functions as a description?

On the very big plus side, it makes this LEAGUES easier to read (and makes my flow 10x faster with my forgetful ADHD brain), but I’m not sure if I’m going to run into some string limit problem, memory issues, or if making it such a long string will take up minimal amounts of runtime, which so far, I haven’t run into yet.

When I ran a similar script using the same “Description” system, I didn’t notice a performance difference in the script performance tab or the micro profiler, so unless I missed something, I would think I can continue using this for module Parameters. Lemme know what you think!

[kingerman88]

I mean it wouldn’t really impact performance, but --!strict typechecking will throw warnings and you won’t get the autocompletes for strings and other objects. I’d say this falls as a bad coding practice since it’s an unintentional way of using the typechecking feature.

Regarding autcompletes for objects

local thing: "Model | Default: Character | Some model in workspace" = workspace.Model
thing:GetDescendants() -- will not autocomplete, you have to type it out in full

-- instead it will prompt string autocompletes
thing:upper() -- will be shown as an autocompletable method, which is 100% wrong

local thing: Model = workspace.Model
thing:GetDescendants() -- will show autocomplete, so you don't have to type out in full

---

Overall I’d say this falls in a similar category to comments and align with the position Code Aesthetics outlines in his youtube video here: https://youtu.be/Bf7vDBBOBUA?si=Lc-4S4K5vfvL6JBv

The TL;DR is that rather than adding descriptions to your variables, you can prioritize writing better variable names instead. In your case Radius: number is somewhat ambiguous, instead something like MouseSelectionRadius: number would be more clear.

[fighterkirbyzx]

This is exactly what I was looking for, thanks! In terms of the way I use module scripts, I haven’t noticed any downsides to using the type as a description, and showing the description after putting : hasn’t given me any trouble, but I get what you mean with the names being a little ambiguous. One thing I’m still confused about though – is there a reason why using types in an unintentional way is a bad thing? Is it that my method could break in the future if Roblox changes how the engine works?

EDIT: thanks for the video too, I might look through their channel for other tips

[kingerman88]

Since typechecking isn’t used at compile time, there shouldn’t be any problems there. That will most likely never change due to the nature of Lua. This should probably never be a problem if you do want to continue doing that.