Adding Lua codestyle #197
Adding Lua codestyle #197
Conversation
Totktonada left a comment
Totktonada left a comment There was a problem hiding this comment.
Some comments from me.
| -- vim:ts=4 ss=4 sw=4 expandtab | ||
| * No whitespaces at EOL, newline at end of file (?) |
There was a problem hiding this comment.
Wording is a little confusing here. An file should ends w/ one newline symbol, but shouldn't ends w/ blank line (two newline symbols).
| * Using spaces: | ||
| | ||
| - do not use a space after functions and after commas in arguments: |
There was a problem hiding this comment.
I didn’t understand what stated here. Do not use a space btw a function name and opening circle bracket? Use a space after commas in formal arguments list?
There was a problem hiding this comment.
1 - we shouldn't use spaces between function name and open round bracket
2 - we should use spaces after commas in the argument lists
I'll rephrase that
| function name(arg1, arg2, ...) | ||
| end | ||
| - use spaces after comments: |
There was a problem hiding this comment.
After two dashes? ‘After comment’ means for me ‘after last word of a comment’.
There was a problem hiding this comment.
Yes, after comment marker
| do_something() | ||
| end | ||
| - surrounding operators: |
There was a problem hiding this comment.
What about case when = used in a table definition?
There was a problem hiding this comment.
Similar rules, but I didn't described case with alignments..
| local thing = {1, 2, 3} | ||
| -- good | ||
| - Add a line break after multiline blocks. |
There was a problem hiding this comment.
Maybe we should stated expicitly that it should be one blank line btw functions / blocks — for ones who aware of PEP-0008 :)
There was a problem hiding this comment.
Ok, I'll rephprase that
| - ``s``/``str``/``string`` is for strings | ||
| - ``c`` is for 1-char strings | ||
| - ``f``/``func``/``cb`` are for functions | ||
| - ``status, <return_name>`` is what you get out of pcall |
There was a problem hiding this comment.
I’m using ok in place where status suggested in this doc. Should we consider it’s okay?
| * <func>'<name>' (strongly avoid require'..') | ||
| * ``function object:method() end`` (use ``functon object.method(self) end`` instead) | ||
| * use comma separator in tables, instead ``;`` or anyone else | ||
| * put comma at the end of line |
There was a problem hiding this comment.
Avoid putting comma at the end of line? Why it’s bad? Can you give an example?
There was a problem hiding this comment.
I mean semicolon here, thanks. Semicolon may be used as 'visual separator' in Lua
| | ||
| * <func>'<name>' (strongly avoid require'..') | ||
| * ``function object:method() end`` (use ``functon object.method(self) end`` instead) | ||
| * use comma separator in tables, instead ``;`` or anyone else |
There was a problem hiding this comment.
I mean that we must use , separator instead of ; or anything else
Totktonada left a comment
Totktonada left a comment There was a problem hiding this comment.
Feedback on the new changes.
| | ||
| - do not use a space after functions and after commas in arguments: | ||
| - one shouldn't use spaces between function name and opening round bracket, | ||
| but arguments must be splitted with one whitespace charachter |
| - surround top-level function and class definitions with two blank lines. | ||
| | ||
| Extra blank lines may be used (sparingly) to separate groups of related |
There was a problem hiding this comment.
Top level functions? So, extra line is third one? I don’t sure it’s good.
Local function? So, it’s covered by sentence about indicating logical sections on line 255.
| something = 'even better' | ||
| } | ||
| - surround top-level function and class definitions with two blank lines. |
There was a problem hiding this comment.
It’s suggested by only one of three code styles you linked above. Personally I don’t like Python’s approach with two lines btw each top-level function/block. Moreover, in Lua we have ends after each function (on it’s own line), so two lines seems even more useless then in a Python code. Anyway, it’s point where third opinion would be helpful.
Maybe I confused you in our voice talk, sorry.
| 👍 |
| I have question about Commeting section: Why convention is different from Doxygen? Is there any tool to generate documentation using this comments? |
rtsisyk left a comment
rtsisyk left a comment There was a problem hiding this comment.
I have concerns about "Commenting" sections.
closes tarantool/tarantool#2380