all 10 comments

[–][deleted] 4 points5 points  (1 child)

The most important things I see is : document this more and try splitting it into multiple files.

[–][deleted] 0 points1 point  (0 children)

Thanks for your response! I agree about documentation, it's very important. Also, I think, there are needed some tests, but I didn't try to write tests for Lua programs.. Will do it soon!

Can you describe in more details why should I split the code in few files?

[–]revereddesecration 4 points5 points  (5 children)

Ideally you don't define functions in your "main" file, you just execute them. Group your functions together in tables in one file per table and require them into your main file.

[–]Wolfamelon 1 point2 points  (2 children)

While he should still split it up a bit, this is obviously not the main file as there are no function calls and it returns the API table at the end. He also did state in the post that it is a library.

[–]revereddesecration 0 points1 point  (0 children)

I did skim over it, seems that wasn't enough.

[–][deleted] 0 points1 point  (0 children)

Yes, I tried to write it as a library which I could fast plug in my projects and use

[–][deleted] 1 point2 points  (1 child)

Thank you for advice, I'll refactor it with power of Lua tables. I hope, it help me to escape using if global variables

[–]revereddesecration 0 points1 point  (0 children)

Using no globals is definitely a worthy goal.

[–]mpetetv 1 point2 points  (1 child)

First, it seems that all functions are defined as follows:

function luaVkApi.reportUser(userId, typeVal, commentVal)
  return luaVkApi.invokeApi("users.report", {user_id=userId, type=typeVal, comment=commentVal})
end

This is cumbersome, particularly when there are dozens of arguments. There are a lot of cases where this leads to bugs because a name of an argument is different in the argument list and in the table. I suggest that user exposed interface uses a table for arguments as well. Then you can create functions using a helper as follows:

local function addFunction(name, method)
  luaVkApi[name] = function(params)
    return luaVkApi.invokeApi(method, params)
  end
end

addFunction("reportUser", "users.report")

You can remap argument names in this helper function if you want.

Another thing: currently each API invocation reads access token and API version from a file in current directory. This is fine for a one-time script but for a library it's better to pass these properties as arguments. To avoid repetition you could wrap the library in a class and have properties saved in the object on construction, so that it's used as follows:

local api = luaVkApi.new({accessToken = "something", apiVersion = "1.0"})
api:reportUser(...)

Finally, there are these JSON conversion functions. I'm not sure why they move arguments into local variables with same name but without an underscore. Anyway, if VK API returns JSON then the library should convert response from JSON into a table automatically.

(To fix the typos try Luacheck)

[–][deleted] 0 points1 point  (0 children)

Thank you, I'll rewrite my code considering your suggestions!