Solution for Sponge Case Challenge

[likechrisss]

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

---

Challenge: SpongeCase

Description

SpongeCase is a style of text in which letters alternate between lowercase and uppercase, starting with lowercase. Each letter's case depends on its index (even or odd). Non-alphabetic characters remain in place but still affect the index count.

Example:

spongecase("hello world")
# Output: "hElLo wOrLd"

spongecase("Python")
# Output: "pYtHoN"

spongecase("HELLO")
# Output: "hElLo"

---

Files

• The file name accurately describes the function’s behavior (e.g., spongecase.py).
• There is a module docstring in the function file (spongecase.py).
• The test file’s name matches the function file name, placed under tests/test_spongecase.py.
• There is a module docstring in the test file.

---

Unit Tests

• The test class has a helpful name in PascalCase (e.g., TestSpongeCase).
• The test class has a docstring explaining what it tests.
• Each unit test has:
  • A helpful name.
  • A clear docstring.
  • Only one assertion.
  • No extra logic—just setup, exercise, and verify.
• All tests pass.
• There are tests for defensive assertions (if applicable).
• There are tests for boundary cases (e.g., empty string, all caps, etc.).

---

Function Docstring

• The function’s behavior is clearly described.
• The function’s arguments are described (type, purpose, assumptions).
• The return value is described (type, assumptions).
• Defensive assertions (if any) are documented using Raises.
• Each assertion checks only one assumption.
• Include 3 or more doctests (or enough to illustrate usage and edge cases).

---

The Function

• The function’s name clearly describes its behavior.
• The function’s name matches its file name.
• The function has correct type annotations (e.g., def spongecase(text: str) -> str:).

---

Strategy

Do’s:

• Variable names help to understand the approach.
• Comments are clear and describe the strategy (why) rather than the implementation (how).
• Lines of code are spaced to highlight different stages of the strategy.

Don’ts:

• The function’s strategy should not be missing from the documentation.
• The code shouldn’t have more comments than logic. If so, consider simplifying the implementation.

---

Implementation

• The code passes formatting checks (e.g., Black, Ruff).
• The code passes Ruff linting checks.
• The code has no (reasonable) Pylint errors.
  • In code review, decide which Pylint errors are worth fixing.
• Variable names use snake_case and are clear.
• The code follows the chosen strategy as simply as possible.
• The implementation is as simple as possible for that strategy.
• The code includes any needed defensive assertions (with minimal logic).

---

Please review and check off each item above.
Once all items are addressed, we can finalize this PR.
Feel free to comment with any questions or clarifications.

Thank you for reviewing the SpongeCase solution!

[RamonColmenares]

Hi!, I think is great to have the readme with the problem description but if you leave it there it can get a little confuse, I would recommend that you englobe both the solution and the readme on a folder, maybe like this:

└── 📁solutions
    └── 📁challenge_#
        └── __init__.py
        └── spongecase.py
        └── README.MD
    └── 📁tests
        └── 📁challenge_#
            └── __init__.py
            └── test_spongecase.py

also I saw other group that use their name as the folder name, that could be a good alternative:

└── 📁solutions
    └── 📁 chrismy_leprince
        └── __init__.py
        └── spongecase.py
        └── README.MD
    └── 📁tests
        └── 📁chrismy_leprince
            └── __init__.py
            └── test_spongecase.py

[RamonColmenares]

LGTM

[hectordacb]

lgtm