Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fevzi palindrome checker #34

Merged
merged 9 commits into from
Jan 13, 2025
Merged

Fevzi palindrome checker #34

merged 9 commits into from
Jan 13, 2025

Conversation

fevziismailsahin
Copy link
Member

@fevziismailsahin fevziismailsahin commented Jan 11, 2025


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
  • 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

@fevziismailsahin fevziismailsahin self-assigned this Jan 11, 2025
@fevziismailsahin fevziismailsahin linked an issue Jan 12, 2025 that may be closed by this pull request
@Vahablotfi Vahablotfi self-requested a review January 12, 2025 06:20
Copy link

@Vahablotfi Vahablotfi left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You’ve done a great job ensuring that the main functionality works as expected, and the code is easy to read. The examples you’ve provided in the docstring and the test cases effectively demonstrate the intended behavior of the function. Great work!

Overall, this is a great implementation of a palindrome checker, and with a few adjustments, it will align perfectly with the code review checklist and be even more robust and comprehensive.

Here are some points to consider for further improvement:

Consider adding checks to validate the input type. For example, ensure the function argument is a list and that its elements are strings or numbers.

This will make the function more robust and handle unexpected input gracefully. Document these checks in the docstring under a "Raises" section.

The return value section could specify more about the function's side effects ("prints the result of each palindrome check to the console").

Each test (unit test) currently includes multiple assertions. To better align with the checklist, consider splitting these into smaller, focused tests with a single assertion each.

Add tests for edge cases, such as:
Empty strings or lists.
Inputs with mixed data types (e.g., non-string/non-numeric elements in the list).
Very large strings or numbers.
Add tests to verify that invalid inputs raise appropriate exceptions.

@fevziismailsahin
Copy link
Member Author

I completed the missing parts. Suitable for merge pull request

Copy link

@Vahablotfi Vahablotfi left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Excellent work! This is a well-structured and thoughtful solution Keep it up!

@Vahablotfi Vahablotfi merged commit 6047d24 into main Jan 13, 2025
10 checks passed
@fevziismailsahin fevziismailsahin deleted the fevzi_palindrome_checker branch January 13, 2025 03:58
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Development

Successfully merging this pull request may close these issues.

Challenge: Palindrome Checker
2 participants