As with any long-standing software project, technical debt will accumulate, and should be taken care of when possible. In this session, we talked about sources of Tor's technical debt, when and how to tackle it, and coding standards for the future to help not accumulate technical debt.

We talked about using tools to analyze the complexity within the current code base, and how to reduce interdependencies. Nick talked about a call graph tool he has been working on, and we talked about other potential candidate tools. We decided that we didn't want to use something heavyweight that requires adding annotations to the code.

With any software project, balancing adding new features versus refactoring existing code is always tough. We talked about how when adding new features, this is an opportunity to refactor existing code as well.

We also focused more on coding standards to reduce tech debt in the future. Some things we discussed are:

- Limiting function size to what can fit within a screen (50-60 lines)

- Limiting test function size similarly, and using contexting to group similar tests

- Limiting module size, focusing on single responsibility

- Reducing what is available publicly. or.h is a good candidate for refactoring, a lot of its structures can be made private within modules

- Tests should be added for new functionality, and when changing legacy functionality

- Reducing size of commits, which should help when reviewing code