MODULARIZATION

better modularization in the future modularization? you can understand pieces of it in insolation the amount of parts you need to look at to understand what a part is doing it is small you can replace it one at a time, you can test it one at a time?

what stands in the way of understanding pieces of our code?

. many of our data types are use in through the codebase . modules that need to know about dozen or hundreds of other modules . config.c module: initializing and configuring a number of things . control.c module: provide an interface to a number of modules and also tell controllers about anumber of modules . main.c module: it calls a lot of things Those are a bad sign where modularization breaks down.

Comment layer: everything in source comment. - it is separate in different layers. Source OR: everything else.

Increasing modularity: reducing data visbility and exposure (a second one) reducing our calls

What tools do you use to do this? . suggestions: . sub-system idea used in tor . putting stuff in different directors . message passing system . systematic use of our handle stuff . tooling to measure our modularity violation

what do we want our code style to be?

Other things that make harder to understand code in Tor:

• big functions are hard to understand (more than 5 pages long)
• modules that go over several thousands lines long
• complex branching structure
• state transitions: we do not have a good way to represent state and state transitions (cut the number of posssible states of what a things can be in) (around the hashrings are complicated to understand)

I would like a new file script that does all the right things to create a new module

End of the project: have a rule that says that every new feature has to be in a module that is off by default.

A styleguide: how we want the code to be module.

GOALS FOR REFACTORING CODE

• Network scalability

• Network performance

• User-percieved performance

• Hardware-optimal performance

• Space/memory efficiency

• Ease of core component replacement

• Ease of development

• Reduced code complexity

• Better unit testability

• Technical debt reduction

• Security/stability