Swap_letters review

[TibyanKhalid]

---

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

The function convert all lowercase letters to uppercase letters and vice versa.

Input: string
Return: the modified string

Sample input:
"Hello World"

Output:
"hELLO wORLD"

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

[Frank2446-dotcom]

The docstring is good for keeping track of the file's creation and author. However, it would be more helpful if you included a brief description of the file's purpose or functionality here. For example:

"""This file contains the function Swap_letters that swaps the case of each letter in a string."""

[TibyanKhalid]

Good idea yeah okay I'll do that now

[Frank2446-dotcom]

The docstring is clear and provides example usage (which is good for doctests). However:

Add edge cases in the doctests, such as empty strings, strings with digits, or special characters.

[TibyanKhalid]

I've added the edge cases tests in the tests file already

[Frank2446-dotcom]

The string literal "Make sure the expected input is a string" doesn’t do anything in the code. It should either be removed or converted to a comment:

Make sure the expected input is a string

[TibyanKhalid]

It's just for documenting purposes, it acts as a comment

[Frank2446-dotcom]

The function implementation is clear, but you can simplify the concatenation in the loop:
changed_string += char.upper() if char.islower() else char.lower() if char.isupper() else char

Using += is cleaner and avoids multiple concatenations.

[TibyanKhalid]

Am I the only one who doesn't like " += " haha, but yeah I think it definitely is clearer I'll change it now

[Frank2446-dotcom]

Same as the previous file—consider adding a description of what the test file is testing

[TibyanKhalid]

Okay sure

[Frank2446-dotcom]

The class name TestSwapletters should be in PascalCase, which is correct. However, the name should be more descriptive, such as TestSwapLettersFunctionality to better describe what exactly is being tested.

The docstring for the class is good, but could be more specific. For example:

"""Test cases for validating the behavior of the Swap_letters function, including edge cases."""

[TibyanKhalid]

Noted I'll make it more descriptive right now

[Frank2446-dotcom]

It’s a good idea to add edge case tests, such as testing an empty string or special characters.
You could consider adding more boundary tests for edge cases (empty strings, non-letters).

[TibyanKhalid]

I thought I added them omg, okay I'll add them right nowww

[Frank2446-dotcom]

Nice Job