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

Complete Writing High Quality Code for Contributing.MD #208

Closed
ArielSAdamsNASA opened this issue Mar 4, 2021 · 2 comments · Fixed by #218 or #227
Closed

Complete Writing High Quality Code for Contributing.MD #208

ArielSAdamsNASA opened this issue Mar 4, 2021 · 2 comments · Fixed by #218 or #227
Labels

Comments

@ArielSAdamsNASA
Copy link
Contributor

Is your feature request related to a problem? Please describe.
Provide instructions to users on how to write high quality code.

Describe the solution you'd like
Complete the Writing High Quality Code section to add to the Contributing Guide.

Additional context
The draft so far:

Writing High-Quality Code

  1. Follow cFS code conventions (formatting, symbol naming, file naming, etc) but do not change/reformat existing code except to address your changes.

  2. For any new API's, add unit tests to cover nominal and off-nominal conditions.

  3. Add/edit stubs to the unit test codebase for any new/modified functions.

  4. For any changes to existing API's, alter the unit tests to cover the changes (and remove tests made irrelevant due to your changes).

  5. Test your code, on a Linux platform (at minimum) --
    TODO: Specific distros/versions/CPU architectures of Linux?

  6. Build your code, including unit tests.
    TODO: need "standard" build process.

  7. Run the unit tests (all passed, yes?)
    TODO: need "standard" test procedure.

  8. Run the main cfs executable (no errors reported, yes?)
    TODO: need "standard" test procedure, including targets.cmake recommendations.

  9. ?? Do we expect contributors to run coverage ?? Guessing no.

Requester Info
Ariel Adams, ASRC Federal

@skliper
Copy link
Contributor

skliper commented Mar 4, 2021

One option for 5-9 is to simply provide instructions for how to trigger all the GitHub actions that perform all these activities for the user. Could also reference the implementations of those actions from the documentation for the definitive/working instructions vs duplicating the instructions in documentation which could get out of sync. It's even easier if the actions are set to run on all pushes, then a user can simply push a bundle branch to their fork and see that everything passes (or not).

@ArielSAdamsNASA
Copy link
Contributor Author

One option for 5-9 is to simply provide instructions for how to trigger all the GitHub actions that perform all these activities for the user.

I personally prefer this option.

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

Successfully merging a pull request may close this issue.

2 participants