SUPER STRICT for LUA

[togFox]

SStrict works well now and it has caught a few things that could have bit me down the road.

My contribution to this project is to do a small TIPS checklist for newcomers:

Create a new main.lua in the PARENT folder of your main source code (i.e. go up one folder and create a main.lua file). This will be your sstrict script.

Add the following to that new main.lua:

Code: Select all

require("sstrict")
require("Source.main")

sstrict.lua needs to sit beside your new main.lua and my real main.lua is in the "Source" sub-folder. You can adjust accordingly. When you execute this new main.lua, sstrict will then inspect your real main.lua and through runtime errors with descriptions for you to fix.

Some coding practices that sstrict is expecting:

- functions need to be declared as local functions

Code: Select all

local function foo()
end

- variables need to be declared as local

Code: Select all

local function foo()
	local msg = "Hello foo"
	print(msg)
end

- functions need to be declared ABOVE the calling function. If love.load() calls a function then that function needs to be declared above love.load()

Code: Select all

local function foo()
	local msg = "Hello foo"
	print(msg)
end

love.load()
	foo()
end

There are other rules that sstrict apply but those will get most noobs up and running. Thanks @Ivan! I hope my small contribution helps.

[JayKyburz]

Hello, I'm a new Lua and Love user and wanted to give some feedback.

I would really like to be able to use super strict, but when I required it, it starts finding errors in the libs I'm using. It would be nice if I could tell it not to inspect a subset of modules I'm vendoring into the project. (I'm not really ready to start editing breezefield for example)

[ivan]

Hello Jay and thank you for using SUPERSTRICT.
In your case, you have 2 options.
You can either require your lib files BEFORE requiring SUPERSTRICT.
Or you can put the following line at the top of your lib file:

Code: Select all

--!strict

[JayKyburz]

Perfect thanks Ivan!

[togFox]

Checking best way to deal with globals. I have a legitimate need to use globals in main.lua:

Code: Select all

gintNumRows = 12
gintNumCols = 12

sstrict wants me to make them local. That won't work so I do this:

--!strict
gintNumRows = 12
gintNumCols = 12
--!strict

This works. sstrict skips over them but causes a new problem:

Code: Select all

local function InitialiseThings()
	
	-- Initialise map array
	local row, col
    
	for row = 1, gintNumRows do
		map[row] = {}
	end

It now says gintNumRows is undefined. :facepalm: How do I get sstrict to process a line (gintNumRows = 12) without throwing an error so that it can continue to parse further down the line?

(no - I'm not going to pass those variables as parameters into every single function I call).

[ivan]

The easiest way is to declare those before you include sstrict

[togFox]

I 'invoke' sstrict like this, in a file called main.lua:

Code: Select all

require("sstrict")
require("Source.main")

My real code is, of course, in source\main.lua. This way I can do my coding in any lazy and bad mannered way I like and then at the end of the session run the sstrict main.lua (in the parent folder) and then fix my code up.

Is there a different/better way to invoke sstrict? Should I put it directly into my real main.lua?

[ivan]

Is there a different/better way to invoke sstrict? Should I put it directly into my real main.lua?

You don't need to invoke sstsrict in your "main.lua" and you don't even need to use it while running your game. You can create a separate project that scans your game directory and checks/validates each file.

[togFox]

Would be nice if this generated a report to console or file with throwing a runtime error and stopping. It would allow me to focus on different things.

[ivan]

togFox, if you just want to see the messages in the console without throwing an error, you can use:

Code: Select all

require("sstrict").panic = false

Please note that SUPERSTRICT cannot throw "runtime" errors - because it doesn't actually run/execute the code, it just scans/validates the code.