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

Code formatting rules #54

Open
Vavat opened this issue Mar 2, 2023 · 2 comments
Open

Code formatting rules #54

Vavat opened this issue Mar 2, 2023 · 2 comments
Assignees
Labels
question Further information is requested

Comments

@Vavat
Copy link
Collaborator

Vavat commented Mar 2, 2023

@Netzpfuscher, hi. David asked me to have a chat with you regarding code clean up. He's aware that he writes horribly formatted code and wanted to pull some resource to have code a bit more maintainable. Since you are a very active contributor, I thought it makes sense to have a discussion with you first before anything is done to find out your opinion and preferences.
I suggest that this issue be dedicated to ironing out two questions:

  • format of the code that we should strive towards
  • manner in which changes to the code formatting should be made

Under format of the code I mean things like naming convention for variables, functions, constants, etc. #define vs. static const. Tab vs. spaces. Brace position. Once those decisions are made quite a bit of that can be automated.

As far as implementation goes I see two options: wait until code reaches reasonable stability and do entire codebase in one hit, or introduce rules and enforce them with every merge request, thus allowing code to morph into acceptable format gradually. I am not sure how confident you are with code stability and whether David and you are happy to stop development to do all changes in one. It introduces certain difficulties in tracing bugs back beyond the formatting changes since diffing becomes much trickier. If this was production grade code for a commercial enterprise I would advocate gradual changes. This is where your input is paramount.

Let me know what you think.

@Vavat Vavat added the question Further information is requested label Mar 2, 2023
@Netzpfuscher
Copy link
Collaborator

I would say that we implement all the stuff we wanted. I'm in heavy development on the CAN/Ethernet/Dashboard stuff. Then we start with the cleaning. There are so many defines everywhere, functions needs to be moved in separate files, remove code duplication... Really don't know where to start.

If we can define rules we can code new stuff based on the rules.

@Vavat
Copy link
Collaborator Author

Vavat commented Mar 2, 2023

OK. Agreed. I'll leave this with you then until you're comfortable to start refactoring.

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

No branches or pull requests

3 participants