Feedback

[github-classroom]

👋! GitHub Classroom created this pull request as a place for your teacher to leave feedback on your work. It will update automatically. Don’t close or merge this pull request, unless you’re instructed to do so by your teacher.
In this pull request, your teacher can leave comments and feedback on your code. Click the Subscribe button to be notified if that happens.
Click the Files changed or Commits tab to see all of the changes pushed to the default branch since the assignment started. Your teacher can see this too.

Notes for teachers

Use this PR to leave feedback. Here are some tips:

• Click the Files changed tab to see all of the changes pushed to the default branch since the assignment started. To leave comments on specific lines of code, put your cursor over a line of code and click the blue + (plus sign). To learn more about comments, read “Commenting on a pull request”.
• Click the Commits tab to see the commits pushed to the default branch. Click a commit to see specific changes.
• If you turned on autograding, then click the Checks tab to see the results.
• This page is an overview. It shows commits, line comments, and general comments. You can leave a general comment below.
  For more information about this pull request, read “Leaving assignment feedback in GitHub”.

Subscribed: @Norbu-Sherpa

[walters954]

Hey Norbu! Great work completing all 20 questions in Module 2! 🎉 You've clearly put in solid effort here, and it shows. Let me share some thoughts on your code.

What You Did Well

1. Complete submission - You tackled every single question, which is fantastic. The commit history shows a methodical approach, working through each question one at a time. That's a great workflow habit!

2. Strong grasp of Maps - Your solutions for Questions 18-20 demonstrate a solid understanding of Map operations. In particular, Question 20 (getHighPaidEmployees) shows you understand how to iterate over a Map's keySet and use get() to retrieve values -- this is a pattern you'll use constantly in Salesforce development.

3. Good use of break and continue - Question 17 (countMoney) correctly uses break to exit the loop when the sum exceeds 40. Question 15 uses the right approach of checking for positive values before adding. These flow control concepts are essential.

4. Clean use of addAll() in Question 14 - Using stringSet.addAll(inputList) is the idiomatic Apex way to populate a Set from a List. Nice and efficient!

Areas for Improvement

1. Question 1 (helloWorld) - Watch for edge cases in your conditions

Your current code handles x > y, x < y, and x == y as three separate cases. However, the method specification says to return null when x equals y (since it only returns "Hello World!" when x is greater than y). Your code returns 'Both numbers are equal' for that case, which won't match the expected test output. Here's a cleaner version:

public static String helloWorld(Integer x, Integer y) {
    if (x == null || y == null) {
        return null;
    }
    if (x > y) {
        return 'Hello World!';
    }
    return null;
}

Why this matters: Always read the method's specification carefully. Returning unexpected values can cause test failures and bugs in production.

2. Question 6 (checkString) - Redundant condition and check order

Your condition a != '' || a != null will always be true (any value is either not empty OR not null). This works by accident but isn't logically sound. Also, checking a == '' before a == null could cause a NullPointerException in some contexts. A safer approach:

public static String checkString(String a) {
    if (a == null) {
        return 'Null';
    } else if (a == '') {
        return 'Empty';
    } else {
        return 'Contains Text';
    }
}

Why this matters: Always check for null first before checking other conditions. This is a defensive programming pattern that prevents runtime errors.

3. Question 7 (determineGrade) - Return value format

Your method returns 'Grade A', 'Grade B', etc., but the specification says it should return just 'A', 'B', etc. (see the example: determineGrade(85) should return "B"). Small detail, but it would cause test failures:

if (score >= 90) {
    return 'A';
} else if (score >= 80) {
    return 'B';
}
// ... and so on

4. Question 16 (findWordInList) - Using indexOf vs. manual loop with break

Your solution using words.indexOf(wordToFind) is clever and gets the right answer! However, the purpose of this exercise was to practice using a for loop with a break statement. For learning purposes, here's what the exercise was looking for:

public static Integer findWordInList(String wordToFind, List<String> words) {
    Integer index = -1;
    for (Integer i = 0; i < words.size(); i++) {
        if (words[i] == wordToFind) {
            index = i;
            break;
        }
    }
    return index;
}

Why this matters: In real-world Apex, you'll encounter situations where you need to break out of loops early (e.g., when processing large data sets). Practicing this pattern now builds muscle memory.

5. Minor: Clean up System.debug() statements

Questions 9 and 10 have System.debug(result) left in the methods. While these don't cause errors, it's good practice to remove debug statements before submitting code. In production Salesforce code, leftover debug statements can impact performance and clutter logs.

Next Challenge

You're clearly building a strong foundation! As you move into Module 3, pay extra attention to:

• Reading specifications carefully to make sure return values match exactly what's expected
• Null-safety patterns -- always check for null before other conditions
• Using the intended language features in each exercise, even when shortcuts exist

Keep up the great work, Norbu! You're making solid progress. 💪