[Draft] Code style

This is a very beginning of defining a code style of the lib

• Use using instead of typedef - using is more readable
• Class can have super alias in its' scope only to its' superclass. Otherwise give it a different name
• Curly braces after if, for and while must be put on the same line not on the next one - same code less lines
• Place curly braces always after if, for, while and do operators even if body contains one line - someone may add line after you and forget to place curly braces and you'll get incorrect behavior which probably compiles well
• All classes/structs are named with lowercase with underscore just like std's ones - one of sqlite_orm's goals is to look like it is a part of stdlib: storage_t, table_type, statement_binder
• public functions are named just like classes: begin, make_table, bind
• every #include from stdlib must have a list of functions/classes from it which are used in a current source file. These lists must be actual to keep includes in actual state and remove excess once they are not required: #include <string> // std::string, #include <cstddef> // std::nullptr_t, #include <algorithm> // std::find_if
• don't write constructors which can be replaced with initializer list constructors - less code -> same result
• don't make member field private/protected with single lined getter/setter - make a public field instead. Once you need logic in setter or getter - then make a refactoring, move to private/protected and add getter and setter. Least of getters and setters require logic but single field logic increases code from one line to seven:

public:
    int myField = 0;

vs

private:
    int myField = 0;
public:
    int getMyField() const {
        return this->myField;
    }

    void setMyField(int value) {
        this->myField = value;
    }

• always use this while accessing member fields and member functions cause it makes reading complicated template code easier
• use std::string &str instead of std::string& str cause & and * are not a part of a type:

int* a, b;

doesn't declare two pointers but one pointer and one int. Same for return type of functions

• Avoid using C macros - macros make compilation complicated especially when the project is large and has a lot of third party libs
• Use enum class always instead of legacy enum - enum class allows making a clearer code
• Prefer reference if you need to pass/store non-nullable variable instead of pointer - pointer is nullable and can be null but reference cannot
• Write #pragma once at the beginning of every header file. Don't use #ifndef include guards cause they look huger and do the same thing and #pragma once is supported by most popular compilers
• Write explicit capture in all lambdas [this, &index, stmt] instead of implicit [=] or [&] cause sometimes Visual C++ can't compile well this code
• Never use using namespace ... within a namespace scope or in the global score in headers. Use it within function/class scope only. Including this lib must not create name collisions with other code in project
• Don't write code inside comments - use comments for some human readable description not for code 'disabling'. If you need to 'disable' some code lines just remove them - you can revert changes with git at any time.
• Don't write unused functions/classes/variables/consts. If code becomes unused remove it. It can be restored in any minute with git if it becomes required someday.