formatting

Author: MMathisLab

README.md

@@ -57,7 +57,7 @@ project_name/
 
    * Formatted code makes your life and those who use/review your code easier. Standardized formatting with tools like `black` and `isort` (see the provided `.pre-commit-config.yaml`).
    * [Pre-commit hooks](https://pre-commit.com/) to automate checks before pushing code! Follow their quick Guide to do this, but in short:
-   
+
    (1) install it in your dev env
    ```python
       pip install pre-commit
@@ -85,12 +85,12 @@ project_name/
 
    * [DataJoint](https://www.datajoint.com/) examples for managing and querying scientific data pipelines - these are a must; use minimally for data + meta data storage, and use it to automate things you do daily (preprocessing, running DeepLabCut, etc!)
    * [Templates for common workflows and schema management are here!](https://docs.datajoint.com/elements/)
-  
+
 
 7. **Style Guide for overall code & project management**
 
    * Tips and practices for code, manuscripts, and figures.
-   
+
 
 ---
 

_toc.yml

@@ -7,4 +7,3 @@ parts:
   - file: docs/DEV_GUIDE
   - file: docs/Learning_resources
   - file: docs/HowTo_JupyterBook
-  

docs/DEV_GUIDE.md

@@ -13,7 +13,7 @@
 1. **Be Constructive and Respectful**
    - Focus on the code, not the person 🔐
    - Provide clear, actionable feedback 🚧
-   - Explain the "why" behind your suggestions 
+   - Explain the "why" behind your suggestions
    - Use a positive and encouraging tone 💜
 
 2. **Review Checklist**
@@ -96,7 +96,7 @@
 
 ## Collaborative Coding Guidelines
 
-Each project is different, so please check project-specific guidelines. 
+Each project is different, so please check project-specific guidelines.
 However, below is a guide for collaborative projects in general.
 I recommend the following system for within-lab projects that have different levels of maintainers & builders.
 
@@ -108,7 +108,7 @@ I recommend the following system for within-lab projects that have different lev
    - No one person is the gate-keeper for the project: work together
 2. **Get a review assignment system in place**
    - 🟥 Make a flag for **major dev/changes**: all users of the code should agree and sign off (git reviews), and this includes the PI.
-   - 🟧 Make a flag for **user-needs**: this is needed to stop a block -- it might not be perfect, so make an issue to revisit later. 1 sign off from another user, and go! 🚀 
+   - 🟧 Make a flag for **user-needs**: this is needed to stop a block -- it might not be perfect, so make an issue to revisit later. 1 sign off from another user, and go! 🚀
    - 🟩 Make a flag for **minor change**: not breaking, can be changed later, 1 sign off okay
 
 ### Git Workflow
@@ -137,7 +137,7 @@ I recommend the following system for within-lab projects that have different lev
 
 1. **Team Communication**
    - Use appropriate channels for different purposes - use basecamp campfire and github issues/PRs
-   - Be clear and concise 
+   - Be clear and concise
    - Document important decisions!!
    - Share knowledge and learnings
 
@@ -200,13 +200,13 @@ We use the Google Style Guide: https://google.github.io/styleguide/
    - Spaces after commas and semicolons
 
 4. **Naming Conventions**
-   - Variables: `lower_snake_case`  
-   - Functions: `lower_snake_case`  
-   - Classes: `PascalCase`  
-   - onstants: `UPPER_SNAKE_CASE`  
-   - Files: `lower_snake_case.py`  
-   - Private members: `_single_leading_underscore`  
-   - Modules/Packages: `lower_snake_case`  
+   - Variables: `lower_snake_case`
+   - Functions: `lower_snake_case`
+   - Classes: `PascalCase`
+   - onstants: `UPPER_SNAKE_CASE`
+   - Files: `lower_snake_case.py`
+   - Private members: `_single_leading_underscore`
+   - Modules/Packages: `lower_snake_case`
    - Interfaces: `PascalCase` (same as classes, no special prefix)
 
 5. **Comments**
@@ -270,4 +270,4 @@ We use the Google Style Guide: https://google.github.io/styleguide/
 
 ---
 
-Remember: These guidelines are living documents. Feel free to suggest improvements and updates as the team evolves and learns. 
+Remember: These guidelines are living documents. Feel free to suggest improvements and updates as the team evolves and learns.

docs/HowTo_JupyterBook.md

@@ -40,5 +40,3 @@ To then deploy the book live, see: https://jupyterbook.org/en/stable/publish/gh-
 In short, Go to Settings > Pages and set up anaction to deploy to a new branch (that you never merge) called `gh-pages`:
 
 ![Screen Shot 2025-06-17 at 2 20 19 PM](https://github.com/user-attachments/assets/17d13802-6543-4859-ac09-7abbd491277d)
-
-

docs/StyleGuide.md

@@ -5,7 +5,7 @@
 
 Please see our overall guide on code & project formatting [here](https://github.com/AdaptiveMotorControlLab/WorkspaceTemplate/blob/main/README.md).
 
-### Main Principles 🔨 Organize your code & data: 
+### Main Principles 🔨 Organize your code & data:
 - For experimental and ML projects, please use [DataJoint/databases](https://www.datajoint.com/)
 - Be sure you work under a lab repo, typically called "https://github.com/AdaptiveMotorControlLab/YourName_workspace".
 - For larger projects (DLC, CEBRA, ExperimentalPipelines, you should be sure your "final" work gets into a pipeline; talk to Mackenzie about this)
@@ -19,7 +19,7 @@ Please see our overall guide on code & project formatting [here](https://github.
 
 
 
-## Ready to write up your work and share your hard work, data, & code? 
+## Ready to write up your work and share your hard work, data, & code?
 Here is how to do so most efficiently with me.
 
 - 🚨 First, I recommend having a one-on-one so we can lay out the paper sketch, authors, data and code sharing plan together if not already done.
@@ -92,10 +92,10 @@ ax.xaxis.label.set_color("white")
 ```
 
 
-### Timeline Major Point: 
+### Timeline Major Point:
 
-For conference submissions, all papers must be in final form 1 week prior to the deadline. 
-There will be no exceptions going forward. 
-This gives us needed time to reflect, refine writing, get some distance, and ask colleagues for feedback. 
-It also gives us time to prepare the code submission, and potentially arXiv the work -- which is always preferred. 
-We should not be submitting manuscripts to conferences we would not want publicly read! 
+For conference submissions, all papers must be in final form 1 week prior to the deadline.
+There will be no exceptions going forward.
+This gives us needed time to reflect, refine writing, get some distance, and ask colleagues for feedback.
+It also gives us time to prepare the code submission, and potentially arXiv the work -- which is always preferred.
+We should not be submitting manuscripts to conferences we would not want publicly read!