CPSC 480-020 Software Engineering (SE) Fall 2024

To implement the project below, follow the TDD process. The Brightspace course page has an invitation link to create the GitHub Classroom repository.

Create your repository (via GitHub classroom) and implement each one of the Rules separately with a single pass through the TDD workflow (red, green, refactor). Each rule (and error message) is implemented in a single commit.

Due Dates

The purpose of many class exercises and projects in this class is to practice good workflows of actual, real, 40-hours-a-week software development. Due to time limitations, each part of a project cannot be very long. Treating this as a "race" at the last minute is not part of SE or any good workflow. It tends to produce less-than-optimum software in both external quality, i.e., bugs, and internal quality, i.e., poor design.

Therefore, the project has progressive due dates regarding the number of rules implemented. Each failure to meet a due date will result in a 10-point reduction in your score out of 100. The following are due dates, not the day you have to work on them, unless you wait until the last day.

Due dates are given for each step. No work will be accepted after the last due date.

All commits must appear in the repository on GitHub. Commits or code changes in GitHub Codespaces do not count.

Project

The input for a source-code static analysis tool can come from multiple sources, including individual files (e.g., main.cpp), directories of source-code files (e.g., src/), source-code archives (e.g., project.tar.gz, file.zip), and standard input (i.e., stdin, e.g., std::cin). In addition, solitary files and source-code archives can include a URL, e.g., https://mlcollard.net/fragment.cpp

To perform the code analysis, the source code is wrapped in a single XML element with metadata about the source code, including filename, programming language, URL, hash, LOC (lines of code), and timestamp. For the source code:

the resulting XML is:

Note: Scroll to see all the attributes.

The attribute hash is of the source and is a SHA1 160-bit (20 bytes) represented in 40 hex characters, which is what Git uses. The xmlns:code="http://mlcollard.net/code" is not an attribute but an XML namespace declaration, handled automatically by XMLWrapper.

The general attribute rules are:

• The order of the attributes in your output must follow the order above.
• If the value for an attribute is empty, the attribute is not displayed

The attribute's variety of input sources and program options follows the Rules stated below.

Assignment

Implement the following rules following a Test-Driven Development (TDD) approach. Write a test in CodeAnalysisTest.cpp, implement the minimal code necessary to get it working in CodeAnalysis.cpp, refactor/clean up the code to make it clear and logical, and then commit with an appropriate commit message.

All commits must result in a program that compiles and passes all tests. This means you must successfully compile and pass the test program before a commit. Any commit that does not build will result in a 0 for that step, and every commit will be checked.

• The code to implement is in the function formatAnalysisXML().
• Do not change or create tests for the function filenameToLanguage().
• Do not create any new functions.
• Using libraries or including files beyond those already defined is unnecessary and strictly forbidden.

Rules

The following rules are unordered. Do not refer to them by number.

Error Handling

All error messages are written to standard error (i.e., std::cerr) on a separate output line, and the function should return an empty string.

• If the file extension is used to determine the language, and there is no mapping for that language, output the error message “Extension not supported”
• When the input is from standard input, and a language cannot be determined, output the error message “Using stdin requires a declared language”

Workflow

The workflow for implementing one rule:

1. Add a single new test case for a single specific rule in the test program CodeAnalysisTest.cpp
2. Successfully compile and build
3. Run the test program and verify that the test case fails
4. Add the implementation only for the new test case in the file CodeAnalysis.cpp
5. Successfully compile and build
6. Run the test program and verify that all tests pass, including the new test case
7. Refactor the test and the added code
8. Successfully compile and build
9. Run the test program and verify that all tests still pass, including the new test case
10. Commit with the appropriate commit message

Refactoring Guidelines

All implementation should result in code that is as clean and clear as possible. For this case:

• Output of a particular attribute must occur only once in the code.
• Ideally, each rule implementation should only require one additional if-statement.
• Prefer simple conditions over complex conditions.
• Prefer initialization and if-then over if-then-else.
• Separate the logic of calculating an attribute value from the output of the attribute value.
• Initialize variables on declaration instead of declaring and then initializing.
• Prefer std::string_view to std::string.
• Instead of comparing strings to "", use the empty() method.

Evaluation Environment

The project is built and graded in a Docker container running srcml/codespaces, which is the same environment as GitHub Codespaces for this project. It is based on Ubuntu 22.04 and uses the GCC compiler.

On macOS, clang is the default compiler and the one you want to use in most cases. This should not cause a problem with this program. However, before you commit, I recommend ensuring your code can build and pass the tests with GCC and the default compiler, clang.

Add GCC via homebrew:

brew install gcc

The preset macos-gcc (in the file CMakePresets.json) provides settings to compile with GCC:

cmake .. --preset macos-gcc

This preset only appears in macOS and not in Linux or Windows.

To return to using clang:

cmake .. --fresh

Instead of flipping back and forth in the same build directory, use two build directories, one for clang and one for GCC. Be sure to build and test in both build directories before you commit. Note It might seem like a pain to have two build directories, but it is not uncommon in real software development and is a good skill to have.

Grading

Your score will depend on the following:

• Meeting the deadlines.
• Following the TDD process. This must be reflected in your commit history, both when commits are made and the commit messages.
• Successful implementation of the rules.
• Following the commit message guidelines.
• Coding style, including use of if-statements. The function logic should be as simple as possible. Pay attention to the coding style criteria given in class.