Since our implementation is a Command-Line interface, there is a need to run different functionality depending on which command the user selects. The `run()`-function above is responsible mapping commands and arguments to a runnable function. It is basically a giant switch. So why do I like this piece of code?:
-**Decouples input-logic from application-logic** - The `run()`-function decouples application-logic from the `Config`-struct generated by the input-parsing code. In the `run()`-function one would be tempted to just pass the `Config` directly as an argument to all the underlying application functions. like `connect(config)`, `did(config)`, etc. This would then introduce the `Config`-struct as a dependency to the large parts of the codebase, making changes to the `Config`-struct potentially lead to very broad changes. By not falling into this temptation, and instead being very specific about which arguments are passed furteher on to the underlying functions, we avoid this trap, and the coupling between input-code and application-code remains very low. In pratice this means that if we change the layout of the `Config`-struct, most of the time we only have to change how the `run()`-function passes it's arguments further down the pipeline, leaving most of the codebase untouched. Decoupling is important in a collaborative environment. Decoupling makes the distinction between different parts of the codebase clear, and makes it easier for multiple people working on the codebase at the same time, without stepping on each others toes (merge conflicts).
-**Overview** - The `run()`-function is mostly self-explanatory, and gives a great overview of all functionality of the system. It is almost like a help-page.
-**Decouples data from functionality** - I already touched upon decoupling, but there is another point to be made about this. Instead of having free-standing functions for application logic amd the need to map commands to which free-standing function they are supposed to run in an imperative fashion, one could instead use an object-oriented approach and bundle the mapping between between commands and functionality inside the `Config`-struct. This introduces an inverse coupling of the one discussed in my first point about decoupling. Keeping data decoupled from functions allows us to only select if we only want to depend on the data layout, only depend on functions or both. Bundling data and logic together forces us to always depend on both.
### 2.2 A link to, and discussion of, code you consider bad
DID-CLI's init-function starts with creating a bunch of directories, if they don't already exist. There are multiple reasons why this code is bad:
-**No else** - For every one of these ifs there is an else. In this context getting in the else-block means: "The directory you tried to create already exists.". In this case, the init() function should just exit and do nothing. Instead it continues executing, potentially corrupting existing files. What should have happened here is that the init() function should exit, and then give an error message to the user. Something like this: `"A `.did/`-directory already exists. Do you want to overwrite it? (yes/no)"`.
-**.unwrap()** - In Rust, whenever you are using `.unwrap()`, it means: Succeed or panic on this line and stop execution. This may be ok in many cases. It is not ok in this case and probably it was just done because of lazyness. Failing to create a directory is a potential error that could happen, and it is not a programmers error. Therefore we should have a way to recover from the error. Maybe give an error to the user and ask if he wants to "try again?". Also if the creation of directory number 3 fails, after 1 and 2 succeeded, there should be a cleanup of directory 1 and 2, before exiting the program. Leaving 1 and 2 there without a directory 3 and 4 is not a valid state for the application to be in. Either no directories should be present or all 4. In database-terms: The directories should be created as a single transaction, and the transaction should be rolled back to the initial state, if anything fails during the transaction.
### 2.3 A link to two pieces of code, a before and after refactoring.
This will include a discussion of why the code was refactored
