[Bug Fix] Allowing Digits In Person Names

Hey guys! Let's dive into a frustrating bug that I stumbled upon while working on a project. It's about person names and the unexpected behavior when they contain digits. Specifically, the User Guide (UG) allows alphanumeric names, but the system is rejecting them. This is a real head-scratcher, and I'm here to break down the issue, why it's a problem, and what needs to be done to fix it. This is a common situation for everyone involved in software development. Let's make sure that we can identify and solve the problem effectively. I will also be sharing details to reproduce the bug, what's expected, and what's actually happening. So, let's get started!

Steps to Reproduce the Bug

To really get to the bottom of this issue, we need to know how to reproduce the bug. It's like a recipe – follow the steps, and you'll see the problem firsthand. Let's break down the exact steps:

1. Run the add command: The core of the issue lies in a specific command, so we'll be starting here. The command in question is add n/Alex1 p/98765432 e/alex@example.com a/Block 1. This command is designed to add a new person to the system. Pay attention to the name field n/Alex1. Notice that it contains a digit (1).

Essentially, the goal is to add a new entry to the system with the name "Alex1", a phone number, an email, and an address. Now, the add command, or rather, the system that processes the command, should ideally be able to handle such entries without any issues, according to the UG. By running this command, we're essentially testing the system's ability to validate the inputs and perform the action.

Now, you might be thinking, "Why is this a big deal?" Well, the answer lies in the expected behavior, which we'll discuss in the next section.

Expected Behavior

When you interact with a system, you usually have a certain expectation about how it should behave. The Expected Behavior is essentially the ideal scenario, what should happen in a perfect world. In this case, we have a clear expectation based on the User Guide. In the world of software development, the expected behavior often comes from the requirements documentation. Let's get into the details:

• Command should succeed: According to the User Guide, the system should accept alphanumeric names. This means names that include both letters and numbers should be perfectly valid. If the User Guide says it's okay, then the system should follow suit. Given this, the command add n/Alex1 p/98765432 e/alex@example.com a/Block 1 should go through without any problems. The system should correctly add the new person to its database or list, or wherever it stores the information. The system's purpose is to manage and store personal information. This is really essential to verify that the core functionalities are working correctly.

• No Errors: If the command is valid, there should be no error messages or rejections. The whole process should be smooth and straightforward. The system should acknowledge the action and possibly provide some feedback (like a confirmation message), but it should never say, "I can't do that because the name contains a number." The system's response should align with what is allowed.

• Data Integrity: The new person's details (name, phone number, email, address) should be correctly stored in the system. The data is consistent and the system should maintain its data integrity. Overall, the user's experience should be in line with the documentation.

As you can see, the expected behavior is clear and straightforward. The system should happily accept the command and store the data. However, as it turns out, the reality is quite different, and that's where the bug comes in.

Actual Behavior

Now, let's talk about what actually happens when you run that add command. The Actual Behavior is the opposite of the Expected Behavior. This section is about the reality of what happens when you try to add a person with an alphanumeric name. Instead of things going smoothly, you run into an issue. Here's what occurs:

• Rejected by the validator: The command is not accepted. The system actively rejects the input. This means the system refuses to add the person and throws an error message or some other indication that the command failed. This rejection is due to the system's validator. This is essentially the part of the code that checks if the input is valid before processing it. In this case, the validator is programmed to only accept names with letters, not numbers. This is where the core problem lies.

• Error messages: You'll likely see an error message explaining why the command failed. The message could be something like, "Invalid name format," or "Name should only contain letters." These error messages are designed to help you understand what went wrong, but in this case, the message directly contradicts what the User Guide says is acceptable.

• Data not added: Since the command is rejected, the person's information is not added to the system. The new entry isn't saved, and the system doesn't reflect the new information. This is the ultimate consequence of the bug – the system is unable to store valid data that it should be able to handle.

The difference between the Expected Behavior and Actual Behavior is huge, and it leads us to the heart of the problem.

Justification

Why is this bug a problem, and why should we fix it? The Justification section answers these key questions. It's about explaining why the issue matters and why it's important to address it. This also helps with the product's performance, as well as the end-user experience. Let's break it down:

• Prevents legitimate data: The primary problem is that the bug prevents adding legitimate data. The User Guide allows alphanumeric names. But the current implementation blocks those names. The user experience is not ideal because legitimate names are not accepted. The system should follow the rules set in the User Guide, and it should process the commands properly, even if a user's name includes digits.

• Inconsistency with the User Guide: This bug creates an inconsistency between the system's behavior and the User Guide. Users rely on the documentation to understand how the system works. If the system doesn't behave as described, it causes confusion, frustration, and a lack of trust in the system. When a user tries to use a feature and it doesn't work as expected, it can cause problems and a loss of confidence in the program.

• Impact on usability: This bug can significantly impact the usability of the system. Imagine a user trying to add a contact with a name like "Alex123" or "JohnDoe89". They won't be able to do it, and they will run into errors. It will make the user confused and frustrated. The user experience is crucial, and it depends on whether the product actually works.

• Data Loss: If users are unable to add legitimate contacts, there could be data loss. You are potentially losing valuable data. This can affect the system's ability to serve its purpose effectively. The system is designed to provide value, but this bug can get in the way.

Fixing this bug is more than just a matter of cosmetic change. It's about making sure the system functions correctly, following the documented rules, and providing a positive user experience. The bug's justification is clear: It prevents legitimate data from being added, creates inconsistencies, and negatively impacts usability.

Conclusion

In conclusion, the bug related to person names containing digits is a real problem. The system should allow names with digits. This issue leads to a poor user experience. It's essential to fix this bug to ensure that the system functions correctly. The system needs to be updated. It will improve the overall performance and reliability. By fixing the bug, we can make sure the system's behavior aligns with the User Guide. It will also help improve the end-user experience.