Adam has written a file name searching program, (their masterpiece!) but, though “working correctly”, it suffers from many code quality problems akin to what might be discussed in a code review. It will be your job to modify the code to fix these problems throughout the term. For ideas about how to get started, feel free to consult these guidelines. Note that we are not expecting you to modify the functionality of the code - only the quality.

Due Dates and Grading

There will be five checkpoints throughout the term, one every two weeks, in which you will be allowed to submit up to four new fixes to the codebase. Before the deadline, you should fill out the Gradescope form, outlining the fixes you have made and why you think they make the code better. This document will be half of your grade for each issue; the other half will be a verification that your new code actually fixes the issues you identified. We will be grading for two issues each week, but you are welcome to submit up to four. At the end, your total score will be the cumulative number of points you have received, out of the expected number of points if you successfully fixed ten issues (grades will not exceed 100%).

Please note that any formatting fixes, including the issues specified in the “Formatting” section of the code quality guidelines, will not result in credit in any week. Additionally, fixing the same issue multiple times will not result in credit for subsequent fixes.

The due dates for the five checkpoints are specified on the course calendar.

Files

You will at some point modify the following files in your fixes.

• main.c
• regex.c
• regex.h
• testregex.c

Restrictions

To facilitate testing, we have the following requirements:

• You should not write any code to be compiled other than in the main.c and regex.c files
• Similar to the above, you should not include any other .h file headers in code to compile other than regex.h
• Your main function should always live in main.c
• You may not change the names of the main.c, regex.c, or regex.h files
• You must maintain the matches function header in regex.c in that you may not change the name, arguments, or return type. It also must remain in the regex.c file, and have a header in regex.h. You are of course free to change its contents.
• You must call matches somewhere in your main.c file, for the purpose of finding matching file names.
• Your matches function must work with the regex_t object we have given you, and you may not modify regex_t’s name or fields.
• Do not use the names ref_matches, match_ref, or compare_char_ref for any of your functions. This is because for one of our tests we replace your regex code with our reference regex code behind the scenes, and we use these function names, so reusing these names may cause this test to fail

The smoke_main and smoke_regex tests should check for these issues. If you fail either of the smoke_ tests and cannot figure out why, please request office hours from a member of course staff. Additionally, the main tests and mainreplacedcode tests should always pass.

Testing Your Code

You can run make test at any time to test your changes’ functionality, and it should always pass (unless you are working on the regex portion and add regex tests that might fail - see regex document). You can check if your code compiles, or create an executable to run custom arguments with, with the command make main. It is recommended you play around with compiling and executing the program as part of figuring out how it works.

An important note - print statements in your code will cause many of our tests to break. If you want to print and test simultaneously, we suggest you use fprintf - e.g. fprintf(stderr, "statement")