<style>h3{border-bottom: 1px solid #E3E3E3}</style> # **Homework 3: Hashtables** **Due:** Friday, October 20th, 2023 at 11:59pm EST **Collaboration policy**: This assignment uses the default course [collaboration policy](https://docs.google.com/document/d/18D3opvXQ2tK0emL9R4LINS3s0BJaLM8_FspUKZzAUtU/edit). Roughly, you may discuss conceptual issues, but you must code alone. See the policy for details and examples of what is and isn’t allowed. This HW3 FAQ post will be maintained on [EdStem](https://edstem.org/us/courses/45311/discussion/). # Learning objectives This assignment has you practice the following course objectives: - Implementing common data structures - Working with exceptions - Understanding hashtables - Writing good test cases - Exploring the social impacts of technology # Overview **Assignment Link** Use this [GitHub Classroom link](https://classroom.github.com/a/akwS86B9) to get the stencil code for this assignment. For instructions on how to download the stencil and set it up in IntelliJ, see our [Stencil Setup Guide](https://docs.cs200.io/s/java-stencil-setup-guide). **Setup** If you’re having trouble with IntelliJ, our [First Time Setup Guide](https://docs.cs200.io/s/intellij-guide) includes a common bugs/FAQ section. Please make sure to read [our Gradescope submission guide](https://docs.google.com/document/d/1eM426oe_zrrDX6NeN9WCnDBmGrOV9afXlMFq4_kBoxk/edit?usp=sharing) before handing in your assignment! **Style Expectations** For all future assignments, including this one, we expect your code to conform to the [CS200 Java Style Guide](https://docs.cs200.io/s/java-style-guide). ## Stencil code The src folder has the following files (**which you should not modify**): - `IDictionary.java` containing `public interface IDictionary<K, V>` - `IGrep.java` containing `public interface IGrep` - `KeyNotFoundException.java` containing `public class KeyNotFoundException` - `KeyAlreadyExistsException.java` containing `public class KeyAlreadyExistsException` You will, however, alter the files that are in the sol folder: - `Grep.java`, containing `public class Grep implements IGrep` - `ChainingHashTable.java`, containing `public class ChainingHashTable<K, V> implements IDictionary<K, V>` AND `private static class KVPair<K, V>` - `Homework3TestSuite.java` containing `public class Homework3TestSuite` You will also alter the `grep-test-files/` directory. This is a folder containing one sample `.txt` file that you can use to test your `Grep `class. We recommend making more files in that directory to help with your testing (think edge cases!). # Java’s built-in hash tables (HashMap and HashSet) In this homework, you will be writing an application (in the `Grep` class) using Java’s built-in hashtables, and completing an implementation of hashtables from scratch (in the `Chaining `class). Java has two styles of built-in hash tables, specifically, `HashMap` or `HashSet`. - A `HashMap` uses a hashtable to represent a _dictionary_ (a mapping from some keys to values), as you have seen in lecture. - You declare a HashMap using `HashMap<KeyType, ValueType> myMap = new HashMap<>();` - Refer back to [Lecture 15](https://brown-csci0200.github.io/assets/lectures/15excnshashmaps/Lec15_whiteboard.pdf) for some common HashMap syntax. - A `HashSet` implements the Java interface `Set` (the same way a `LinkedList` or `ArrayList` implements `List`). The `Set` interface is an **unordered** (meaning elements have no index) collection of objects with the requirement that **no two elements are the same** (as determined by `.equals` equality). So, if we call a Set’s `add` method on an object already contained within the `Set`, the `Set` will not change (see the documentation for more details). - You declare a `HashSet` using `HashSet<EltType> mySet = new HashSet<>();` A hashtable is a straightforward way to implement a set, as a set can be seen as a special case of a _dictionary_. Since **dictionaries do not allow duplicate keys, we can view sets as dictionaries whose keys do not map to any values!** You can use Java’s `HashMap` class by copy-pasting `import java.util.HashMap;` at the top of your file (though IntelliJ may also automatically import it if you use `HashMap` in your code). Documentation on how to use Java’s HashMap can be found [here](https://docs.oracle.com/en/java/javase/18/docs/api/java.base/java/util/HashMap.html). Likewise, you can use Java’s `HashSet` class by importing `java.util.HashSet` (documentation found [here](https://docs.oracle.com/en/java/javase/18/docs/api/java.base/java/util/HashSet.html)) and Java’s Set interface by importing `java.util.Set` (documentation found [here](https://docs.oracle.com/en/java/javase/18/docs/api/java.base/java/util/Set.html)). :::danger **_Important:_** You are allowed to use the Java `HashMap` and `HashSet` built-ins in `Grep.java`, but not in `ChainingHashTable.java`. ::: # **PART 1: Searching in Files (Grep)** ## Background: command-line grep The UNIX command `grep` is an extremely powerful and useful tool (see [this activity](https://docs.google.com/document/d/1iHtZCZPSlH1rMLhudGWzMYsicCyjxxIpxs6Imus2S0A/edit?usp=sharing) if you’re not familiar with the command line). You can use grep to search :flashlight: a file for a given pattern, and report where that pattern appears in the file, as follows: grep -n <pattern> <file> The `-n` is an optional parameter that tells grep that we want it to report line numbers. It prints out each line of text next to the line number. This is but one of many, many grep features, which are fully documented on its man page (which you can access, if you want to learn more, by typing `man grep` into a terminal). :::info <details> <summary> <b><i>Example:</i></b> How does grep look when you use it in the terminal? </summary> Here are a couple of examples of how you’d use grep with this line number option: grep -n treasure myFile This command would print out something like the following: 1. The treasure is under the lamp 4. treasure 9. They found a hint that led them to another piece of the treasure map Your input/output format will look a bit different (see below), but this is the essence of what you are trying to replicate with your code. </details> ::: ## DIY Grep Now we’re going to implement (a limited version of) `grep` for ourselves! :dancer: In your `sol` directory, we’ve given you a class `Grep` that implements the `IGrep` interface. This class has: - A constructor with one parameter, a `String` with the filename that we’ll be `grep`ing - A method `lookup` with one parameter, a `String` representing the word to look up. This method returns a `Set` of `Integer`s representing the line number(s) that the word appears on We’ll be working within this class to write our own implementation of grep. _As noted above, you can (and should) make use of Java’s built-in hash table data structure, which is called_ `HashMap`_, to solve this problem._ ### **Task 1-A:** Construct some example documents In the `grep-test-files` directory, create a short (3-4 line) text file, where some words appear on only one line and some words appear on multiple lines. For each word that appears in the file, write down all of the lines that the word appears on. **What data structure would you use to represent this information?** The goal is to quickly be able to look up the collection of line numbers that a given word appears on in a file.  Draw out :art: what the contents of the data structure would look like for your example file. You do not have to use a specific format or turn this drawing in, but you will use it in the next step. :::warning <details> <summary> <b><i>Important Pointers:</i></b> What should your data structure do? </summary> Take a look at the file `Ozymandias.txt` in the `grep-test-files` directory. You want to have some data structure that allows you to easily go **from words in the file** (“I”, “met”, “a”, “traveler” …) **to the line numbers where they appear**. For example, your data structure should indicate that the word “that” is on lines 6, 8, and 13, while the word “stone” is on line 2. Your data structure wouldn’t need to show that “that” appears twice on line 8. </details> ::: :::info <details> <summary> <b>More Info and Tips</b> </summary> <ul> <li>Your data structure does not need to keep track of the number of times a word appears on a line, just that it appears at least once</li> <li>You should treat words as sequences of characters separated by whitespace; so “glitter” and “glitter!” are distinct words. Also, you can assume words are case-sensitive; so “mystery” and “Mystery” are distinct words.</li> <li>If the word does not appear anywhere in the file, it should not appear in the data structure.</li> </ul> </details> ::: :::success <details> <summary> <b><i>Hint:</i></b> What data structure should I use? </summary> Think about a data structure that <b>automatically removes duplicates</b> ! Prioritize efficiency!</li> </details> ::: ### **Task 1-B:** Process and Populate In the constructor of the `Grep` class, process the input file to your `Grep` to construct and populate the data structure you chose in task 1-A.  :::success <details> <summary> <b><i>Hint:</i> </b> We recommend looking into <code>split</code> method in the <code>String</code> class. Read more: </summary> The `split` method splits up a string into pieces each time it encounters a specific character, and stores those pieces in an array of strings. For example: ```java String sentence = "This is a sentence." String[] words = sentence.split(" ") // words is an array: ["This", "is", "a", "sentence."] // loop through the array: for (String word: words) { System.out.println(word) // do some other computation here } ``` </details> ::: :::warning **Reading from files**: Take a look at <a href="https://docs.cs200.io/lab4">Lab 4</a> for how to read from files. For a complete example, you can download the solution code for the lab [here](https://drive.google.com/file/d/13t2_FiC6urW0gurKK_PcztJ_S2yl4A-e/view?usp=drive_link). Some notes: - You’ll probably need to use two classes from the Java IO library (<code>java.io</code>) to accomplish this goal: one to read a file, and one to read specific lines from that file - Ensure that you **catch and handle relevant exceptions** by printing an informative message and “exiting gracefully” (meaning that you end the method without throwing the exception). Remember, we want error messages to be as informative as possible, so we want to give unique information about each error/error type that might pop up. - Think about exceptions like `FileNotFoundException` and/or `IOException`. ::: :::success <details> <summary> <b><i>Hint:</i></b> What is the scope of our data structure (should it be public or private)? </summary> The data structure should be a <code>private</code> field in your <code>Grep</code> class so that the <code>lookup</code> method can use it later. </details> ::: :::info <details> <summary><b>Notes about Testing</b></summary> Since the field is private in the <code>Grep</code> class, you cannot write unit tests for it. If you would like to check whether your constructor code is working, have your <code>Grep</code> constructor print out the contents of the data structure that you populated in Task 1-B (you should just be able to call <code>System.out.println(...)</code> on that field after you’re done filling it up). You can then call your constructor in the main method (e.g. <code>Grep(“grep-test-files/Ozymandias.txt”)</code>) and check the results of the printed-out contents vs. your drawing in Task 1-A. <br></br>Instead of using a print statement in your constructor, you can also insert a breakpoint at the end of your constructor and use the debugger to inspect the contents of the data structure. Once you think the constructor is working, you should remove the print statement from the constructor. </details> ::: ### **Task 1-C:** Write a test method for `Grep` **Task 1-C**: In `Homework3TestSuite.java`, write a test method that: - Initializes a new `Grep` object using your example file as the input to the constructor **(just like in DecisionTree, make sure the HW3 folder is your working directory in IntelliJ and use a relative path, e.g. “grep-test-files/Ozymandias.txt”)** - Calls the `lookup` method of this object using some input(s) (search terms) and verifies that the result is a `Set` of line numbers where the search term appears. Just like in HW2, this test will not pass yet. 🙅 :::info <details> <summary><b><i>Note:</i></b> What could a test look like?</summary> Following up on the Ozymandias example, our test would initialize a new `Grep` object with `Ozymandias.txt` as the input. The assertions would verify that calling `lookup(“that”)` returns a `Set` with 6, 8, and 13 as elements; and that calling `lookup(“stone”)` returns a `Set` with 2 as the element. What should `lookup(“cat”)` return? </details> ::: :::success <details> <summary><b><i>Hint:</i></b> How do we check that the <code>Set</code> looks as expected?</summary> To check that the returned <code>Set</code> has the values you expect, you can either check that the size of the returned <code>Set</code> is the expected size and check that it contains each of the expected elements, <b>or</b> make a <code>Set</code> that contains the expected elements and use <code>assertEquals(expectedSet, returnedSet)</code> </details> ::: ### **Task 1-D:** `lookup` Fill in the `lookup` method according to the documentation in the `IGrep` interface. ### **Task 1-E:** Test `lookup` Run your tests and debug the `lookup` method, if necessary.  ### **Task 1-F:** Write a `main` method Write a `main` method for the `Grep` class. The `String[] args` should contain a file name, and then at least 1 other word to look for, in that order. The output of correctly running the main method should look something like the following: that was found on lines: [6, 8, 13] stone was found on lines: [2] :::danger **Your main method should not throw any exceptions**; make sure it prints out an informative message and exits gracefully instead of throwing any exceptions that may arise from incorrect user input. ::: :::warning Refer to [Lab 4](https://docs.cs200.io/lab4) to see how to use arguments in IntelliJ. ::: ### **Task 1-G**: Add more tests Add more tests, as necessary, to `Homework3TestSuite.java` that test your lookup function. You do not need to test for exceptions that might be thrown on I/O errors (as you are catching those and printing a message, which can’t be tested). :::info <details> <summary><b>More Info about What to Test</b></summary> We are only testing lookup here, not the main `Grep` program, because the latter simply prints output to the screen. In such cases, you test the inner logic, then manually inspect the output build from the results of the inner logic. That is, you only need to test your `lookup` method, not the `Grep` constructor or `main` method. </details> ::: # **PART 2: Chaining Hash Tables** In this problem, you will implement a hash table as we outlined in lecture. Recall that the internal data structure we saw for a hash table is an array of lists. You will use Java’s `LinkedList` class in particular for the list implementation. The point of this problem is for you to see how hash tables are built when they don’t already exist in a language. Therefore, **you may NOT use Java’s hashmaps or hashsets in your implementation.** In your `sol` directory, we’ve given you a class `ChainingHashTable` that implements the `IDictionary<K, V>` interface. This class has: - A constructor that takes in the size of your hashtable - An inner class` KVPair<K, V>` for combining keys and values (as shown in lecture Friday 3/03) <!----> - Several methods from the `IDictionary` interface that we must implement: - `lookup`: we’ve implemented this method for you, but it will be your job (later) to implement its helper method `findKVPair` - `update`: we’ve written for you in its entirety - `insert` and `delete`: you must write these methods on your own (more info later in the handout) - Overridden methods for `equals` and `toString` that you should implement (later). ## The Constructor ### **Task 3-A**: Fill in the constructor for `ChainingHashTable.java` Fill in the constructor for `ChainingHashTable.java`. The `ChainingHashTable` constructor should take as input a size variable, which specifies the size (number of slots) of the table. Attempts to make a hashtable with a negative or 0 size should throw an `IllegalArgumentException` with the error message "Invalid size." When the constructor is done, you should have a valid empty hashtable. :::warning <details> <summary><b><i>Note:</i></b> About setting up the data structures</summary> This task requires you to set up fields for the underlying data structures for the hashtable (which we discussed in class) and create the corresponding objects. The subtlety here is that you have to **completely set up the objects**. We’re leaving it to you to figure out what that means (that’s one of the learning goals of this assignment), but we have later tasks that will explicitly hint you toward this. Look back at the lectures on hashtables (03/01, 03/03) for an idea of what underlying data structure could be helpful here. </details> ::: :::danger **Important**: In Java, you cannot create an array of a generic type (generic means “with type parameters”). In order to circumvent this limitation, you should do the following to create an array of `LinkedList`s of `KVPair`s. ```java this.data = (LinkedList<KVPair<K,V>>[]) new LinkedList[size]; ``` This line of code will generate a warning that there is an unchecked cast. To get rid of the warning, above any methods that cast like this, you should write: ```java @SuppressWarnings("unchecked") ``` Typically, warnings such as these indicate a problem with your code, so you should not suppress them; you should pay attention to them! In this specific instance, however, we justify its use as we are trying to get around a Java limitation. ::: ## Finding key-value pairs ### **Task 3-B:** Write test methods In `Homework3TestSuite.java`, write test methods that: :::info <details> <summary> <b>Requirements for Test Methods</b> </summary> - Initialize new `Chaining` objects - Call `lookup` and `update` on empty Chaining objects (an empty Chaining object has a positive initial size, but has no key-value pairs added to it) - Call on the `insert` method to add key-value pair(s) to the hashtables and use `lookup` to make sure the correct key-value pair(s) exist in the hashtables - Test the interaction between `insert`, `update` (which updates the value for a given key), and `lookup` (which looks up the value for a given key) - Call on the `delete` method to delete key(s) - Test for basic edge cases (such as a key not existing in a table) - Test more complex interactions between `insert`, `delete`, `update`, and `lookup` </details> ::: :::warning <details> <summary><b>Important Pointers about Writing Tests 🧪</b></summary> Separate these out into multiple test methods – we want you to write these tests now to think of example hashtable operations and how all of these methods might interact with each other, but some of the tasks below will have you run some tests and not others as you start implementing the methods. Do not go overboard writing tests for this task (you will add more once you implement `equals`), but be confident that you’ve thought through and written tests that show examples of the possible interactions of the four methods. If a key is not found or already exists in the table, the appropriate methods will throw a `KeyNotFoundException` or `KeyAlreadyExists` exception (check the stencil code to see if a method should be throwing such an exception). </details> ::: ### **Task-3C**: Write `findKVPair` Fill in  `findKVPair`, which searches your data structure for the KVPair for a given key value. This method should throw a `KeyNotFoundException` if the given key is not in the hashtable. **Reminder**: You are welcome to implement additional (helper) methods if you wish. If they are only for use within your class, mark them as private. :::success <details> <summary><b><i>Hint:</i></b> About hashing and <code>hashCode</code></summary> Recall that hash tables are backed by a hashing function, which maps a key to an index in the array. You can use the built-in java hashCode method (e.g. <code>int hash = myValue.hashCode()</code>), which returns a signed (either positive or negative) integer. You should take the absolute value (<code>Math.abs(hash)</code>) of this integer and use the modulo (<code>%</code>) operator to map this to a value that will fit in your array. </details> ::: ### **Task 3-D**: Make sure everything works :) Once you have `findKVPair` implemented, you should have an empty hashtable on which the `lookup` and `update` methods (which we provided) can run. **Run your empty-hashtable tests for** `lookup` **and** `update` **NOW.** The subtlety we warned about in the constructor regarding setting up the objects can show up on these empty tests if you missed something. Making sure the empty case works now could save you a lot of debugging headaches later. You have not implemented `insert` and `delete` quite yet, so don’t run any tests that use those methods. ## Implement insert and delete ### **Task 3-E**: Write `insert` Fill in the `insert` method, which takes a key and a value and stores the value for the given key in the underlying hashtable, unless the key was already in the hashtable. - If the key was already in the hashtable, throw a `KeyAlreadyExistsException` and leave the hashtable contents unmodified. ### **Task 3-F**: Test `insert` Run your tests that use the `insert` method but not the `delete` method. If you get an unexpected problem, ask yourself whether you could avoid it by modifying the constructor (this is another place where the constructor subtlety we warned about could arise). :::warning <details> <summary><b>Warning: OO Design 👀</b></summary> We have mentioned in lecture how good OO design avoids code that has to ask what type something is. Asking whether something is equal to `null` is often a type check in disguise. If your code asks whether something is `null`, consider whether that is actually necessary (this again connects to the constructor subtlety). </details> ::: ### **Task 3-G**: Write `delete` Fill in the `delete` method, which removes a KVPair from the hashtable. The method header in the stencil indicates which exceptions this method can throw. 🤽 You are welcome to use [LinkedList methods](https://docs.oracle.com/en/java/javase/18/docs/api/java.base/java/util/LinkedList.html) if you think they will help (but this is not required). ### **Task 3-H**: Test! Run all of the tests from Task 3-B and debug your code. ## Handling Exceptions Some of the methods in `IDictionary` throw exceptions (which can be seen in the method declarations in the stencil code). If the method declaration `throws` a specific exception, your code should throw that exception when appropriate. Some of the thrown exceptions are really for the user of the hashtable and aren’t useful for your own implementation. You don’t need to catch these exceptions (you should test for them, however). You may find situations in which the thrown exceptions are useful, in which case you should catch them and do something appropriate (we’re intentionally leaving this for you to think about). :::danger **_Note:_** You may **NOT** modify the `throws` annotations (or anything else) in `src/IDictionary`. Work with the throws annotations that we have provided. ::: :::info **_Note:_** You are **NOT** expected to print out messages to the user just because an exception got thrown. If you don’t see a use of an exception for the logic of your code, just pass them along to the user/test suite (by not surrounding the code that throws the exception in a `try/catch` block). ::: ## Implementing toString and equals ### **Task 3-I**: Write `toString` Fill in `toString` in the stencil file. Use a format such as: [key1: value1, key2: value2, ...] (small variations on this are also fine – the goal is to print the key/value mappings, but not the internal indices). The order in which the keys print out doesn’t matter. :::success <details> <summary><b><i>Hint:</i></b> How should we approach this?</summary> Consider nested `for` loops! </details> ::: :::warning **_Warning:_** Since your format may not match our wheat solution format exactly, do not put tests for this method in `Homework3TestSuite.java`. Write your own small testing file to test toString, or create a main method to print some sample tables out. ::: ### **Task 3-J**: Write some tests Write some tests that: - Initialize multiple `ChainingHashTable` objects and insert some values into them - Call on `equals` to check if two of the hashtables you initialized are equal. Two `ChainingHashTable` objects should be considered equal if they have the same set of key-value pairs. They could have different underlying array sizes and different organizations of KVpairs within the arrays (including the same KVPair being stored in different array slots in otherwise equal arrays). ### **Task 3-K:** Write `equals` Fill in the `equals` method in the stencil file. There are no running-time restrictions on your solution. :::success <details> <summary> <b><i>Hint:</i></b> How do we test if two <code>Chaining</code> objects are equal? What does it mean for them to be equal? 🤔 </summary> This problem requires you to figure out how to iterate through one hashmap while checking its contents against the other. <code>findKVpair</code> may be helpful depending on how you break this down, but using it is not required. It may also be helpful to think of this problem as “are all KV pairs that are in hashtable A also in hashtable B, <i>and</i> are all KV pairs that are in hashtable B also in hashtable A?” </details> ::: ### **Task 3-L:** Test `equals` Test and debug your `equals` method. :::success <details> <summary><b><i>Hint:</i></b> Do you have issues with the <code>testEquals</code> test case?</summary> If you have issues with the testEquals test case, it is related to this method! Try to make sure your equals method checks all the requirements and nothing more. </details> ::: ## Testing ### **Task 3-M**: Make sure your tests are :sparkles:really good:sparkles: Revise or add to your tests, as necessary. You do **NOT** need to test `findKVPair`, `toString`, or any helper methods that you write in order to write `insert` and `delete`. :::success <details> <summary><b>Helpful Testing Tips</b></summary> - Since your class is generic, be sure to use multiple key and value types in your testing. - Since we are working with a mutable data structure, don’t forget about `@Before` methods that can be used to set up your data across tests. - **Don’t forget to test exceptions!** You should test for the `KeyNotFound` and `KeyAlreadyExists` exceptions </details> ::: We will run wheat/chaff testing on your test suites. Note that :sparkles:**you do not need to catch all of the chaffs**:sparkles:. See the [Grading](#Grading) section for details on which chaffs are requrired. # Handing in Before handing in your files, check that your solution is compatible with Gradescope. To do this, run `AutograderCompatibility.java`. Make sure that it compiles and runs without any errors. To hand in your files, submit them to Gradescope. - Submit `Grep.java`, `ChainingHashtable.java`, to the **Homework 3: Implementation** submission - Submit `Homework3TestSuite.java` **AND any txt files in `grep-test-files`** to the **Homework 3: Testing** submission. Once you have handed in your homework, you should receive an email, more or less immediately, confirming that fact. If you don’t receive this email, try handing it in again, or ask the TAs what went wrong. :::info <details> <summary> <b><i>Note:</i></b> If your code does not work with the autograder, you will be penalized. If there are any complications, follow these steps: </summary> <ul> <li>Make sure your testing submission passes the wheat. If it doesn’t, you should use the autograder output and the message in the failed autograder test to debug your test suite.</li> <li> If your test suite passes the wheat, run your implementation against your test suite. If this crashes, you should fix your solution code so that it is compatible with your test suite. </li> <li> If you are still having issues, please reach out to us at TA Hours or Ed. </li> </ul> </details> ::: # Grading :::info **_Note:_** Here is the breakdown of how this homework is graded: 1. **Implementation (autograded)** (30%): We are running 22 autograder tests on your assignment. 15 of them are visible to you, and 7 of them are not (this is to encourage you to thoroughly test your own code). Focus on fixing the autograder tests and writing and passing your own tests to earn this part of the homework score. 2. **Testing (autograded)** (30%): We are grading your assignment using <a href="https://docs.cs200.io/s/wheat-chaff-guide" style="text-decoration: underline">wheat and chaff grading</a>. For this assignment, **you are expected to pass the wheat and catch four of the five grep chaffs and eight of the twelve chaining chaffs** to get full points on this part of the homework score. We suggest using the results of the wheat/chaff testing to self-assess how thorough your test suite is for running on your own code (**don’t worry if you missed a couple of chaffs, though** – a couple of the chaining chaffs in particular deal with specific edge cases). 3. **Style checks (autograded)** (5%): We will check your code to ensure it complies with our <a href="https://docs.cs200.io/s/java-style-guide" style="text-decoration: underline">Java Style Guide</a>, most especially on following our conventions for method naming and including Javadocs.  For this part, make sure you’re following our <a href="https://docs.cs200.io/s/java-style-guide" style="text-decoration: underline">Java Style Guide</a>—if something doesn’t match, the autograder will provide feedback. <b>Note:</b> On Gradescope, this part is counted with the autograder score for implementation. 4. **Design and code structure** (35%): The TAs will manually grade your work according to some rubrics. To earn the points for this part of the homework score: Fllow the design considerations for every task (for example, if a task for choosing a specific data structure says that the goal is “quick lookup,” your choice of data structure should prioritize that goal) ::: *** _Please let us know if you find any mistakes, inconsistencies, or confusing language in this or any other CS200 document by filling out our_ [_anonymous feedback form_](https://forms.gle/aJh8V8VrNPpMbDD37)_!_