challenge: subtract_two_numbers_challenge

[GeehanAli]

---

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

Behavior

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
  • It's ok to have extra helper functions if necessary, like with mergesort
• The function has correct type annotations
• The function is not called at the top level of the function file
  • Recursive solutions can call the function from inside the function body

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 any docstrings or tests
• 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

[misik-eng]

I believe You could have done it with one branch but sometimes it is easier to create a new one and start from clear page, I know , hehe , It looks awesome and clear.

One more thing I'd like to mention: Gennadii suggested committing more frequently during development, and I think it's a great idea. This approach can really help with tracking progress and reviewing changes step by step.

But your challenge looks good, Approved

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
  • Comment: You have defensive assertions to handle non-numeric inputs correctly.
• There are tests for boundary cases
  • Comment: Boundary cases like large numbers and zero are well-tested.

---

Function Docstring

• The function's behavior is described
• The function's arguments are described:
  • Type
  • Purpose
• The return value is described:
  • Type
• The defensive assertions are documented using Raises:
  • Comment: Consider specifying the exact error raised (e.g., TypeError) in the docstring.
• Include 3 or more (passing!) doctests
  • Comment: Great job including multiple doctests that validate expected behavior.

---

The Function

• The function's name describes its behavior
• The function's name matches the file name
• The function has correct type annotations
• The function is not called at the top level of 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

---

Implementation

• The code passes the formatting checks
• The code passes all Ruff linting checks
• The code has no (reasonable) Pylint errors
• Variables are named with snake_case
  • Comment: Variable names are consistent with PEP 8.
• The code follows the strategy as simply as possible
• There are no commented lines of code
• There are no print statements anywhere
• The code includes defensive assertions
  • Comment: Defensive checks for argument types are appropriate.
• Defensive assertions include as little logic as possible