Add guides around code organization and file formatting #3
Conversation
FMS is a large code base without much consistency in how its organized on a file level. Models, controllers, and tests all have different code groupings which this commit seeks to standardize.
| end | ||
| ``` | ||
|
|
||
| ### Model File Organization |
There was a problem hiding this comment.
Where do non-default scopes go in this setup? I'd suggest they go right after the associations, but I'm not committed to that.
There was a problem hiding this comment.
I've always put them before public class methods, since they're more or less just chainable class methods.
|
|
||
| ```ruby | ||
| describe User do | ||
| describe('Default Scope') do |
There was a problem hiding this comment.
I'm a believer that scopes should not be tested (at least not a a unit test level), so I would leave this example out.
There was a problem hiding this comment.
I tend to agree and gets me thinking that there should probably be a testing do's and dont's page in this guide too. @bgibbons0531 said this in a thread in Slack on 01-22-2018:
Would make it more... friendly... to add tests as a visiting dev too. When I add things to FMS, I figure I should add a test around it (even if super small), look through test code base, and then think to myself maybe it's not that important
Even just a list of things that must be tested before opening a pull request because I was on the same page with him in that I didn't know which tests I should include in my first PR.
FMS is a large code base without much consistency in how its organized on a file level. Models, controllers, and tests all have different code groupings which this commit seeks to standardize.
This is just a rough first draft. I realize code organization is probably a contentious topic for some so I'd like as much feedback as possible.
The end goal, and what @adamnengland and I discussed, is to create some checks in Pronto to ensure files are organized according to the standards we all agree on here.
This style guide is great, but it's a passive resource. If we can get more checks for things like this (and commit messages, which I've discussed a bit with @thetimbanks) I think we'd see a marked increase in our code quality.