[QUOTE=Wizard of Ass;48485324]I'd also love an option to force OO use of strings(few exceptions such as string.byte, string.format).[/QUOTE]
In this case it'd also be good to force use of [I]#str[/I] instead of [I]string.len(str)[/I] or [I]str:len()[/I]
[QUOTE=mijyuoon;48485350]In this case it'd also be good to force use of [I]#str[/I] instead of [I]string.len(str)[/I] or [I]str:len()[/I][/QUOTE]
That's a separate thing really, I personally prefer using len() tho.
[QUOTE=mijyuoon;48485269]There's one case where semicolon is required, but I don't think it's gonna happen too often.
[code]
local a = stuff
("wat"):someshit()
-- ERROR: ambiguous syntax (function call x new statement) near '('
[/code][/QUOTE]
[QUOTE=Lexic;48485156]syntax Hitler[/QUOTE]
If you manage to make Lua throw ambiguous syntax, put the keyboard down and take a break.
[QUOTE=Wizard of Ass;48485324]I'd also love an option to force OO use of strings(few exceptions such as string.byte, string.format).
eg.
[code]local str = "hello "
string.sub(str, 1, 2)
--instead:
str:sub(1, 2)
[/code]
You could also force that for constants:
[code]
local a = ("hello"):sub(1, 2)
[/code]
Usually this makes code more readable since you chain calls rather than wrap, it also improves performance(if string is not localized).[/QUOTE]
I don't like OO strings because it's cleaner to do string.sub(str or "", "a", "b") than (str or ""):sub("a", "b")
[QUOTE=Ott;48487210]I don't like OO strings because it's cleaner to do string.sub(str or "", "a", "b") than (str or ""):sub("a", "b")[/QUOTE]
OO strings are cleaner but only when first argument is just a variable.
[QUOTE=Wizard of Ass;48485324]it also improves performance(if string is not localized).[/QUOTE]
lmao
[URL="https://github.com/garrynewman/garrysmod/blob/master/garrysmod/lua/includes/extensions/string.lua#L303-L312"]"because utilizing the __index metamethod of strings and going through a check is faster than outright calling the function"[/URL]
Due to popular demand I've changed the lexer around a bit and made it lex whitespace. The limitation still partially holds, though: it's really hard to reason about indentation, because that requires scope knowledge, which the lexer doesn't have.
That said, the linter now checks for trailing whitespace and a lack of whitespace around '='.
edit:
Just took hours to implement a VERY rudimentary, scope unaware check for inconsistent indenting with tabs and spaces. Basically, if it finds both "\n\t" and "\n_" in separate whitespace tokens, it'll give the warning.
That means that this is detected:
[lua]
if tabs then
local bananas = 1
end
if spaces then -- Warning is at the end of this line, because the whitespace token is "\n "
local bananas = 1
end
[/lua]
But this isn't:
[lua]
if spaces then
local bananas = 1
end
if four_spaces_and_one_tab then
local bananas = 1
end
[/lua]
I'd say that's good enough for now.
[QUOTE=zerf;48489272]lmao
[URL="https://github.com/garrynewman/garrysmod/blob/master/garrysmod/lua/includes/extensions/string.lua#L303-L312"]"because utilizing the __index metamethod of strings and going through a check is faster than outright calling the function"[/URL][/QUOTE]
I'm late, I forgot about this abomination, that fucking "enhancement" caused way too many problems.
Sorry, you need to Log In to post a reply to this thread.
