Home

DeOS v0.00.0000 :/: --------- :/: MENU :/: STATUS :/: LOGS :/: PERMA

---

The languages of intelligence (writing) and self-interest (money) are the mind's greatest creations; both must be decentralized or all is lost. —DeSantis

---

Contents ﹂ Rules    ﹂ Style    ﹂ Interfaces    ﹂ Debugging    ﹂ Testing    ﹂ Performance    ﹂ Portability    ﹂ Xanadu

---

Rules

A : Style

• 00 : Use descriptive names for globals, short names for locals.
• 01 : Be consistent.
• 02 : Use active names for functions.
• 03 : Be accurate.
• 04 : Indent to show structure.
• 05 : Use the natural form for expressions.
• 06 : Parenthesize to resolve ambiguity.
• 07 : Break up complex expressions.
• 08 : Be clear.
• 09 : Be careful with side effects.
• 10 : Use a consistent indentation and brace style.
• 11 : Avoid function macros.
• 12 : Parenthesize the macro body and arguments.
• 13 : Give names to magic numbers.
• 14 : Define numbers as constants, not macros.
• 15 : Use character constants, not integers.
• 16 : Use the language to calculate the size of an object.
• 17 : Don't belabor the obvious.
• 18 : Comment functions and global data.
• 19 : Don't comment bad code, rewrite it.
• 20 : Don't contradict the code.
• 21 : Clarify, don't confuse.

---

B : Interfaces

• 00 : Hide implementation details.
• 01 : Choose a small orthogonal set of primitives.
• 02 : Don't reach behind the user's back.
• 03 : Do the same thing the same way everywhere.
• 04 : Free a resource in the same layer that allocated it.
• 05 : Detect errors at a low level, handle them at a high level.
• 06 : Use exceptions only for exceptional situations.

---

C : Debugging

• 00 : Look for familiar patterns.
• 01 : Examine the most recent change.
• 02 : Don't make the same mistake twice.
• 03 : Debug it now, not later.
• 04 : Get a stack trace.
• 05 : Read before typing.
• 06 : Explain your code to someone else.
• 07 : Make the bug reproducible.
• 08 : Divide and conquer.
• 09 : Study the numerology of failures.
• 10 : Display output to localize your search.
• 11 : Write self-checking code.
• 12 : Write a log file.
• 13 : Draw a picture.
• 14 : Use tools.
• 15 : Keep records.

---

D : Testing

• 00 : Test code at its boundaries.
• 01 : Test pre- and post-conditions.
• 02 : Use assertions.
• 03 : Program defensively.
• 04 : Check error returns.
• 05 : Test incrementally.
• 06 : Test simple parts first.
• 07 : Know what output to expect.
• 08 : Verify conservation properties.
• 09 : Compare independent implementations.
• 10 : Measure test coverage.
• 11 : Automate regression testing.
• 12 : Create self contained tests.

---

E : Performance

• 00 : Automate timing measurements.
• 01 : Use a profiler.
• 02 : Concentrate on the hot spots.
• 03 : Draw a picture.
• 04 : Use a better algorithm or data structure.
• 05 : Enable compiler optimizations.
• 06 : Tune the code.
• 07 : Don't optimize what doesn't matter.
• 08 : Collect common subexpressions.
• 09 : Replace expensive operations by cheap ones.
• 10 : Unroll or eliminate loops.
• 11 : Cache frequently-used values.
• 12 : Write a special-purpose allocator.
• 13 : Buffer input and output.
• 14 : Handle special cases separately.
• 15 : Precompute results.
• 16 : Use approximate values.
• 17 : Rewrite in a lower-level language.
• 18 : Save space by using the smallest possible data type.
• 19 : Don't store what you can easily recompute.

---

F : Portability

• 00 : Stick to the standard.
• 01 : Program in the mainstream.
• 02 : Beware of language trouble spots.
• 03 : Try several compilers.
• 04 : Use standard libraries.
• 05 : Use only features available everywhere.
• 06 : Avoid conditional compilation.
• 07 : Localize system dependencies in separate files.
• 08 : Hide system dependencies behind interfaces.
• 09 : Use text for data exchange.
• 10 : Use a fixed byte order for data exchange.
• 11 : Change the name if you change the specification.
• 12 : Maintain compatibility with existing programs and data.
• 13 : Don't assume ASCII.
• 14 : Don't assume English.

---

G : Xanadu

• 00 : Every Xanadu server is uniquely and securely identified.
• 01 : Every Xanadu server can be operated independently or in a network.
• 02 : Every user is uniquely and securely identified.
• 03 : Every user can search, retrieve, create and store documents.
• 04 : Every document can consist of any number of parts each of which may be of any data type.
• 05 : Every document can contain links of any type including virtual copies ("transclusions") to any other document in the system accessible to its owner.
• 06 : Links are visible and can be followed from all endpoints.
• 07 : Permission to link to a document is explicitly granted by the act of publication.
• 08 : Every document can contain a royalty mechanism at any desired degree of granularity to ensure payment on any portion accessed, including virtual copies ("transclusions") of all or part of the document.
• 09 : Every document is uniquely and securely identified.
• 10 : Every document can have secure access controls.
• 11 : Every document can be rapidly searched, stored and retrieved without user knowledge of where it is physically stored.
• 12 : Every document is automatically moved to physical storage appropriate to its frequency of access from any given location.
• 13 : Every document is automatically stored redundantly to maintain availability even in case of a disaster.
• 14 : Every Xanadu service provider can charge their users at any rate they choose for the storage, retrieval and publishing of documents.
• 15 : Every transaction is secure and auditable only by the parties to that transaction.
• 16 : The Xanadu client-server communication protocol is an openly published standard. Third-party software development and integration is encouraged.

---