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

Consider enforcing a consistent coding style and naming convention #169

Open
robinkrahl opened this issue Jan 12, 2020 · 4 comments
Open

Comments

@robinkrahl
Copy link
Contributor

Currently, the coding style in the C++ and C source code is often inconsistent (indentation, spacing, brace placement, …). Sometimes this makes it hard to read the code. Would you consider defining a consistent coding style and using a tool like clang-format to enforce it?

Also, most files use the cc extension, except DeviceCommunicationExceptions.cpp. Some files use camel case (NitrokeyManager.cc) and some only lower case (device.cc). Would you agree to a consistent naming scheme?

@szszszsz szszszsz added this to the v3.6 milestone Jan 13, 2020
@szszszsz
Copy link
Member

szszszsz commented Jan 13, 2020

Hi!
Of course! Sorry for that. I plan large refactoring/clean up (this/next month), including code reformat, which hopefully will decrease the confusion here.

Back then I was avoiding code whitespace reformat to keep the ability of clean patches revert, and easy to find sources of the changes. Now I plan to add a style check as a part of CI and git hooks, which would prevent such issues.

@robinkrahl
Copy link
Contributor Author

robinkrahl commented Jan 13, 2020 via email

@robinkrahl
Copy link
Contributor Author

I plan large refactoring/clean up (this/next month), including code reformat, which hopefully will decrease the confusion here.

Do you have an update on this? I have some patches I’d like to submit, but I think it would be better to wait for the refactoring.

@szszszsz
Copy link
Member

szszszsz commented Apr 2, 2020

Hi!
Sorry for the delay. Feel free to submit the patches, I will handle them on refactoring without a problem. I think this is best option, so I will not hold you back with the nitrocli development.

sgued pushed a commit to sgued/libnitrokey that referenced this issue Feb 14, 2022
@szszszsz szszszsz modified the milestones: v3.7, v3.8 Apr 27, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants