smart contract & solidity rules

Some important details about Solidity specific/ Ethereum (Smart Contracts):

Background: 
A contract has functionality (functions) and state (data).
Magic Global Variables: msg, tx, block
Anyone in the world has access to a smart contract (set/ get) the state.
But there are access restrictions that can be configured.
-address type is a 160 bit value, storing external contracts, keypairs.
-public generates a function that can be accessed outside of the contract.
-mapping(address => uint) public balances; complex datatype maps addresses to uint, like hashtables. *** use more advanced datatype
-event Sent(address from, address to, uint amount); blockchain nodes listen for those events.
e.g. to listen to an event: call the constructor of the corresponding contract and then call Sent(): Coin.Sent().
-Gas, upon creation each txn is charged with gas. Its purpose is to limit the amount of work required to execute the txn and pay for this execution (gas_price * gas ).
Storage, key-value store, each account has persistent memory area. 
Memory, cleared instance for each message call. ** Memory is more COSTLY, the larger it grows.
EVM is a stack machine, Access to the stack is limited to the top 16 elements.
Logs feature is used in Solidity to implement maps.
Selfdestruct, code of a contract is removed from the blockchain.
Function Types: internal(by default) ones can be called inside the current contract; external functions can be passed via and returned from external function calls.

Common Rules:
1. Empty Files/functions should be removed
2. MultiLine Comments not empty
4. Contracts should not be empty 
5. String literals should not be concatenated NOT FOR SOLIDITY
6. Boolean checks should not inverted 
7. Constants should come first in equality tests NOT FOR SOLIDITY
8. Variables not shadowed
9. An open curly brace should be at the end of the line DONE
10. Follow Cognitive Complexity Rule 
11. Unused local variable
12. Unused function parameters
13. Parameter names should not duplicate the names of their methods
14. Variables should be defined in the blocks where they are used

Solidity Specific Rules
1. Pragma (Solidity) version should be the latest
2. Use string only for dynamically allocated data (NOT YET)
3. Function state mutability can be restricted to pure, if the function does not read/modify the state
4. Specify constructor’s visibility either public or internal
5. Defining constructors as functions with the same name as the contract
6. is deprecated use “constructor(...){...}”
7. Pragma does not exist
8. Deprecated suicide function
9. Avoid tx.Origin (it will be deprecated, the contract will not work well with multisig wallets, it can lead to security issues)
10. For security reasons avoid sha3 in favor of keccak256
11. Access Restriction Rules: use modifiers pattern: In the beginning the required condition is checked. Afterwards the execution jumps back
to the initial function. This behavior is indicated by an underscore (_;)
Guard Check Rule: The desired behavior of a smart contract would be to check for all required circumstances and only proceed if
everything is as intended. This rule ensures that all parameters of public/external functions that are not pure or view are validated with
require()
13. String Comparison Rule: for string comparison it is suggested to use keccak256 to check if the hashes of the strings are equal.
14. Gain access to data stored outside of the blockchain through an Oracle. The contract requesting info from an outside source,
assembles a query and sends it in a txn to the oracle. The contract needs to have a callback function, so that oracle can deliver the result
of the query. Include a check in the callback function so that only the specified oracle could call it
15. Transfer Ether Securely: since there is no semantics information yet. I raise an issue each time a send() function is called
16. Randomnness: generating a random number, taking into account block, could introduce serious security vulnerabilities
17. Lower Gas Bytes Rule: developers should use bytes instead of byte[], it’s cheaper in terms of gas consumption
18. Checks Effects Rule: When handing over control flow to an external entity is is important to guard your public functions.
Specifically, issue is raised when external interactions; transfer, or send is not the last step of a public function
19. Tight Variable Packing: Optimize gas consumption when storing or loading statically-sized variables
20. “var” keyword is deprecated, two cases variable declaration and tuple assignment