diff --git a/docs/StarBase/StandardsAndGuidelines.md b/docs/StarBase/StandardsAndGuidelines.md
index d0d3d3f..bdcba1f 100644
--- a/docs/StarBase/StandardsAndGuidelines.md
+++ b/docs/StarBase/StandardsAndGuidelines.md
@@ -50,6 +50,7 @@ hide:
     * We prefer char * over String especially if you don't know what you are doing - which is a contradiction as strings can cause defrag and chars can cause crashes ;-)
     * Globals useful to put them in designated memory area?
 * Heap memory changes should be as minimal as possible and processing should be done on the stack (as that is cleared after each code block has finished). So heap should be used to store more the ‘data model’, which is more or less stable data. Like leds[] or mapping tables or Executables. Any processing can modify this but should use heap only to modify the ‘data model’. This then means that any structure (struct, class, containers) other then the data model should be avoided, best example is string but also vector should be used with great care as they might be classes on itself but inside their classes they do heap allocation and free and that is the tricky part. There are several ways to do this. Next to char string use of pointers or values by reference. Eg you can loop over a vector where each element is copied in the loop but you can also make each element a pointer to the element in the ‘data model’. Eg for (auto &element: executablesVector) or void function(ClassType &var). The & sign makes sure there is not vector or class element copy
+*  An object (and also struct) takes just the memory space of the variables it defines, the Variable object is one pointer and tons of code, Effect and Projection object is not allowed to have variables to minimize the overhead. They have overloaded virtual functions though, memory for function pointer will be allocated to admin this.
 * StarBase and StarLight have next to the main branch also a dev branch where all development will be done on, optionally branches from dev can be made for multi commit changes. All merging from dev to main must be done by pull requests so the release changes will automatically be propagated with the commits made into main
 * For files which are included in other files: All definition stuff should go into cpp files.
     * Compiling goes faster as an include will only include the header contents