Skip to content

[CS2113-T13-3] LeBook - #43

Open
Deanson-Choo wants to merge 520 commits into
nus-cs2113-AY2425S2:masterfrom
AY2425S2-CS2113-T13-3:master
Open

[CS2113-T13-3] LeBook#43
Deanson-Choo wants to merge 520 commits into
nus-cs2113-AY2425S2:masterfrom
AY2425S2-CS2113-T13-3:master

Conversation

@Deanson-Choo

Copy link
Copy Markdown

Book Management System that eases the workload of librarians. It is optimized for librarians so that tasks can be done faster.

rchlai added a commit to rchlai/tp that referenced this pull request Mar 18, 2025

@TVageesan TVageesan left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Overall looks good, don't see any major design issues here. Main way you could (optionally) improve is by utilizing custom exceptions to streamline your error handling.

Comment on lines +33 to +34
// Assert that we're returning a non-null list
assert books != null : "Book list should never be null";

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Comments like these violate the principle of 'don't repeat the obvious'. The assert is already quite clear on what it does just by reading the code: if the books is null, flag a assert that "Book List should never be null". The comment here actually harms the readability as the reader/developer reads twice the amount of words to get the same amount of understanding of what this line does.

Comment on lines +29 to +32
public String toSaveAsString(Book book) {
assert (filePath != null) && !filePath.trim().isEmpty() : "File path cannot be null or empty";
return book.toFileFormat();
}

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does it make sense to verify that filePath is valid here, inside toSaveAsString? You could either 1) check once at initilaization 2) assert that filePath is valid only in functions that are relevant/require the filepath to be valid. Secondly, if this function is just a wrapper around book.toFileFormat() do we need the function in the first place?

return bookList;
}

Scanner s = new Scanner(f);

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

avoid single letter variables outside of temporary variables (i.e. i,j,k in loops). I promise the readability gain is worth typing the extra seven characters.

directory.mkdirs();
}

try (BufferedWriter writer = new BufferedWriter(new FileWriter(filePath))) { // Overwrites file

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

disgusting

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry

Comment on lines +36 to +45
public void printError(String message) {
printSeparator();
System.out.println("[ERROR] " + message);
printSeparator();
}

public void printWithSeparator(String message) {
printSeparator();
System.out.println(message);
printSeparator();

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If you already have a printWithSeperator, why not utilize that to implement your other prints? (i.e. printError(String message) { printWithSeperator("[ERROR]" + message) } )

String result = bookManager.deleteBook("2"); // Index out of bounds

assertEquals(1, bookManager.getBooks().size());
assertEquals("There is no such book in the library!", result);

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

not essential/necessary, but considering using actual exceptions for situations like this to make your testing less brittle. When you output directly a error message (and check for it) it means the test is very dependent on the message you write. If you change the text a bit later on, all the tests related to it will fail even though it's still functioning correctly.

What you can do to make this less brittle is use custom exceptions. IF you use a InvalidBookException for example, jest can just check if the correct type of exception is thrown (which wont change) instead of checking if the error message itself matches (which changes much more often)

Comment on lines +83 to +87
public String deleteBook(String index) {
assert index != null : "Book Index cannot be null";

try {
int bookIndex = Integer.parseInt(index) - 1;

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

With SLAP principle, we want to focus responsibilities specifically to manging books to the Book Manager class. It's a bit strange then that deleteBook receives a string index and then processes it into a integer index. This should be the Parser level responsibility to process string data into the data the internal classes want to receive.

Xavierleejrui and others added 28 commits April 1, 2025 18:30
added junit tests for some command files
Add more parser tests and implement minor change in parser
added listoverdue and undo function to UG
Update help command to include listing of users
minor bug fix for undo function
improve the help command. Also improved formatting when adding a book.
WayneCh0y and others added 30 commits April 8, 2025 04:23
update and remove extraneous
fixes bug on listing shelf
bug fixing in shelf list numbering
bug fix in list overdue users
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.