Add solution for Challenge 21 by cckwes

[cckwes]

Challenge 21 Solution

Submitted by: @cckwes
Challenge: Challenge 21

Description

This PR contains my solution for Challenge 21.

Changes

• Added solution file to challenge-21/submissions/cckwes/solution-template.go

Testing

• Solution passes all test cases
• Code follows Go best practices

Thank you for reviewing my submission! 🚀

[coderabbitai]

Walkthrough

A new Go program is introduced with three binary search utility functions: an iterative implementation, a recursive implementation, and a function to find insertion positions in sorted arrays. Each function handles edge cases and returns -1 or 0 when targets are not found.

Changes

Cohort / File(s)	Change Summary
Binary Search Implementations challenge-21/submissions/cckwes/solution-template.go	Adds three public functions: BinarySearch (iterative), BinarySearchRecursive (recursive), and FindInsertPosition (insertion point locator) for sorted integer arrays. Includes a main function demonstrating usage and edge case handling.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

• Standard binary search algorithm implementations with conventional edge case handling (empty arrays, not found cases)
• Single file addition with no complex interactions or dependencies to verify
• Logic is straightforward and follows well-established patterns

Possibly related PRs

• PR #626: Adds the same three binary search functions (BinarySearch, BinarySearchRecursive, FindInsertPosition) in a different submission file for Challenge 21.
• PR #764: Implements identical binary search functions with the same signatures and purposes in another challenge-21 submission.
• PR #707: Adds the same three exported functions to challenge-21 solution files, directly modifying the same public API surface.

Pre-merge checks

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 75.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
Title check	✅ Passed	The title clearly and specifically identifies the main change: adding a solution for Challenge 21 by the user cckwes, which matches the changeset.
Description check	✅ Passed	The description is directly related to the changeset, explaining the Challenge 21 solution submission, the file added, and testing performed.

---

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 (2)

challenge-21/submissions/cckwes/solution-template.go (2)

54-77: Consider simplifying the recursive API and base cases

The recursive search logic is correct, but you could simplify and make the API harder to misuse:

• The len(arr) == 0 check is redundant if callers respect left/right; left > right is already a sufficient base case.
• Exposing left and right on the exported function makes it easier for external callers to pass out‑of‑range values and trigger a panic.

If the challenge doesn’t require this exact signature, you could wrap it like:

// BinarySearchRecursive is the exported entry point.
func BinarySearchRecursive(arr []int, target int) int {
    return binarySearchRecursive(arr, target, 0, len(arr)-1)
}

func binarySearchRecursive(arr []int, target, left, right int) int {
    if left > right {
        return -1
    }
    mid := (left + right) / 2
    val := arr[mid]
    if val == target {
        return mid
    }
    if val > target {
        return binarySearchRecursive(arr, target, left, mid-1)
    }
    return binarySearchRecursive(arr, target, mid+1, right)
}

If the signature is fixed by the template, you can at least drop the len(arr) == 0 check to reduce work in each recursive call.

---

79-105: Clarify FindInsertPosition semantics for duplicates (optionally switch to strict lower bound)

For arrays without duplicates, this works as expected: returns the index of target if present, otherwise the position where it should be inserted to keep the slice sorted.

With duplicates, though, the index returned for an existing target depends on how the mid converges (e.g., for [2,2,2,2] and target=2, it returns 1, not 0). If the intended contract is “lower bound” (first index where arr[i] >= target), you can tweak it slightly:

 func FindInsertPosition(arr []int, target int) int {
-    if len(arr) == 0 {
-        return 0
-    }
-
-    left := 0
-    right := len(arr) - 1
-
-    for left <= right {
-        index := (left + right) / 2
-        val := arr[index]
-
-        if val == target {
-            return index
-        }
-
-        if val < target {
-            left = index + 1
-        } else {
-            right = index - 1
-        }
-    }
-
-    return left
+    left, right := 0, len(arr)
+    for left < right {
+        mid := (left + right) / 2
+        if arr[mid] < target {
+            left = mid + 1
+        } else {
+            right = mid
+        }
+    }
+    return left
 }

This keeps the same behavior for unique elements but guarantees a stable “insert before all existing equals” position if duplicates are present. If the challenge never uses duplicates, what you have is still logically sound.

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between f761321 and 81e5125.

📒 Files selected for processing (1)

• challenge-21/submissions/cckwes/solution-template.go (1 hunks)

🔇 Additional comments (2)

challenge-21/submissions/cckwes/solution-template.go (2)

7-24: Main function is a clear, self-contained demo

The main function cleanly demonstrates all three helpers with simple sample data and doesn’t interfere with their use in tests. No changes needed here.

---

26-52: Iterative BinarySearch implementation looks correct and robust

The iterative binary search correctly initializes bounds, handles the empty-slice case, and updates left/right without off‑by‑one issues. Behavior (-1 when not found) is clear and conventional.