# sch-rnd modularization

## Why bother...

I believe good software should be modular. This is especially important in the context of large software, such as CAD applications. There should be a thin core that can model the world and provide the basic operations defined on it but anything else should go in separate modules.

Sch-rnd is built up from scratch with modularity in mind.

I believe such modularization has benefits on multiple levels:

- it is possible to compile smaller, potentially faster executables by omitting features the specific user would never use anyway
- in a distribution dynamic-link plugins can be distributed as separate packages providing the user with the option to decide what features to install
- such plugins have to have some sort of APIs if they want to reference each other or if the code needs to reference them; such an API may not (and often did not) exist when the code is part of the core

## Code size in charts

### Overall distribution

All numbers are in SLOC and are acquired running sloccount on the given directory. While lines of code alone is not a true measure of complexity, it's a good estimation. The slices of pie charts are the major components of the sch-rnd executable.

Main components

The main components are:

- libcschem: library that is operating the data model and the modular compiler
- sch-rnd app: application code: main() and the central infrastructure
- 3rd minilibs: 3rd-party minilibs shipped with sch-rnd; these minilibs are specialized in narrow tasks
- plugins: optional modules implementing the actual functionality (each can be disabled)

### Zooming on to the plugins

total size per class

IO plugins

feature plugins

export plugins

GUI plugins

engine plugins

(Red means the plugin doesn't really work).

## Progress in numbers

Below is a table with the summary of core plugins.

module | size [sloc] | status | configure default | class | description
--- | --- | --- | --- | --- | ---