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

Valid anagram (Resolves #94) #95

Merged
merged 17 commits into from
Jan 12, 2025
Merged

Valid anagram (Resolves #94) #95

merged 17 commits into from
Jan 12, 2025

Conversation

fatima-malik99
Copy link

@fatima-malik99 fatima-malik99 commented Jan 12, 2025


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

A function that determines if two strings are anagrams of each other. Two strings are considered anagrams if they contain exactly the same characters with the same frequency, regardless of their order.

Behavior

Input:

  • Two strings (str1 and str2), where each string can contain:
    • Alphabetic characters (both uppercase and lowercase)
    • Numbers
    • Special characters
    • Spaces
    • Empty strings

Output:

  • A boolean value (True or False) where:
    • True: if the strings are valid anagrams of each other
    • False: if the strings are not anagrams

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

@fatima-malik99 fatima-malik99 added documentation Improvements or additions to documentation require-review Pull requests that needs to be reviewd. labels Jan 12, 2025
@fatima-malik99 fatima-malik99 self-assigned this Jan 12, 2025
@fatima-malik99 fatima-malik99 linked an issue Jan 12, 2025 that may be closed by this pull request
@MadiMalik MadiMalik self-requested a review January 12, 2025 12:34
@MadiMalik
Copy link

Overall, great job, Fatima! Your code and documentation are clean, well-structured, and very understandable. I just wanted to point out that your function is case-sensitive, meaning W is not equal to w. However, you don’t have a test case specifically addressing this behavior. Additionally, I think adding a boundary test to handle long inputs would be beneficial. Once again, excellent work!

@mudassra-taskeen mudassra-taskeen self-requested a review January 12, 2025 16:22
@fatima-malik99
Copy link
Author

fatima-malik99 commented Jan 12, 2025

Overall, great job, Fatima! Your code and documentation are clean, well-structured, and very understandable. I just wanted to point out that your function is case-sensitive, meaning W is not equal to w. However, you don’t have a test case specifically addressing this behavior. Additionally, I think adding a boundary test to handle long inputs would be beneficial. Once again, excellent work!

Hi Madiha thanks for your review. I already have a test_case_sensitive for handling it. Also, I will definitely add boundary case for long inputs. Thank you for your feedback.

@mudassra-taskeen
Copy link

Overall, great job, Fatima! Your code and documentation are clean, well-structured, and very understandable. I just wanted to point out that your function is case-sensitive, meaning W is not equal to w. However, you don’t have a test case specifically addressing this behavior. Additionally, I think adding a boundary test to handle long inputs would be beneficial. Once again, excellent work!

Hi Madiha thanks for your review. I already have a test_case_sensitive for handling it. Also, I will definitely add boundary case for long inputs. Thank you for your feedback.

I have not seen any boundary case in your code. You should add them for better performance.

@fatima-malik99
Copy link
Author

Overall, great job, Fatima! Your code and documentation are clean, well-structured, and very understandable. I just wanted to point out that your function is case-sensitive, meaning W is not equal to w. However, you don’t have a test case specifically addressing this behavior. Additionally, I think adding a boundary test to handle long inputs would be beneficial. Once again, excellent work!

Hi Madiha thanks for your review. I already have a test_case_sensitive for handling it. Also, I will definitely add boundary case for long inputs. Thank you for your feedback.

I have not seen any boundary case in your code. You should add them for better performance.

Please check again I added boundary case after Madiha's suggestion.

Copy link

@mudassra-taskeen mudassra-taskeen left a comment

Choose a reason for hiding this comment

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

I have checked both files. Your solution has no error, working fine, and is ready to merge.

@mudassra-taskeen mudassra-taskeen merged commit f896aa9 into main Jan 12, 2025
10 checks passed
@jola-ds jola-ds deleted the valid_anagram branch January 13, 2025 01:47
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
documentation Improvements or additions to documentation require-review Pull requests that needs to be reviewd.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Valid Anagrams Checker
3 participants