Basic information

Welcome to the wiki of mtdef. This wiki is built in order to avoid any misunderstanding. With this wiki we clear what we think of some subjects.


We use a number of names that are known. In order to avoid any misunderstanding, we make clear what we think of some naming. You can read them at the mtdef wiki.


Bracket naming

Here we make clear what we think of the following bracket names.

• brackets   => ()
• braces     => {}
• crotchets  => []
• brokets    => <>

    "=>" says for what we use that bracket name.


Medial capitals naming

We use a number of names that are known. In order to avoid any misunderstanding, we make clear what we think of the following cases.

                Programming | Files | Comments.
• camelCase  =>      x      |   x   | Mostly used for variables.
• PascalCase =>      x      |   x   | Mostly used for functions.
• snake_case =>      x      |   x   | Mostly used for website files.
• UPPERCASE  =>      x      |       | Mostly used for flag variables.
• lowercase  =>             |   x   | Mostly used for website files.
• lisp-case  =>             |   x   | Also known as spinal-case or kebab-case.
• Train-Case =>             |   x   | Almost never useds.
    
    Here are some of our own casing names:

• HIGH_CASE  =>      x      |       | Combination of snake_case and UPPERCASE.
• dot.case   =>             |   x   | Rework on snake_case. Used like: main.min.js

    "=>" says for where we use that casing name.

If we start with an underscore followed by a name shown above we mean to use the name notation with the underscore.
Example: a name with _ and camelCase, we show you the following: _camelCase.

NOTE: We do not call it dot casing when entering objects in JavaScript or adding string variables in PHP


What are cookies?

A cookie is a small piece of data sent from a website and stored on the user's computer by the user's web browser while the user is browsing.


What we save

For what do we use cookies and eat them?
• [MTDEF-C] If you want to use our cookies
• [MTDEF-S] Our themes and styling


Software release state abbreviation

Alpha states:
• Pre-alpha: P.A.
• Open-alpha: O.A.
• Closed-alpha: C.A.

Beta states:
• Open-beta: O.B.
• Closed-beta: C.B.

Release states:
• Local release: L.R.
• Candidate release: C.R.
• Official release: O.R.


Pre-alpha release state

Pre-alpha refers to all activities performed during the software project before formal testing.


Open-alpha release state

The open-alpha phase of the release life cycle is the first phase to begin software testing. This testing is for all skilled programmers that use our products.


Closed-alpha release state

The closed-alpha phase of the release life cycle is our second phase to do retesting the software. This testing is primarily focused on the failed tests of the open-alpha release state.


Open-beta and Closed-beta release state

The beta phase generally begins when the software and it features are complete but likely to contain a number of known or unknown bugs.

The open-beta release state is a unstable release with all of the final functionalities. You can start building on the open-beta and release your product when the OR is finished.

The closed-beta release state is a unstable release with a part of the final functionalities. The closed-beta is a unstable version of a L.R. A closed-beta is created when one of our developers create a fork of one of our products. This happens mostly for Game Jams.


Local release state

The local release state is a stable release with a part of the final functionalities. A local release is created when one of our developers create a fork of one of our products. When that fork becomes stable after some C.B. testing we may release it under a L.R. This happens mostly for Game Jams and almoost never gets to the L.R. state. If the L.R. version can easily be used across other projects we create a O.R.


Candidate release state

This is the state of product stabilization, all product features have been designed, coded and tested. This heppens when the development team agrees that no entirely new source code will be added to this release. There could still be source code changes to fix defects, changes to documentation and data files, and peripheral code for test cases or utilities. Beta testers, if privately selected, will often be credited for using the release candidate as though it were a finished product. Beta testing is conducted in a client's or customer's location and to test the software from a user's perspective.


Official release state

The official release state is a stable release with all the final functionalities for that version. With the official release we may start creating other products like an API, tutorials and examples.



We use this icon to notice that there was/is one person work(ed/ing) on that project




We use this icon to notice that there where/are 2 to 5 people working on that project




We use this icon to notice that there where/are more than 5 people working on that project




We use this icon to notice the achevement or project is copyright protected or has a license.




We use this icon to notice an achievement is achieved




We use this icon to notice an achievement is a registered




We use this icon to notice the achievement is a rollback or downgrade.




We use this icon to notice the achievement is removed.