344: reverse string

[WazedKhan]

Summary by CodeRabbit

• New Features

  • Added solution for string reversal problem using a two-pointer approach with in-place swapping
  • Added two implementations for top-k frequency problem: one using frequency counting and sorting, another using heap data structure

• Tests

  • Added test coverage for string reversal solution
  • Improved test data formatting for consistency across existing test cases

[coderabbitai]

Walkthrough

New LeetCode reverse string implementation added with two-pointer swap approach. Top-k frequent elements algorithms introduced using both sorting and heap-based methods in array hashing solutions. Test suite updated with formatting normalization and new reverse string test case.

Changes

Cohort / File(s)	Summary
Reverse String Implementation LeetCode/easy/reverse_string_344.py	New file with Solution class implementing in-place string reversal via two-pointer approach; includes swap helper method and reverseString method
Top-K Frequent Elements algorithms/python/array_hashing.py	Added topKFrequent (sorting-based) and topKFrequentHeap (min-heap-based) methods to Solution class; introduced heapq and Counter imports
Test Updates tests/test_leetcode_easy.py	Normalized spacing in test array formatting; added test_reverse_string_344 function with parameterized test cases; existing tests unchanged

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~20 minutes

• algorithms/python/array_hashing.py — Review both topKFrequent implementations for correctness of frequency counting logic, heap operations, and edge case handling (k=0, k>n, duplicates)
• LeetCode/easy/reverse_string_344.py — Verify two-pointer algorithm correctness and in-place mutation behavior
• tests/test_leetcode_easy.py — Confirm new test_reverse_string_344 properly validates reverse string output and existing tests remain unaffected by formatting changes

Poem

🐰 Two pointers dance, swapping left and right,
Heaps bubble up with frequencies bright,
From array chaos, top-k takes flight,
Tests verify each algorithm's might!
✨

Pre-merge checks and finishing touches

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 25.00% which is insufficient. The required threshold is 80.00%.	You can run @coderabbitai generate docstrings to improve docstring coverage.

✅ Passed checks (2 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title '344: reverse string' directly references the LeetCode problem number and clearly describes the main change, which is adding a reverse string implementation.

✨ Finishing touches

• 📝 Generate docstrings

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch 344-reverse-string

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 0

🧹 Nitpick comments (4)

LeetCode/easy/reverse_string_344.py (1)

6-18: Reverse logic is correct; swap helper could be inlined

The two‑pointer in‑place reversal is correct and handles empty, odd, and even‑length inputs as expected. If you want to simplify, you can drop the swap helper and use direct tuple unpacking:

while left < right:
    s[left], s[right] = s[right], s[left]
    left += 1
    right -= 1

Current version is fine if you prefer the explicit helper.

tests/test_leetcode_easy.py (1)

94-116: Reverse-string tests look good; consider adding an empty-input case

The parametrized test_reverse_string_344 correctly exercises in‑place mutation for a variety of lengths and character patterns and matches the LeetCode contract of not using the return value.

To tighten coverage, you might add a case for an empty list (and optionally a single‑character list), e.g. ([], []), to pin boundary behavior.

algorithms/python/array_hashing.py (2)

1-2: topKFrequent implementations are correct; a few simplifications are possible

Both topKFrequent and topKFrequentHeap correctly compute the k most frequent elements and are fine for typical LeetCode constraints.

If you want to streamline a bit:

• For topKFrequent, you can avoid constructing an intermediate dict and just sort keys by frequency:

  counter = {}
  for num in nums:
      counter[num] = counter.get(num, 0) + 1
  
  return sorted(counter, key=counter.get, reverse=True)[:k]

• For the heap version, behavior is correct; just note that the result order reflects heap order, which is fine for problems that allow “any order” but might be surprising in other contexts. A short docstring could clarify that.

These are optional polish; the current code is valid.

Also applies to: 34-60

---

63-66: Avoid executing demo code at import time

The bottom snippet that builds nums, calls topKFrequentHeap, and prints the result will run on every import of this module, which is undesirable in library/tested code and can produce unexpected stdout noise.

Consider either removing this block or guarding it:

if __name__ == "__main__":
    nums = [3, 0, 1, 0]
    k = 1
    sol = Solution().topKFrequentHeap(nums=nums, k=k)
    print("topKFrequent:", sol)

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 333142e and d588721.

📒 Files selected for processing (3)

• LeetCode/easy/reverse_string_344.py (1 hunks)
• algorithms/python/array_hashing.py (2 hunks)
• tests/test_leetcode_easy.py (2 hunks)

🧰 Additional context used

🧬 Code graph analysis (1)

tests/test_leetcode_easy.py (1)

LeetCode/easy/reverse_string_344.py (2)

• Solution (6-18)
• reverseString (10-18)

🔇 Additional comments (1)

tests/test_leetcode_easy.py (1)

8-27: Merge test case updates are purely formatting

The test_merge_sorted_array_88 parameter values remain the same; only spacing/formatting changed. No behavioral impact on the tests.