Contributing to LDR Importer

So, you want to to help out with the development of LDR Importer? First off, thank you for your interest! Before you begin though, you need to read some simple guidelines to help make LDR Importer the best it can be!

Getting Started

1. Start by forking the repository by clicking
2. Clone the script onto your computer by running git clone https://github.com/yourusername/LDR-Importer.git or if you are using a GUI client, however you clone repositories.
3. Read up on the code and project layout and guidelines below.
4. Edit away! A list of stuff to do are filed in project Issues. Make a new branch off the branch you want to merge into and commit to it. This way, there will be fewer merge conflicts when you submit a pull request.
5. Once you finish your work, submit a pull request by clicking
6. If everything checks out, your changes will be merged! :D
7. Don't forget to share the project with your friends and

Code Style

• PEP 8 should be followed at all times. Line length should be followed when possible (it is not always feasible to keep lines at 79 characters. You can use the PEP8 online website to check for errors.
• A Travis CI builder is attached to automatically check the script for any errors. More documentation on that can be found on the Travis CI Builder page.
• The Blender Python API style guidelines, which is mainly a small extension of PEP 8.
• Use double quotes (" ") when possible. For multi-line strings, use triple quotes (""" """).
• Function names and variables should try to follow the camelCase convention at all times.
• str.format() is the preferred way to join strings and variables in a single statement.
  • If a single line string is more than 79 characters and does not need to be on a second line, use str.format() to keep it on one line and wrap the extended string on the next physical line. It is better than the % operator, and using + (plus) signs is just bad practice. ;)
• Always trim white space from the end of lines and blank lines.
• Please try to document your code as much as possible. It is understood you may not have the time to and others might need to do it, but if you do have the time do document, go right ahead and do it and perhaps whatever else may need it!

Separate Branches

• The master branch is where stable, complete, mostly bug-free code belongs. It is this script that will make up the next, official release. If someone wanted to download a pre-release version and not worry about it being broken, they would download this branch.
• Feature branches are created when large changes need to be made or tested, and it does not need to be done in the master branch. Both forks and the main repository should follow this. This make the process of merging pull requests easier and allows the code to be reviewed and corrected before getting merged into the master.
• There occasionally may be branches that do not fit into these two categories. Please refer to any open issue or pull request associated with them to learn their purpose.