CASCO Design Goals

CASCO is a [framework] for...

fast implementation

CASCO users shall be able to quickly produce prototypes, first iterations or tracer bullets.

  • deployment should be easy, robust and well documented
  • CASCO should deliver enough out-of-the-box functionality to write complete applications without having to extend the framework

flexibility

CASCO users shall have the ability to override every aspect of behavior of the framework with as little 'copy-paste-edit' programming as possible.

extensibility

CASCO users shall have the ability to add new functionality to the framework with as little 'copy-paste-edit' programming as possible.

shallow learning curve

New CASCO users shall be able to find their way around the framework quickly.

Strategies to achieve this goal include:

  • consistent function names and signatures
  • nicely formatted and readable source code
  • well documented source code
  • good API documentation
  • good tutorials/getting_started/cookbook/introduction_to wiki pages

refactorfriendliness

CASCO users shall find refactoring a walk in the park.

Strategies to achieve this goal include:

  • disallow hard path references in code.
  • provide mechanisms to move classes around without breaking the application.
  • provide unit tests with as much coverage as possible.

no bloating

CASCO users (and the CASCO framework) shall never be distracted by junk code, files and/or modules.

Units of Code that are never used in an application should be isolated (into a separate module) from code that is in use. Then the unused module can be switched of (not registered) or, even better, removed from the application source tree.

Bloating is bad because it may impair performance and it makes traversing/reading the code more difficult. Skipping unused sections, or even unused files in a directory, while reading code is a mental strain.

re-usability

CASCO users shall be able to re-use code written for one application in another without hassle