Skip to content

Commit

Permalink
Style Corrections
Browse files Browse the repository at this point in the history
  • Loading branch information
maxtyson123 committed Jan 5, 2024
1 parent ae545fa commit 626cb7e
Show file tree
Hide file tree
Showing 106 changed files with 5,402 additions and 7,159 deletions.
2 changes: 1 addition & 1 deletion .github/ISSUE_TEMPLATE/feature_request.md
Original file line number Diff line number Diff line change
@@ -1,7 +1,7 @@
---
name: Feature request
about: Suggest an idea for this project
title: ''
m_title: ''
labels: ''
assignees: ''

Expand Down
4 changes: 2 additions & 2 deletions README.md
Original file line number Diff line number Diff line change
Expand Up @@ -53,8 +53,8 @@ Kernel Cleanup
- [x] Cross-Compiler
- [x] Better Scripts
- [x] GUI Bug Fixes
- [ ] Better Commenting and Doxygen Documentation
- [ ] Use better c++ coding conventions
- [x] Better Commenting and Doxygen Documentation
- [x] Use better c++ coding conventions
- [ ] CMAKE Build System (and maybe get it building and debugging in CLion)
- [ ] Clean up all the TODOs
- [ ] Rewrite Readme
Expand Down
18 changes: 0 additions & 18 deletions docs/Bugs.md

This file was deleted.

6 changes: 3 additions & 3 deletions docs/CONTRIBUTING.md
Original file line number Diff line number Diff line change
Expand Up @@ -16,7 +16,7 @@ To keep the code understanble please make sure it is formatted and reable. Addit
## We Use [GitHub Flow](https://guides.github.com/introduction/flow/index.html), So All Code Changes Happen Through Pull Requests
Pull requests are the best way to propose changes to the codebase (we use [GitHub Flow](https://guides.github.com/introduction/flow/index.html)). We actively welcome your pull requests:

1. Fork the repo and create your branch from `master`.
1. Fork the repo and create your branch from `m_is_master`.
2. If you've added code that should be tested, add tests.
3. If you've changed APIs, update the documentation.
4. Ensure the test suite passes.
Expand All @@ -26,12 +26,12 @@ Pull requests are the best way to propose changes to the codebase (we use [GitHu
## Report bugs using GitHub's [issues](https://github.com/briandk/transcriptase-atom/issues)
We use GitHub issues to track public bugs. Report a bug by [opening a new issue](); it's that easy!

## Write bug reports with detail, background, and sample code
## write bug reports with detail, m_background, and sample code
[This is an example](http://stackoverflow.com/q/12488905/180626) of a bug report someone wrote, and I think it's not a bad model. Here's [another example from Craig Hockenberry](http://www.openradar.me/11905408), an app developer whom I greatly respect.

**Great Bug Reports** tend to have:

- A quick summary and/or background
- A quick summary and/or m_background
- Steps to reproduce
- Be specific!
- Give sample code if you can. [This stackoverflow question](http://stackoverflow.com/q/12488905/180626) includes sample code that *anyone* with a base R setup can run to reproduce what I was seeing
Expand Down
2 changes: 1 addition & 1 deletion docs/Goals.md
Original file line number Diff line number Diff line change
Expand Up @@ -59,6 +59,6 @@

# Other
- Clipboard
- Privelges (Rings, Read/Write)
- Privelges (Rings, read/write)
- Apps installer
- App store
94 changes: 47 additions & 47 deletions docs/Notes.md

Large diffs are not rendered by default.

29 changes: 29 additions & 0 deletions docs/Styles/ClionCodeStyleSettings.xml
Original file line number Diff line number Diff line change
@@ -0,0 +1,29 @@
<code_scheme name="Project" version="173">
<Objective-C>
<option name="TYPE_QUALIFIERS_PLACEMENT" value="AFTER" />
</Objective-C>
<Objective-C-extensions>
<option name="TYPE_QUALIFIERS_PLACEMENT" value="AFTER" />
<rules>
<rule entity="NAMESPACE" visibility="ANY" specifier="ANY" prefix="" style="PASCAL_CASE" suffix="" />
<rule entity="MACRO" visibility="ANY" specifier="ANY" prefix="" style="SCREAMING_SNAKE_CASE" suffix="" />
<rule entity="CLASS" visibility="ANY" specifier="ANY" prefix="" style="PASCAL_CASE" suffix="" />
<rule entity="STRUCT" visibility="ANY" specifier="ANY" prefix="" style="PASCAL_CASE" suffix="" />
<rule entity="ENUM" visibility="ANY" specifier="ANY" prefix="" style="PASCAL_CASE" suffix="" />
<rule entity="ENUMERATOR" visibility="ANY" specifier="ANY" prefix="" style="PASCAL_CASE" suffix="" />
<rule entity="TYPEDEF" visibility="ANY" specifier="ANY" prefix="" style="SNAKE_CASE" suffix="" />
<rule entity="UNION" visibility="ANY" specifier="ANY" prefix="" style="SNAKE_CASE" suffix="" />
<rule entity="CLASS_MEMBER_FUNCTION" visibility="ANY" specifier="ANY" prefix="" style="SNAKE_CASE" suffix="" />
<rule entity="STRUCT_MEMBER_FUNCTION" visibility="ANY" specifier="ANY" prefix="" style="SNAKE_CASE" suffix="" />
<rule entity="CLASS_MEMBER_FIELD" visibility="ANY" specifier="ANY" prefix="" style="SNAKE_CASE" suffix="" />
<rule entity="STRUCT_MEMBER_FIELD" visibility="ANY" specifier="ANY" prefix="" style="SNAKE_CASE" suffix="" />
<rule entity="GLOBAL_FUNCTION" visibility="ANY" specifier="ANY" prefix="" style="SNAKE_CASE" suffix="" />
<rule entity="GLOBAL_VARIABLE" visibility="ANY" specifier="ANY" prefix="" style="SNAKE_CASE" suffix="" />
<rule entity="PARAMETER" visibility="ANY" specifier="ANY" prefix="" style="SNAKE_CASE" suffix="" />
<rule entity="LOCAL_VARIABLE" visibility="ANY" specifier="ANY" prefix="" style="SNAKE_CASE" suffix="" />
</rules>
</Objective-C-extensions>
<clangFormatSettings>
<option name="ENABLED" value="true" />
</clangFormatSettings>
</code_scheme>
Loading

0 comments on commit 626cb7e

Please sign in to comment.