Type checking

[murks]

Now that I'm actually writing code I notice that most of the mistakes I make and have to hunt down are stupid typos. They often enough cost me half an hour to find.
I already use zbstudio with its static analyzer and it helps somewhat, but it can't find all such mistakes and also gives a couple of false positives.

What is your approach to avoid such stupid mistakes?

[slime]

liberal use of assert (in the appropriate places) can be one helpful tool.

For example:

Code: Select all

function foo(a, b, c)
    assert(type(a) == "string")
    assert(type(b) == "number")
    assert(type(c) == "table")

    local bar = {a=a, b=b, c=c}
    return bar
end

[Jeeper]

I used to have a ton of typing errors back when I started out, I think that you just get more observant as you get more experienced. A tip would be to run your game/application more frequently, that way it is easier to find any typos or other mistakes.

[paulclinger]

I already use zbstudio with its static analyzer and it helps somewhat, but it can't find all such mistakes and also gives a couple of false positives.

@murks, I don't have anything to suggest beyond what's already available in ZBS, but am curious what kind of mistakes are being missed and what expressions give false positives. I noticed myself that typos in table fields are difficult to detect; lua-inspect that ZBS is using can do field analysis as well, but it generates large number of false positives and is noticeably slower, so it's turned off by default.

I'm looking at alternatives for Lua parsing and am interested in examples that can be improved, although the changes are quite complex and may take several released to be fully implemented.

What you may try right now is to get the latest ZBS (use the one from github) and enable "slow" static analysis. Open src/editor/inspect.lua and change "local FAST = true" to "local FAST = false". It should report table field name mismatch as well. I wonder if this produces any better results for you.

[murks]

@murks, I don't have anything to suggest beyond what's already available in ZBS, but am curious what kind of mistakes are being missed and what expressions give false positives. I noticed myself that typos in table fields are difficult to detect; lua-inspect that ZBS is using can do field analysis as well, but it generates large number of false positives and is noticeably slower, so it's turned off by default.

I'm looking at alternatives for Lua parsing and am interested in examples that can be improved, although the changes are quite complex and may take several released to be fully implemented.

The false positives is for example normal use of middleclass:

Code: Select all

local Donkey = class('Donkey')

Code: Select all

donkey.lua:1: first use of unknown global function 'class'

One problem it didn't find was this: I used a variable 'ready' and decided then to call it 'jumpready' instead. I got somewhat confused and ended up with a mix of 'ready' and 'jumpready' (actually those variables were self.ready and self.jumpready). ZBS did not complain at all. I guess this is the table fields issue you mentioned.
Actually those are the times when I wish for a language where I have to declare variables before use.

What you may try right now is to get the latest ZBS (use the one from github) and enable "slow" static analysis. Open src/editor/inspect.lua and change "local FAST = true" to "local FAST = false". It should report table field name mismatch as well. I wonder if this produces any better results for you.

That does not work for me (using a build from yesterday, I just modified /usr/share/zbstudio/src/editor/inspect.lua):

Code: Select all

Lua: Error while running chunk
lualibs/luainspect/ast.lua:390: attempt to compare string with number
stack traceback:
	lualibs/luainspect/ast.lua:390: in function 'get_keywords'
	lualibs/luainspect/ast.lua:431: in function 'fdown'
	lualibs/luainspect/ast.lua:294: in function 'walk'
	lualibs/luainspect/ast.lua:423: in function 'ast_to_tokenlist'
	src/editor/inspect.lua:36: in function 'warnings_from_string'
	src/editor/inspect.lua:197: in function 'analyzeProgram'
	src/editor/inspect.lua:214: in function <src/editor/inspect.lua:211>
	[C]: in function 'MainLoop'
	src/main.lua:620: in main chunk
	[C]: in ?

[paulclinger]

@murks,

> I guess this is the table fields issue you mentioned.

I think so.

> That does not work for me (using a build from yesterday, I just modified /usr/share/zbstudio/src/editor/inspect.lua):

If the latest version already includes commit 63bc899a, could you PM me the file it happens on? I can't reproduce this issue...

[murks]

@murks,

> I guess this is the table fields issue you mentioned.

I think so.

> That does not work for me (using a build from yesterday, I just modified /usr/share/zbstudio/src/editor/inspect.lua):

If the latest version already includes commit 63bc899a, could you PM me the file it happens on? I can't reproduce this issue...

The problem is gone now (revision 63bc899). It did not depend on the file but it happened with revision b0ce69d. With 'FAST=false' ZBS warns about the first use of every field, including function definitions and everything, which isn't that helpful I think.

Code: Select all

Donkey.lua:6: first use of unknown field 'initialize' in 'Donkey'

Well, maybe it can help to identify typos, but it produces a lot of warnings of stuff that is perfectly fine.