4 - Comments are as much important as source code. Text encoded state of
5 assistive assembly writing software is welcome at the end of a comment
6 line, expect several assistants if those become reality.
7 - The assembler should be parsing friendly to a C preprocessor. Namely, the
8 assembler syntax should be friendly to the tokenization performed by a
10 - The usage of the assembler macro language should stay used to the
11 minimum because making assembly code depend on a super complex
12 macro language is no better that to make it depend on a compiler.
14 simple C89 with bits of C99:
15 - only one loop keyword "loop" (#define loop for(;;))
16 - avoid "anonymous code blocks"
17 - variable declarations only at the start of a block
18 - don't use the const keyword, use literals/enumerations.
19 - avoid convoluted code as much as you can.
20 - try to write explicit code as much as you can. Way better to have more
21 explicit lines than less with a lot of implicit information.
22 - use the preprocessor to deal with a hierarchy of namespaces (more work,
23 but need less complex compilers, which is always better in the end)
24 - use namespaces to ensure the code is "1 compilation unit friendly", namely
25 to avoid identifier names (symbol, types, etc) collisions.
26 - implicit casts should be avoided and be mostly explicit. For instance,
27 don't need to cast from/to void pointers (void*).
28 - always presume a naive and simple compiler, never a super
29 optimizing/guessing one.