We love pull requests. Here's a quick guide:
-
Fork the repo.
-
Run the tests. We only take pull requests with passing tests, and it's great to know that you have a clean slate:
bundle && bundle exec rake -
We are using RuboCop because we love static code analyzers.
- Ways to run RuboCop:
bundle exec rubocopbundle exec rakewould run the test suite and after that it runs the Ruby static code analyzer.
- Ways to run RuboCop:
-
Please add a test for your change. Only refactoring and documentation changes require no new tests. If you are adding functionality or fixing a bug, we need a test! We use Minitest in this project.
-
Make the test pass. Always use
sample,shuffle, andrandfrom the Base class (just like the rest of the code) rather thanArray#sample,Array#shuffleandKernel#randto preserve the deterministic feature. -
We care about code coverage and use
SimpleCovto analyze the code and generate test coverage reports. It's possible to check the test coverage by runningopen coverage/index.html. Please make sure to not decrease ourcurrent % coveredand add appropriate test cases when necessary. -
When adding a new class, add a new yaml file to
lib/locales/enrather than adding translations tolib/locales/en.yml. For example, if you add Faker::MyThing, put your translations inlib/locales/en/my_thing.yml. See the locale README for more info. -
When removing a method, don't forget to deprecate it. You can
extend Gem::Deprecateand use thedeprecatemethod to accomplish this task. -
Methods with optional arguments should use keyword rather than positional arguments. An exception to this could be a method that takes only one optional argument, and it's unlikely that that method would ever take more than one optional argument.
-
Push to your fork and submit a pull request.
For those of you with commit access, please check out Scott Chacon's blog post about github flow
- Anything in the master branch is deployable
- To work on something new, create a descriptively named branch off of master (ie: new-oauth2-scopes)
- Commit to that branch locally and regularly push your work to the same named branch on the server
- When you need feedback or help, or you think the branch is ready for merging, open a pull request
- After someone else has reviewed and signed off on the feature, you can merge it into master
If you're reviewing a PR, you should ask yourself:
- Does it work as described? A PR should have a great description.
- Is it understandable?
- Is it well implemented?
- Is it well tested?
- Is it well documented?
- Is it following the structure of the project?
Include YARD style docs for all methods that includes:
- A short description of what the method generates
- Descriptions for all params (
@param) - The return type (
@return) - At least one example of the output (
@example) - The version that the method was added (
@faker.version)- Set as
nextfor new methods
- Set as
##
# Produces a random string of alphabetic characters, (no digits)
#
# @param char_count [Integer] The length of the string to generate
#
# @return [String]
#
# @example
# Faker::Alphanumeric.alpha #=> "kgdpxlgwjirlqhwhrebvuomdcjjpeqlq"
# Faker::Alphanumeric.alpha(number: 10) #=> "zlvubkrwga"
#
# @faker.version next
def alpha(number: 32)
# ...
endPlease follow these guidelines when adding new code:
- Two spaces, no tabs.
- No trailing whitespace. Blank lines should not have any space.
- Prefer
&&,||overand,or. MyClass.my_method(my_arg)notmy_method( my_arg )ormy_method my_arg.a = band nota=b.- In general, follow the conventions you see used in the source already.
- ALL SHALL OBEY THE RUBOCOP
Please use dash syntax for yaml arrays:
# instead of these
b_things: [small_thing, big_thing, other_thing]
c_things: [
small_thing,
big_thing,
other_thing,
]
# this is preferred
a_things:
- small_thing
- big_thing
- other_thing- If in doubt,
bundle exec rake reformat_yaml['lib/path/to/file.yml']
- Use the
rake consoletask to start a session with Faker loaded. - Use
bundle exec yard server -rto launch the YARD Doc server