-
Notifications
You must be signed in to change notification settings - Fork 7
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
[WiP] Set coding style for libhanjp #47
base: develop
Are you sure you want to change the base?
Conversation
For consistent indentation, change mixed indentation into one. As the libhangul and previous code base uses 4 spaces for indentation, convert all tab characters into 4 spaces. Signed-off-by: JaeSang Yoo <[email protected]>
1. Bracket ('{') rules * Functions, structure, union, class, enums Opening and closing brackets are placed on separate line. * Control-flow statements (ex. if, for, while...) Opening bracket should be in same line. If-else like code blocks, closing bracket can be in same line. (ex. "} else {") 2. Newline ('\n') rules * Definition/declaration of functions All keywords related with signature should be in same line. (extern/static, return type, parameters) When the signature is too long to represent in single line, try to break in parameters. * Space between function & etc. Use single newline to split paragraph in function code blocks. Use double newline to distinguish between function definitions. No need to use additional newline for declaring multiple functions. 3. Spacing rules * Control-flow statements Split control-flow statements, conditions, bracket with spaces. * Definition/declaration of functions Do not split function name and its parameter definition. * Calling functions Do not split argument passing parenthesis of function call. Signed-off-by: JaeSang Yoo <[email protected]>
* declare conversion functions near its related constants definition * change magic numbers (conversion result) into constants Signed-off-by: JaeSang Yoo <[email protected]>
@onting Would you mind giving me write access? P.S. I won't force merge every PRs as what I want. I'll take some time to review other's opinions. |
Got it, you'll get it soon. |
It seems you already have maintainer access. |
I thought I didn't have enough permission because I cannot merge PR immediately. |
* Prefer use single line comment with // * To describe simple comment about codeblock below * To describe after the code line * Prefer use multiple line comment with /* */ * Always use /* */ for multiple line comment * To emphasize code block below (ex. Interface Implementation) * Documentation such as doxygen (not applied yet) Signed-off-by: JaeSang Yoo <[email protected]>
* Defines coding convention * Rules are proposed in commit bb79de2, 9b76bfe, 5c22882 * General rules are refereneced from zeromq Signed-off-by: JaeSang Yoo <[email protected]>
@onting I wrote coding convention rules document. Please check and leave your opinion. |
Seems great!(although it seems little bit strict) |
It will be automatically matched using automate tool. I'm researching on it. |
As mentioned in #46, there are mixed tabs and spaces for indent, using both comment styles without any reason, spacing between keywords, and other miscellaneous things.
I have referenced some details about coding style from libzmq
Detailed rules that I propose are described in 9b76bfe
TODO: