Added two subsections on best practice

Author: vkokosh

docs/develop/smart-contracts/security/secure-programming.mdx

@@ -0,0 +1,76 @@
+# Things to Focus on while Working with TON Blockchain
+
+In this article, we will review and discuss the elements to consider for those who want to develop TON applications.
+
+## Checklist
+
+### 1. Name collisions
+
+Func variables and functions may contain almost any legit character. I.e. `var++`, `~bits`, `foo-bar+baz` including commas are valid variables and functions names.
+
+When writing and inspecting a Func code, Linter should be used
+
+### 2. Check the throw values
+
+Each time the TVM execution stops normally, it stops with exit codes `0` or `1`. Although it is done automatically, TVM execution can be interrupted directly in an unexpected way if exit codes `0` and `1` are thrown directly by either `throw(0)` or `throw(1)` command.
+
+### 3. Func is a strictly typed language with data structures holding exactly what they are supposed to store
+
+It is crucial to keep track of what the code does and what it may return. Keep in mind that the compiler cares only about the code and only in its initial state. After certain operations stored values of some variables can change.
+
+Reading unexpected variables' values and calling methods on data types that are not supposed to have such methods (or their return values are not stored properly) are errors and are not skipped as "warnings" or "notices" but lead to unreachable code. Keep in mind that storing an unexpected value may be okay, however, reading it may cause problems e.g. error code 5 (integer out of expected range) may be thrown for an integer variable.
+
+### 4. Unlike other blockchains, TON does not contain revert messages, only exit codes
+
+It is helpful to think through the roadmap of exit codes for the code flow (and have it documented) before starting programming your TON smart contract.
+
+### 5. Messages have modes
+
+A collection of flags represented as a single number, one of them may serve as self-destruct and one serves to send all remaining coins on balance. It is essential to check the message mode.
+
+### 6. TON fully implements the actor model
+
+It means the code of the contract can be changed. It can either be changed permanently, using `SETCODE` TVM directive, or in runtime, setting the TVM code registry to a new cell value until the end of execution.
+
+### 7. TON Blockchain has several transaction phases: computational phase, actions phase, and a bounce phase among them
+
+The computational phase executes the code of smart contracts and only then the actions are performed (sending messages, code modification, changing libraries, and others). So, unlike on Ethereum-based blockchains, you won't see the computational phase exit code if you expected the sent message to fail, as it was performed not in the computational phase, but later, during the action phase.
+
+### 8. Func functions that have medhod_id identifiers have method IDs
+
+They can be either set explicitly `"method_id(5)"`, or implicitly by a func compiler. In this case, they can be found among methods declarations in the .fift assembly file. Two of them are predefined: one for receiving messages inside of blockchain `(0)`, commonly named `recv_internal`, and one for receiving messages from outside `(-1)`, `recv_external`.
+
+### 9. TON Crypto address may not have any coins or code
+
+Smart contracts addresses in TON blockchain are deterministic and can be precomputed. Ton Accounts, associated with addresses may even contain no code which means they are uninitialized (if not deployed) or frozen while having no more storage or TON coins if the message with special flags was sent.
+
+### 10. TON addresses may have three representations
+
+TON addresses may have three representations.
+A full representation can either be "raw" (`workchain:address`) or "user-friendly". The last one is the one users encounter most often. It contains a tag byte, indicating whether the address is `bounceable` or `not bounceable`, and a workchain id byte. This information should be noted.
+
+### 11. Keep track of the flaws in code execution
+
+Unlike Solidity where it's up to you to set methods visibility, in the case of Func, the visibility is restricted in a more intricate way either by showing errors or by `if` statements.
+
+### 12. Keep an eye on gas before sending bounced messages
+
+In case the smart contract sends the bounced messages with the value, provided by a user, make sure that the corresponding gas fees are subtracted from the returned amount not to be drained.
+
+### 13. Monitor the callbacks and their failures
+
+TON blockchain is asynchronous. That means the messages do not have to arrive successively. e.g. when a fail notification of an action arrives, it should be handled properly.
+
+### 14. Check if the bounced flag was sent receiving internal messages
+
+You may receive bounced messages (error notifications), which should be handled.
+
+### 15. Write replay protection for external messages:
+
+There are two custom solutions for wallets (smart contracts, storing users money): `seqno-based` (check the counter not to process message twice) and `high-load` (storing processes identifiers and its expirations).
+
+## References
+
+Originally written by 0xguard
+
+- [Original article](https://0xguard.com/things_to_focus_on_while_working_with_ton_blockchain)

docs/develop/smart-contracts/security/things-to-focus.md

@@ -200,6 +200,8 @@ const sidebars = {
               label: 'Security Measures',
               items: [
                 'develop/smart-contracts/security/README',
+                'develop/smart-contracts/security/secure-programming',
+                'develop/smart-contracts/security/things-to-focus',
                 'develop/smart-contracts/security/ton-hack-challenge-1',
                 'develop/smart-contracts/guidelines/random-number-generation',
                 'develop/smart-contracts/security/random',