Teaching AI composite software design was the best prompt I've ever made. It's like it actually thinks about software quality and maintainability consciously afterwards.
Still only good for small, targeted snippets though, but the quality of those snippets is much improved. If you ask it to produce a functional decomposition prior to generating a lot of code, that code is typically better structured too. If any of you vibers out there try it out, I hope it's helpful.
---
The prompt, for anyone who wants to try it out:
```
# Instructions
## Software Design Principles
The following is a methodology for evaluating software code according to Composite Design (Glenford Myers, 1975) in the form of Functional Decomposition. Understand this criteria when writing and analyzing code, aiming for the highest module strength and loosest coupling possible.
### Definitions
- **Module**: A group of program statements that have a defined beginning and end, collectively referenced by a module name, and can be called from other modules. Corresponds to the "function" in most modern languages.
### Functional Decomposition
If a program contains modules A, B, and C, where A calls B and C, and B calls C, the functional decompositions would be notated as follows. Each module has a name and is referred to with a capital letter starting with A, B, C... then AA, AB, AC... and so on. The first column shows whether the called module has other dependencies, with "—" indicating a root module and "↓" indicating a mid-level module, which must have a section listing the modules it calls, until only root modules remain. Call numbers are sequential and unique, even if the same module is called in several other modules, and do not indicate the order in which modules are called.
---
**A. Name of Module A**
| | Call # | Module | Module Name | Inputs | Outputs |
| --- | ------ | ------ | ---------------- | ------ | ------- |
| ↓ | 1 | B | Name of Module B | A | X |
| — | 2 | C | Name of Module C | B | Y |
**B. Name of Module B**
| | Call # | Module | Module Name | Inputs | Outputs |
| --- | ------ | ------ | ---------------- | ------ | ------- |
| — | 3 | C | Name of Module C | C | Z |
---
### Module Strength
In composite design, there are several levels of module strength. In the generated code, make each module as strong as possible.
- **Functional**: The strongest module. All of the elements are related to the performance of a single function.
- **Informational**: Performs multiple functions where the functions all deal with a single data structure (like a mapping). Represents the packing together of two or more functional-strength modules.
- **Communicational**: A module with procedural strength, but all the elements either reference the same set of data or pass data among themselves.
- **Procedural**: Perform more than one function, where they are related to the procedure of the problem.
- **Classical**: A module with logical strength, but the elements are also related in time, e.g. sequentially.
- **Logical**: A module of coincidental strength, but the elements are related logically.
- **Coincidental**: A module in which there is no meaningful relationship among its elements.
### Module Coupling
In composite design, there are several degrees of module coupling. In the generated code, make each module as loosely coupled as possible.
- **Data**: A relationship that is not content, common, external, control, or stamp coupled. All input and output are passed as arguments or return variables. All arguments are data elements, not control elements or data structures.
- **Stamp**: A relationship where both modules reference the same data structure, and the data structure is not globally known.
- **Control**: A relationship where one module passes control elements to another. Such an argument directly influences the execution of the called module, such as function codes, flags, and switches.
- **External**: A relationship where both modules refer to the same global variable, but it is an individual data item, not a data structure.
- **Common**: A relationship where both modules refer to the same global data structure (such as a COMMON environment in FORTRAN).
- **Content**: A relationship where one module makes direct reference to the internal contents of another module, like program statements or private variables.
```
