Skip to content
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

Draft
wants to merge 5 commits into
base: develop
Choose a base branch
from

Conversation

JSYoo5B
Copy link
Member

@JSYoo5B JSYoo5B commented Apr 8, 2022

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:

  • Set rules for using each comment styles
  • Automate coding style match & check
  • Documentation about coding style

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]>
@JSYoo5B JSYoo5B changed the base branch from main to develop April 8, 2022 11:27
@JSYoo5B
Copy link
Member Author

JSYoo5B commented Apr 8, 2022

@onting Would you mind giving me write access?
It seems I can't do write access to this repository.

P.S. I won't force merge every PRs as what I want. I'll take some time to review other's opinions.

@JSYoo5B JSYoo5B marked this pull request as draft April 8, 2022 11:37
@JSYoo5B JSYoo5B closed this Apr 8, 2022
@JSYoo5B JSYoo5B deleted the code-formatting branch April 8, 2022 11:39
@JSYoo5B JSYoo5B restored the code-formatting branch April 8, 2022 11:39
@JSYoo5B JSYoo5B reopened this Apr 8, 2022
@onting
Copy link
Collaborator

onting commented Apr 8, 2022

@onting Would you mind giving me write access? It seems I can't do write access to this repository.

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.

@onting
Copy link
Collaborator

onting commented Apr 8, 2022

It seems you already have maintainer access.
Please check again.

@JSYoo5B
Copy link
Member Author

JSYoo5B commented Apr 9, 2022

It seems you already have maintainer access. Please check again.

I thought I didn't have enough permission because I cannot merge PR immediately.
It seems every PR needs review to get merged.
I'll try later when the PR is fully ready.

* 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]>
@JSYoo5B
Copy link
Member Author

JSYoo5B commented Apr 15, 2022

@onting I wrote coding convention rules document.

Please check and leave your opinion.
(ex. this rule is too strict, this rule is ambiguous, need new rules, etc...)

@onting
Copy link
Collaborator

onting commented Apr 17, 2022

Seems great!(although it seems little bit strict)
I'd prefer to apply without bracket rules.
I like the style allowing both(bracket in same line, separate line) rules.
Thank you very much.
@JSYoo5B

@JSYoo5B
Copy link
Member Author

JSYoo5B commented Apr 17, 2022

I'd prefer to apply without bracket rules.
I like the style allowing both(bracket in same line, separate line) rules.

It will be automatically matched using automate tool. I'm researching on it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants