challenge: factorial_36

[MPKenley]

---

name: solution review factorial
about: A template PR for code review with a checklist

Behavior

The factorial function calculates the factorial of a given number using a recursive approach. The factorial of a non-negative integer n is the product of all positive integers less than or equal to n. It is often denoted as n!.

Arguments:
n (int): The non-negative integer whose factorial is to be calculated.

Returns:
The function returns an integer representing the factorial of n.

Behavior:
The function takes a non-negative integer n as an argument.

It checks if n is equal to 0. If so, it returns 1, as 0! is defined to be 1.

If n is not equal to 0, the function recursively calls factorial(n - 1) and multiplies the result by n.

This process continues until n reaches 0, where each recursive call returns the product of the integers up to that point.

Example:

print(factorial(5)) # Prints 120, as 5! = 5 * 4 * 3 * 2 * 1
print(factorial(0)) # Prints 1, as 0! = 1

Files

• The file name describes the function's behavior
• There is a module docstring in the function file
• The test file's name matches the function file name -
  /tests/test_file_name.py
• There is a module docstring in the tests file

Unit Tests

• The test class has a helpful name in PascalCase
• The test class has a docstring
• Every unit test has
  • A helpful name
  • A clear docstring
  • Only one assertion
  • There is no logic in the unit test
• All tests pass
• There are tests for defensive assertions
• There are tests for boundary cases

Function Docstring

• The function's behavior is described
• The function's arguments are described:
  • Type
  • Purpose
  • Other assumptions (eg. if it's a number, what's the expected range?)
• The return value is described
  • Type
  • Other assumptions are documented
• The defensive assertions are documented using Raises:
  • Each assumption about an argument is checked with an assertion
  • Each assertion checks for only one assumption about the argument
• Include 3 or more (passing!) doctests

The Function

• The function's name describes it's behavior
• The function's name matches the file name
• The function has correct type annotations
• The function is not called in the function file

Strategy

Do's

• Variable names help to understand the strategy
• Any comments are clear and describe the strategy
• Lines of code are spaced to help show different stages of the strategy

Don'ts

• The function's strategy is not described in the documentation
• Comments explain the strategy, not the implementation
• The function does not have more comments than code
  • If it does, consider finding a new strategy or a simpler implementation

Implementation

• The code passes the formatting checks
• The code passes all Ruff linting checks
• The code has no (reasonable) Pylint errors
  • In code review, you can decide when fixing a Pylint error is helpful and
    when it's too restricting.
• Variables are named with snake_case
• Variable names are clear and helpful
• The code follows the strategy as simply as possible
• The implementation is as simple as possible given the strategy
• There are no commented lines of code
• There are no print statements anywhere
• The code includes defensive assertions
• Defensive assertions include as little logic as possible

[SEMIRATESFAI]

Suggestions for Improvement:

1. Module Docstring in Test File: Add a descriptive docstring at the top of the test file to explain its purpose.
2. Test Method Names: Use more descriptive names for the test methods. For example, rename test_factorial_positive to test_factorial_with_positive_numbers.
3. Test Method Logic: Separate logic within test methods into individual methods for clarity and simplicity.
4. Function Docstring: Mention the assumption that the input should be a non-negative integer and document any assumptions about the return value.
5. Doctests: Include at least 3 passing doctests in the function docstring to demonstrate its behavior.
6. Function Call: Ensure the function is only called under if name == "main".
7. Linting Checks: Run Ruff linting checks and address any issues to ensure code quality.
   This review ensures that the factorial.py solution code and its test file meet all requirements.

[MPKenley]

Hello @SEMIRATESFAI

I have made the requested changes to the code according to your review. Could you please take another look and let me know if everything is now correct?

thank you for your time and feedback.

[SEMIRATESFAI]

Hello @SEMIRATESFAI

I have made the requested changes to the code according to your review. Could you please take another look and let me know if everything is now correct?

thank you for your time and feedback.

It looks like your factorial.py code adheres well to the checklist criteria. Great job!

[SEMIRATESFAI]

It looks like your factorial.py code adheres well to the checklist criteria. Great job!

[SEMIRATESFAI]

It looks like your factorial.py code adheres well to the checklist criteria. Great job!

[SEMIRATESFAI]

Great Job on the changes you have made!

[SEMIRATESFAI]

great job updating what was required.