-
Notifications
You must be signed in to change notification settings - Fork 41
Code style guide #300
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
Code style guide #300
Conversation
|
|
||
| ## Line breaks, new lines and file Endings | ||
|
|
||
| All source files must end with two empty lines. Otherwise, there mustn’t be multiple consecutive empty lines in the files. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just one, right.. one empty line at the end of the file
|
|
||
| ## Line Breaking | ||
|
|
||
| Staying under 80 characters per line is [preferred](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=bdc48fa11e46f867ea4d75fa59ee87a7f48be144), but [don’t stick to this rule against common sense](https://lkml.org/lkml/2020/5/29/1038). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We actually don't respect this.. we can agree on a sane number though.. 80 is too little
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In the reference above, Linus raised the detected limit in the warning script to 100.
Luacheck by default checks for lines > 120.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Perhaps we should see what's the longest in the current code base?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ohh that's long.. hehe.. any chance of getting the second longest? I think that might be a good number..
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
176, then 135.
Over 105903 lines whose length > 9, only 58 (lines of code, not comments or LDoc) are above 100, only 11 above 120.
With Linus leaving a warning above 100, I think it could be a good rule, as soon as we agree that common sense keeps all its rights.
IMHO, this style of break (as function definitions are likely the longest ones) would be the best: two tabs before the second line, to avoid confusion with function body. Python follows this convention. Aligning with the opening parenthesis would require mixing tabs and spaces for indentation.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would say 120 and 1 tab.. my vote, at least ;-)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we could agree on that, then:
Staying under 120 characters per line is _preferred_, but [don’t stick to this rule against common sense](https://lkml.org/lkml/2020/5/29/1038).17ac113 to
925bfd9
Compare
Following a discussion with @lneto, here is a proposal for a coding style guide. Submitting as a draft, as it’s open to criticism and modifications!