Page 1 of 1
Type checking
Posted: Wed Sep 03, 2014 8:52 pm
by 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?
Re: Type checking
Posted: Wed Sep 03, 2014 9:30 pm
by 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
Re: Type checking
Posted: Wed Sep 03, 2014 10:38 pm
by 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.
Re: Type checking
Posted: Thu Sep 04, 2014 4:11 am
by paulclinger
murks wrote: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.
Re: Type checking
Posted: Thu Sep 04, 2014 8:05 am
by murks
paulclinger wrote:
@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
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.
paulclinger wrote:
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 ?
Re: Type checking
Posted: Thu Sep 04, 2014 3:34 pm
by 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...
Re: Type checking
Posted: Fri Sep 05, 2014 9:47 am
by murks
paulclinger wrote:@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.