maxims - LeFreq/Singularity GitHub Wiki
The ideal code size says that there is a minimal size for your program or application that is ideal. This minimum is based on the divisions of problem scope that can be answered logarithmically. The challenge is to find the right divisions of your programming problem until you reach this minimum (100 log2(LOC)).
The following are some maxims for getting there:
- When your code size is still too big to fit in the equation, step back and try to understand what generality that you're missing and make a function for it. Nearly no one can tell you how to ideally make the application they're paying you for. They can give good hints on the architecture of your program (from however much time the need was served before a software solution was available and their own mastery of that history), but you need to assess how much expertise they actually have of their problem domain.
- Ideal abstraction: If more than three applications use the same service of your hardware, make it an OS call. If more than two, consider whether there is a general category and make an OS call for it.
- Continue this all the way downwards: Anything that your application does more than three times, put it in a named function. If you do it only twice, think about whether there is a category of general functionality and create it. Same goes for the same function in multiple files: push them upwards into the more general code-space.
- Return to step 1. Following this path will lead you to the Enlightenment.
- management: architect your program first, so that other coders can understand your engineering
- construction: understand the problem you're trying to solve before codng it
- hard-code constants as little as possible: lookup the values, ask user, derive from other objects (and cache as necessary)
- encapsulation: don't duplicate code: put it in a function
- management: divide
- construction: conquer
- architecture: synthesis/encapsulate
- engineering: optimize
- endo-dimension: use no more than 4 parameters to a function. In case of meta-programs, like complilers this limit is 5.
- exo-dimension: if you're keeping more than 20 variables in play at any time, the complexity of your problem is over your head. Get a team.
- Build everything up from the machine types: ints, floats, sequential data arrays (strings)
- Somewhere there is a boundary between purity of the object model and practiciality of using structs: find it and document it, so people know where you build the fence
- Everything must follow the GOOP: clear object name, doctests, and four methods +/- 1 as documented
- Build from existing objects: search the dir for objects that match your function.
- Everything is an object and all objects are apps
- all nodes are named
- all nodes follow consistent basic commands: set, msg, clone, etc.
- test all objects at boot?
- Objects are not assigned to, they receive mnessages (which may or may not be stored as assignment).
- Objects to not simulate things in the real world, they add increasing levels of structure, sophistication, and constraints to data. A sequential storage object is a simple d
- Objects return whatever is in their >> method when they are used in a standard expression, like a variable is used.
- Objects don't hold magic states: once their >> contents are dumped, they return NULL.
- Objects hold one piece of data (a string counts as 1 piece) otherwise they should be broken up into separate objevcts. If they don't have a piece of data, they are a function.
- Objects an be freely composed of multiple objects. This is called delegation and distinguishes it from data. Data can't be delegated onto.
- All objects should do something interesting when run as an app.