Currently, we are looking into clang-format. This should be part of the build pipeline as well to make sure all source code is properly formated using a single style.
Add an additional document with code style rules that are not covered by the clang formatter file, e.g.
always add javadoc style documentation to "public" functions
naming conventions for functions, variables, namespacing modules etc
Currently, we are looking into clang-format. This should be part of the build pipeline as well to make sure all source code is properly formated using a single style.
Add an additional document with code style rules that are not covered by the clang formatter file, e.g.
- always add javadoc style documentation to "public" functions
- naming conventions for functions, variables, namespacing modules etc
May be good to also include some architectural considerations in that supplementary document,
to get people up to speed on patterns for how things are commonly implemented inside bemanitools?
In GitLab by @praxis on Sep 28, 2019, 23:23
May be good to also include some architectural considerations in that supplementary document,
to get people up to speed on patterns for how things are commonly implemented inside bemanitools?
Yeah, that sounds like a very useful thing to have to get people onboarded much faster. I try to come up with the fundamental things to get something like a design document kicked off. However, if you or anyone else feels that there is something missing, input is required.
Yeah, that sounds like a very useful thing to have to get people onboarded much faster. I try to come up with the fundamental things to get something like a design document kicked off. However, if you or anyone else feels that there is something missing, input is required.
I created a new issue to address this: #27
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Currently, we are looking into clang-format. This should be part of the build pipeline as well to make sure all source code is properly formated using a single style.
Add an additional document with code style rules that are not covered by the clang formatter file, e.g.
In GitLab by @praxis on Sep 28, 2019, 23:23
May be good to also include some architectural considerations in that supplementary document,
to get people up to speed on patterns for how things are commonly implemented inside bemanitools?
Yeah, that sounds like a very useful thing to have to get people onboarded much faster. I try to come up with the fundamental things to get something like a design document kicked off. However, if you or anyone else feels that there is something missing, input is required.
I created a new issue to address this: #27
mentioned in commit
6741a1f2fdMerged !6
closed