Normalize "SBOM" to "Sbom" through most of the code base by DaveTryon · Pull Request #950 · microsoft/sbom-tool (original) (raw)

(Note: This replaces #947, which got into a state where the base was missing many of the changes from #924)

As called out in #685, our code is very inconsistent in its usage of "SBOM" and "Sbom". Older files seemed to start with "SBOM", then migrated somewhat toward "Sbom", but we have a bit of a mix. We punted on #685 because of compatibility concerns.

As we've discussed separately, SPDX 3.0 is a breaking change, so we have a window of opportunity to standardize our API. This PR is an attempt to name that happen, following the following rules:

1. The new standard is to follow PascalCasing
2. File names and class names are case-consistent
3. Let Visual Studio automate as many of the changes as possible
4. Make the commits as tightly scoped as possible
5. Try to keep the docs in sync with the code changes
6. To keep things clean, use "Sbom" in all code constructs, with 2 exceptions to come later:
7. Files that include "SPDX" in the name (minimize merge conflicts with API changes to support SPDX 3.0 #924
8. Leave the test files alone where possible. I think I renamed 1 test file by mistake, but I can back that out if we want
9. Since I'm working on Windows, which ignores case differences, the file renames were a 2-step process:
10. Rename SBOMFoo to SBOMFoo_, allowing Visual Studio to update all usages
11. Rename SBOMFoo_ to SbomFoo, allowing Visual Studio to update all usages
12. Build and run tests frequently along the way to make sure that we don't perpetuate breakage
13. Search for SBOM\w\w using regular expressions as a way to find cases that may have been missed

The PR itself is broad (93 files), but most of the review should be trivial.

Places where a case-sensitive grep for SBOM\w\w finds hits:

• Our ProductName is still "MIcrosoft.SBOMTool" - we'll probably need to keep this for backward compatibility with tools that consume our SBOM files
• Our docs use a namespace of SBOMApiExample - trivial change that won't impact the API
• Many tests still use SBOM in class and file names - will fix later as they don't impact the API

Proposed roadmap:

1. Merge API changes to support SPDX 3.0 #924
2. Update this PR to reflect changes from API changes to support SPDX 3.0 #924
3. Merge this PR
4. Decide if we want to normalize "SPDX" to "Spdx". If so, create a similar PR
5. Create a migration document from API 3.x to 4.0 (we need do this even if we choose not to normalize the casing)
6. Normalize casing in test names (doesn't impact the API, could happen after we release the 4.0 API)