Home

iTunes Library Parser

Contributors

Thanks for your interest in contributing. There are few rules to contributing to the library.

Contribution Rules

1. Pull requests should be in response to an open issue and should close the issue in the commit message. Please create an issue prior to issuing a pull request, and make it clear whether you want to fix the issue or not. This gives us a chance to talk about the issue prior to accepting a pull request.
2. Pull requests without a corresponding issue will not be merged until they address an issue.
3. Pull Requests should be short and cover a single feature. Please keep feature implementation, library upgrades, and bug fixes in separate pull requests.
4. API breaking changes should be communicated in the pull request. This will probably delay the merge until we are ready for a new major version release.

Coding Standards

1. I've tried to cover as much of the coding standard formatting rules in the .editorconfig
2. The majority of this library has been written by an XP developer and coach and as such follows a lot of the XP and Clean Code suggestions.
3. The majority of this library was written using TDD. It is expected that all new code comes with new microtests / unit tests and all changes come with tests around the changes. The current coverage is 100%, and while it's not the requirement, the expectation is for it to be very high. We want to be able to push new versions of the nuget package without any manual testing required.
4. The preference is to avoid code comments and instead focus on well-named methods and fields. Where methods and fields cannot convey intent we prefer an intention-revealing test case. If none of this are sufficient then a comment is appropriate. We rely on code comments when all other intention revealing approaches are insufficient.

Design Triggers

We follow some design triggers as described by Sandi Metz. They alone aren't necessarily standards but are typically true so we use these as triggers to indicate that we may need to refactor. Here is the list of our design triggers.

1. Classes should be very small, often not more than 50 LOC and beyond 100 LOC often means the object is doing too much.
2. Methods should be very small, often not more than 5 LOC and beyond 10 LOC often means the method is doing too much.
3. Classes should not have more than three dependencies.