1. Static Analysis Tooling

• Git Hooks
• Case Study: Prettier and How it was Built

Static analysis tools operate on our source code (static) vs. running program (dynamic). They help us maintain the quality of our source code by fixing formatting issues, spotting suspicious coding constructs, or alerting us to common errors. Most of us wouldn't write a document in a word processor without spellcheck, and neither should programmers write code without linters and other static analysis tools. Using these tools is critical in a collaborative project with lots of contributors. Programming is hard, and the best programmers know that they can't do it without good tools to help them.

Add various static analysis tooling to your repo.

Automatic source code formatters (also known as beautifiers or "pretty printers") take source code as input and produce properly formatted output. Their goal is to establish a common format for all source code in the project.

Pick a source code formatter for your language and add it to your repo. Here are some suggestions, but you are free to use another that you want to try:

• JavaScript Prettier or Oxc
• Java Google Java Format
• Python Black or Ruff Formatter
• C# CodeFormatter or Reshaper or dotnet-format
• Go gofmt
• Rust rustfmt
• C++ clang-format

After you've picked a formatter, do all of the following:

• Read the docs for your formatter. There will be detailed instructions on setup and configuration. Make sure you've read them before you proceed.
• Setup the formatter in your project. This might mean adding files, packages, and settings.
• Often we configure settings for how the output should look (e.g., how to indent, where to put whitespace). Choose any settings and add them to the formatter's configuration. Ideally you shouldn't change the defaults if you can avoid it. Automatic source code formatting means letting a tool decide instead of using personal preference, so everyone hates some parts of how the code looks, but generally we all agree it's better.
• Add any files or folders to be ignored. You shouldn't format all the files in your project, only the ones you are developing.
• Create a simple "one-step" solution for running your formatter on the entire project from the command line. This could be an npm script, a shell script, or some other method common to your language or package manager. You must end up with a command you can run at the command line that calls your formatter.
• Run the formatter via the command line on your entire project's source code. Look at everything it's changed and make sure things are OK, then commit the changes.
• Make sure your project still works! Did you break anything in your program by making these changes? If so, fix them now and re-run the formatter until everything works again.

Linters help us spot common and subtle mistakes that all programmers make, or help us avoid certain code patterns that lead to bugs. We want to make it easy for ourselves and new developers joining our project to not introduce bugs or bad code.

Pick a linter for your language and add it to your repo. Here are some suggestions, but you are free to use another that you find:

• JavaScript ESLint or Oxc
• Java SpotBugs
• Python Flake8 or PyLint or Ruff
• C# StyleCopAnalyzers
• Go golint or golangci-lint
• Rust rust-clippy
• C++ clang-tidy

After you've picked a linter, do all of the following:

• Read the docs for your linter. There will be detailed instructions on setup and configuration. Make sure you've read them before you proceed.
• Set up the linter in your project. This might mean adding files, packages, and settings.
• Often we configure various linting rules (e.g., what to check for and what to ignore). Choose any settings and add them to the linter's configuration.
• Add any files or folders to ignore. Not everything in our project can or should be linted.
• Create a simple "one-step" solution for running your linter on the entire project from the command line. This could be an npm script, a shell script, or some other method common to your language or package manager.
• Run the linter via the command line on your entire project's source code, fix the warnings and errors it finds, and repeat the process until there are no issues. Once this is done, commit the changes.
• Learn how to add one-off lint ignore comments to your code. Often there are specific lines of code where, for one reason or another, we can't fix a linting error. Instead, we need to tell our linter to ignore this line, or ignore this whole function, or ignore this whole file. Make sure you know how to do this, and use it if necessary.
• Make sure your project still works! Did you break anything in your program by making these changes? If so, fix them now and re-run the linter until everything works again. It's usually possible to disable linters via special comments in your source code, but it's a better idea to fix the code so it doesn't have any issues. Rewrite any code that the linter says is problematic.

Running static analysis tools at build time (i.e., using our scripts) is great because we can automate it. However, it's also nice to provide a way to integrate them into our editor or IDE so that we get the benefits while we are writing code. An automatic source code formatter can be run whenever we save a file. Similarly, we can have a linter running continuously and underlining errors or warnings as we type. This lets us fix issues as soon as make them, and helps us produce better code.

We could set up our own personal editor to work the way we like, but then new contributors wouldn't have the same development environment as we do. Instead, it's common to create configuration files and folders in our project that get read by the user's editor and and applied automatically. For example, Visual Studio Code settings can be placed in a .vscode/ folder.

Research how to integrate your Source Code Formatter and Linter into your editor. I highly recommend using VSCode, but you can use which ever editor is most common to your language. Add any necessary configuration folders, extensions, and files to run your formatter when the user save's their code. Also, integrate the linter so that warnings and errors are automatically shown.

Both steps will likely involve adding plugins or add-ons to your editor, and this may also be something that you can include in a configuration file.

If you're still up for a challenge, try to setup a git pre-commit hook to run your source code formatter on any changes that are being committed. This will help developers not forget to run the formatter before they submit any changes or make a pull request. The process for creating a git hook will be slightly different for each language or platform, so do some research.

• Watch the Video lecture
• Do the Readings
• Finish work on Release 0.2
• Follow instructions to add static analysis tooling to your repo