Splitcells™ Network's Guidelines

Guidelines describe, how something should be done or what the guiding principles are. It makes actions more reproducible and predictable. Guidelines are nothing more and nothing less. If these guidelines are overridden a reason should be present, and be documented or commented, if it is feasible.

These guidelines refer to the Splitcells Network project. These guidelines do not handle communities and other social interactions. The communities and co. has to do this by themselves.

For (programming) languages and document formats prefer using the most official or the most common guidelines, if there are no guidelines of this project applying to the aspect in question. In other words, language and documentation specific guidelines of this project try to only override public guidelines instead of writing complete custom guidelines from scratch.

The project and its parts should be portable, extendable, adaptable and deletable .

Every part of the project has to be discoverable from the root project. This specifically means, that the path of a file or content should identify and describe or at least summarize the content's meaning. (For an XML element, this would be the file path + the XPath pointing to the XML element.) This is called a discoverable path in this project and a tree build of such paths is called a discoverable tree.

This also means, that in the ideal case, one should be able to guess, where to look for a particular thing without knowing where the files are located. If this is not possible, it should be possible to find the thing in question by starting from the main/root document. Here establishing and maintaining this is called project rooting.

Meta

These are the guidelines for the Splitcells Network project. Do not consider these code guidelines for your own code.

  1. toDo
      1. todo
        1. Make all assumtions visible (i.e. nullable variables via Optional).
      1. toDo
        1. Fork, join and cathedral development protocol.
      1. toDo
        1. Programs should be primarily seen as tree/table transformers in order to simplify programming paradigm and language use.
      1. toDo
        1. Make it possible to tolerate out of date documentation.

Error Log