What should a GLua linter lint for

[Wizard of Ass]

I am aware that there is a difference, but I've yet to encounter a situation where I explicitly have to return nil.

Do you have some gmod related use case?

[Willox]

[QUOTE=Wizard of Ass;48472500]I am aware that there is a difference, but I've yet to encounter a situation where I explicitly have to return nil.

Do you have some gmod related use case?[/QUOTE]

I always use return nil ever since I ran in to issues whilst trying to debug the returned value of some functions using print and got confused.

[Th13teen]

Redefining things that are in the global table by default.

Example:
[lua]
local file = "hello world"
file.Read( <something> )
[/lua]
I've made the mistake several times before.

Things such as double negatives
Example:
[lua]
return !( 1 != 2 )
[/lua]

[Grocel]

[QUOTE=FPtje;48465934]Currently it checks for:
[...]
- self.Weapon in SWEPs
[...]
[/QUOTE]

I guess, self.Entity in entities should be there too.

[zerf]

-ninjas-

[tyguy]

Maybe it's just me, but sometimes I forget the argument order for net.Receive on the server.

Example:

net.Receive("blabla", function(ply, len)
end )

should be:

net.Receive("blabla", function(len, ply)
end )

It's probably just me but i'm sure it's happened to some of you too.

[Author.]

[QUOTE=tyguy;48472880]Maybe it's just me, but sometimes I forget the argument order for net.Receive on the server.

Example:

net.Receive("blabla", function(ply, len)
end )

should be:

net.Receive("blabla", function(len, ply)
end )

It's probably just me but i'm sure it's happened to some of you too.[/QUOTE]

A linter can't reliably handle such an issue since you can call them anything other than 'ply' and 'len', and adding any likely candidates will just be a waste of time and resources.

[tyguy]

[QUOTE=Author.;48472960]A linter can't reliably handle such an issue since you can call them anything other than 'ply' and 'len', and adding any likely candidates will just be a waste of time and resources.[/QUOTE]

forgive me if i'm wrong but couldn't the linter just check the type of the first and second argument?

[FPtje]

[QUOTE=Grocel;48472665]I guess, self.Entity in entities should be there too.[/QUOTE]

Done.

[QUOTE=tyguy;48472880]Maybe it's just me, but sometimes I forget the argument order for net.Receive on the server.

Example:

net.Receive("blabla", function(ply, len)
end )

should be:

net.Receive("blabla", function(len, ply)
end )

It's probably just me but i'm sure it's happened to some of you too.[/QUOTE]

Valid points, but I'll hold off on the things that require knowledge of the default lua/GMod functions until I get other stuff done. The same goes for live variable analysis (unused variables) and other kinds of dead code.

Through the way things lex and parse I'm also very limited in looking at whitespace.

I know these things limit the ideas a lot, but I still have a lot to work on from Lexic's post alone. In the meantime, [B]keep the ideas coming, they're great![/B]
Next on the list is the shadowing of variables/parameters created in the script. That's a somewhat bigger one, so I'll work on that tomorrow. That can later be extended by shadowing of default gmod functions and libraries.

[Wizard of Ass]

Silly question, but do you think you could implement something like cyclomatic complexity checks to identify "spaghetti" code?

I've used it in a bunch of JS projects so far and helped me to identify cluster of code that would eventually become hard to maintain.

[Zet0r]

I haven't messed with a lot of different code so I wouldn't really know, but would inconsistent spaces in arguments be something to lint for?
[lua]SomeFunction(argument)
SomeOtherFunction( argument )
Vector(1,1,1)
Vector(1, 1, 1)[/lua]

[xav]

[QUOTE=Zet0r;48477681]I haven't messed with a lot of different code so I wouldn't really know, but would inconsistent spaces in arguments be something to lint for?
[lua]SomeFunction(argument)
SomeOtherFunction( argument )
Vector(1,1,1)
Vector(1, 1, 1)[/lua][/QUOTE]

This

• Please enforce spaces after keywords (if, elseif, while, until, etc)

if(this_looks_like_a_function_call) then
    woo_function_call()
elseif(this_also_confuses_my_brain_and_looks_horrible) then
    print("Sorry cake and swad")
end

->

if (this_looks_like_a_function_call) then
    woo_function_call()
elseif (this_also_confuses_my_brain_and_looks_horrible) then
    print("Sorry cake and swad")
end

• I would say maybe? the inverse for function calls, but with an option, as I use this style quite extensively [url=http://xavie.ru/i/34HDYzr]View image: http://xavie.ru/i/34HDYzr.png[/url] not to mention when calling a function with a string literal or a table definition and omitting the parenthesis, generally speaking, you want a space for better readability.

• Check for lack of whitespace around assignment operator

local some_var=true    -- This looks ugly
local some_var = true  -- This looks much better

• No trailing whitespace

• Unified line endings (Text editors should take care of that, but some idiotic ones don't)

• No mix of tabs and spaces for indentation

• Max line width of 79 characters. Annoying at first but god damn useful after you get used to it.

[sp]Time to go PEP8 style?[/sp]

• Extending on people disliking call( arguments ) indexing[ like this ] is also annoying and separating(arguments , like , this) is even worse

• Two empty lines before non-anonymous function declaration (aka function identifier() but not identifier = function()) perhaps excluding comments?

• Empty line before if statement

• Discourage single-line if statements unless the only expression within it is a return/continue/goto statement or maybe a coroutine.yield()

• Disallow else on the same line as if

• End of line comments should start at least two spaces after the last character on the line, and have a space between the delimiter and the comment:

print("Hello!")  -- Good and easy to read
print("Bye")  --Acceptable, but hard on the eyes
print("What's up!?")--Horrifying
print("Oh god")  // Don't even get me started on this

Honestly, I think C-Style comments are horrifying.
• Enforce a strict comment syntax through linter settings to either enforce Lua or C's

The following would be harder to implement properly, but if you or anyone wants to give it a go:

• Inconsistent indentation width between nested blocks:

if this then
--->--->if that then
--->--->--->print "This and that!"
--->--->end
end

• Misaligned indentation

if this then
--->--->if that then
--->--->--->print "This and that!"
--->end
end

--or

if this then
--->if that then
--->--->print "This and that!"
end
end

• Make aligned assignments spaces only:
(Tabs will break on different tab rendering width! Not everyone wants their tabs to be 4 characters wide.)
[img]http://xavie.ru/i/31EfhTE.png[/img]

I have more stored in the bank of Brain, but those could bring up debates as to whether or not that is a linter's task, but this covers most of my pet peeves.

[Willox]

[quote]Max line width of 79 characters[/quote]

Is this the '80s?

[Donkie]

Throw a warning if someone calls the player argument anything other than "ply", it's become a standard. (Probably only possible in pre-defined hooks)

[xav]

[QUOTE=Willox;48478358]Is this the '80s?[/QUOTE]

No, but it makes having multiple files side-by-side easier on 1080p, which is very useful.
This would obviously be configurable, but it's a nice default.

[LegendofRobbo]

[QUOTE=xaviergmail;48478381]No, but it makes having multiple files side-by-side easier on 1080p, which is very useful.
This would obviously be configurable, but it's a nice default.[/QUOTE]

buy a second monitor

or learn to use tabs efficiently

[#NaN]

[quote]Max line width of 79 characters. Annoying at first but god damn useful after you get used to it.[/quote]

I already hate it that I'm forced to 80 characters when I'm coding stuff for university. And no - I'm not getting used to it after 2 semesters. It's just stupid. It's not that I'm gonna print my code on paper.

[xav]

Jesus, no need to be so hostile. It was just a recommendation. Every linter should have an option for max line length for those who want it. You guys clearly dislike the idea so perhaps have it disabled by default.

[editline]17th August 2015[/editline]

[QUOTE=legendofrobbo;48478415]buy a second monitor

or learn to use tabs efficiently[/QUOTE]

I don't know what makes you think I indent inefficiently, when I'm clearly suggesting proper indentation rules..? I don't want to start a debate on coding practices. "What works for you is best for you, stick to it"

[Willox]

I'm not against max line lengths, for the record. I try to stick to 120.

[FPtje]

[QUOTE=FPtje;48465934]

One limitation: it's very hard to reason about whitespace because that's taken out before analysis starts. I'd have to recode half the thing to get whitespace in the analysis. Comments however are fine.[/QUOTE]

The OP mentions one important limitation. I can do a couple of things with whitespace, but things like spaces within function definition parentheses is difficult.

[xav]

[QUOTE=FPtje;48478511]The OP mentions one important limitation. I can do a couple of things with whitespace, but things like spaces within function definition parentheses is difficult.[/QUOTE]

Ah, sorry. That pretty much nullfies all of my points :l

[#NaN]

[QUOTE=xaviergmail;48478449]Jesus, no need to be so hostile.[/QUOTE]

Sorry, I didn't meant to be hostile. I guess the feature might be useful for some people out there.

[ph:lxyz]

If you're linting the whole API, maybe identify where server-only code is being called inside a CLIENT section and vice-versa.

[MeepDarknessM]

[QUOTE=FPtje;48469618]
[img]http://i.imgur.com/9ACPlvn.png[/img][/QUOTE]

on thing i don't like about this is that you might want to target yourself in maybe a admin mod

for example, godding yourself.

[Mijyuoon]

[QUOTE=MeepDarknessM;48479133]on thing i don't like about this is that you might want to target yourself in maybe a admin mod

for example, godding yourself.[/QUOTE]

In admin mods that parameter usually would be a variable and not just LocalPlayer().

[MeepDarknessM]

[QUOTE=mijyuoon;48479178]In admin mods that parameter usually would be a variable and not just LocalPlayer().[/QUOTE]

you can not say usually or any quantifiable adjective really. There may be admin mods that have a button just to god yourself.

[Wizard of Ass]

[QUOTE=Willox;48478467]I'm not against max line lengths, for the record. I try to stick to 120.[/QUOTE]

You can just make it a setting and set the default to something like 140.

[Lexic]

[QUOTE=FPtje;48472243]I already have warnings on double semicolons and commas. Semicolons after statements is a programmer's style choice. I think it's stupid too, but that's my opinion and not a universal truth.[/QUOTE]

Embrace the config file, you know it to be true!

Seriously though - being able to force semicolons to either exist or not would be great.
I mean you never actually need them (unless you're syntax Hitler) since Lua tries very hard to make statement ends unambiguous.

Lua 5.1.4  Copyright (C) 1994-2008 Lua.org, PUC-Rio
> a = 5 b = c print(a,b)
5       nil

(But I like them)

[Mijyuoon]

[QUOTE=Lexic;48485156]Embrace the config file, you know it to be true!

Seriously though - being able to force semicolons to either exist or not would be great.
I mean you never actually need them (unless you're syntax Hitler) since Lua tries very hard to make statement ends unambiguous.

Lua 5.1.4  Copyright (C) 1994-2008 Lua.org, PUC-Rio
> a = 5 b = c print(a,b)
5       nil

(But I like them)[/QUOTE]

There's one case where semicolon is required, but I don't think it's gonna happen too often.

local a = stuff
("wat"):someshit()
-- ERROR: ambiguous syntax (function call x new statement) near '('

[Wizard of Ass]

I'd also love an option to force OO use of strings(few exceptions such as string.byte, string.format).

eg.

local str = "hello "
string.sub(str, 1, 2)
--instead:
str:sub(1, 2)

You could also force that for constants:

local a = ("hello"):sub(1, 2)

Usually this makes code more readable since you chain calls rather than wrap, it also improves performance(if string is not localized).