chore(docs) : Add markdown table to dev cheat sheet (#4077)

* Add markdown table to the dev cheat sheet

docs/content/developer/dev-cheat-sheet.mdx

@@ -6,41 +6,46 @@ import TestingCheatSheet from "../_snippets/testing-cheat-sheet.mdx";
 
 Quick reference on best practices for IOTA Network developers.
 
-## Move
-
-### General
-
-- Read about package upgrades and write upgrade-friendly code:
-  - Packages are immutable, so buggy package code can be called forever. Add protections at the object level instead.
-  - If you upgrade a package `P` to `P'`, other packages and clients that depend on `P` will continue using `P`, not auto-update to `P'`. Both dependent packages and client code must be explicitly updated to point at `P'`.
-  - `public` function signatures cannot be deleted or changed, but `public(package)` and `entry` functions can. Use `public(package)` or private visibility liberally unless you are exposing library functions that will live forever.
-  - It is not possible to delete `struct` types, add new fields (though you can add dynamic fields), or add new [abilities](https://move-language.github.io/move/abilities.html) via an upgrade. Introduce new types carefully—they will live forever!
-- Use `vector`-backed collections (`vector`, `VecSet`, `VecMap`, `PriorityQueue`) with a **known** maximum size of ≤ 1000 items.
-  - Use dynamic field-backed collections (`Table`, `Bag`, `ObjectBag`, `ObjectTable`, `LinkedTable`) for any collection that allows third-party addition, larger collections, and collections of unknown size.
-  - Move objects have a maximum size of 250KB—any attempt to create a larger object leads to an aborted transaction. Ensure that your objects do not have an ever-growing `vector`-backed collection.
-- If your function `f` needs a payment in (e.g.) IOTA from the caller, use `fun f(payment: Coin<IOTA>)` not `fun f(payment: &mut Coin<IOTA>, amount: u64)`. This is safer for callers—they know exactly how much they are paying, and do not need to trust `f` to extract the right amount.
-- Don't micro-optimize gas usage. IOTA computation costs are rounded up to the closest _bucket_, so only very drastic changes will make a difference. In particular, if your transaction is already in the lowest cost bucket, it can't get any cheaper.
-- Follow the [Move coding conventions](https://move-language.github.io/move/coding-conventions.html) for consistent style.
+## Dev Sheet
+
+| **Commands** | **Description** |
+|-|-|
+|`which iota`|to check if iota is already installed or not.|
+|`iota client`|to connect to IOTA network|
+|`iota client envs`|to check environments|
+|`iota client new-env --alias <ALIAS> --rpc <RPC>`|to create new environment.|
+|`iota client switch --env <EnvAlias>`|to switch another environment.|
+|`RUST_LOG="off,iota_node=info" cargo run --bin iota start --force-regenesis --with-faucet`|to start local network.|
+|`iota keytool list`|to list all the address.|
+|`iota move new first_package`|to create new move package.|
+|`pnpm create @iota/dapp --template react-client-dapp`| to setup React app with dApp kit|
+|`cargo install --locked --git https://github.com/iotaledger/iota.git --branch <BRANCH-NAME> --features gas-profiler iota`|To get the latest version of CLI|
+|`iota client active-address`|to get the current address.|
+|`iota client -–help`|to list out all commands of iota client.|
+|`iota client new-address <Scheme> Scheme`|to generate address , **Scheme** - (ed25519,secp256k1,secp256r1)|
 
-### Composability
-
-- Use the `display` standard to customize how your objects show up in wallets, apps, and explorers
-- Avoid “self-transfers”—whenever possible, instead of writing `transfer::transfer(obj, tx_context::sender(ctx))`, return `obj` from the current function. This allows a caller or programmable transaction block to use `obj`.
-
-### Testing
+## Move
 
-<TestingCheatSheet />
+|**Topic**|**Description**|
+|-|-|
+|**General**| <ul><li>  Upgrading a package (`P` to `P'`) doesn't auto-update dependencies; update dependent packages and clients explicitly. </li> <li> Public function signatures can't be deleted/changed; use `public(package)` or `private` visibility unless exposing permanent library functions.  </li> <li> It is not possible to delete `struct` types, add new fields (though you can add dynamic fields), or add new [abilities](https://move-language.github.io/move/abilities.html) via an upgrade. Introduce new types carefully—they will live forever! </li> <li> Use `vector`-backed collections (`vector`, `VecSet`, `VecMap`, `PriorityQueue`) with a **known** maximum size of ≤ 1000 items. </li> <li> Use dynamic field-backed collections (`Table`, `Bag`, `ObjectBag`, `ObjectTable`, `LinkedTable`) for any collection that allows third-party addition, larger collections, and collections of unknown size. </li> <li> Move objects have a maximum size of 250KB—any attempt to create a larger object leads to an aborted transaction. Ensure that your objects do not have an ever-growing `vector`-backed collection. </li> <li> If your function `f` needs a payment in (e.g.) IOTA from the caller, use `fun f(payment: Coin<IOTA>)` not `fun f(payment: &mut Coin<IOTA>, amount: u64)`. This is safer for callers—they know exactly how much they are paying, and do not need to trust `f` to extract the right amount. </li> <li> Don't micro-optimize gas usage. IOTA computation costs are rounded up to the closest _bucket_, so only very drastic changes will make a difference. In particular, if your transaction is already in the lowest cost bucket, it can't get any cheaper. </li> <li> Follow the [Move coding conventions](https://move-language.github.io/move/coding-conventions.html) for consistent style.</li></ul> |
+|**Composability**| <ul><li> Use the `display` standard to customize how your objects show up in wallets, apps, and explorers </li><li> Avoid "self-transfers"—whenever possible, instead of writing `transfer::transfer(obj, tx_context::sender(ctx))`, return `obj` from the current function. This allows a caller or programmable transaction block to use `obj`. </li></ul> |
+|**Testing**| <TestingCheatSheet /> |
 
 ## Apps
 
-- For optimal performance and data consistency, apps should submit writes and reads for the same full node. In the TS SDK, this means that apps should use the wallet's [`signTransactionBlock`](../references/ts-sdk/dapp-kit/index.mdx) API, then submit the transaction via a call to [`execute_transactionBlock`](/iota-api-ref#iota_executetransactionblock) on the app's full node, _not_ use the wallet's `signAndExecuteTransactionBlock` API. This ensures read-after-write-consistency--reads from the app's full node will reflect writes from the transaction right away instead of waiting for a checkpoint.
-- For lower latency, use [`executeTransactionBlock`](/iota-api-ref#iota_executetransactionblock) with `"showEffects": false` and `"showEvents": false` if your app needs to know that a transaction was confirmed, but does not immediately need to see the transaction effects or read the objects/events written by the transaction.
-- Apps should implement a local cache for frequently read data rather than over-fetching from the full node.
-- Whenever possible, use programmable transaction blocks to compose existing on-chain functionality rather than publishing new smart contract code. Programmable transaction blocks allow large-scale batching and heterogeneous composition, driving already-low gas fees down even further.
-- Apps should leave gas budget, gas price, and coin selection to the wallet. This gives wallets more flexibility, and it's the wallet's responsibility to dry run a transaction to ensure it doesn't fail.
+| **Topic** | **Description** |
+|-|-|
+| **Optimal performance** | For optimal performance and data consistency, apps should use the wallet's [`signTransactionBlock`](../references/ts-sdk/dapp-kit/index.mdx) API to sign transactions and then submit them via [`execute_transactionBlock`](/iota-api-ref#iota_executetransactionblock) on the app's full node. This ensures immediate read-after-write consistency, as the app's full node reflects writes instantly, avoiding delays from checkpointing. |
+| **Lower latency** | For lower latency, use [`executeTransactionBlock`](/iota-api-ref#iota_executetransactionblock) with `"showEffects": false` and `"showEvents": false` if your app only needs confirmation of a transaction without immediate access to its effects or events.|
+| **Local cache** | Apps should implement a local cache for frequently read data rather than over-fetching from the full node. |
+| **Transaction cache**| Whenever possible,use programmable transaction blocks to compose on-chain functionality instead of deploying new contracts, enabling batching and lowering gas fees. |
+|**Wallet dependency**| Apps should leave gas budget, gas price, and coin selection to the wallet. This gives wallets more flexibility, and it's the wallet's responsibility to dry run a transaction to ensure it doesn't fail. |
 
 ## Signing
 
-- **Never** sign two concurrent transactions that are touching the same owned object. Either use independent owned objects, or wait for one transaction to conclude before sending the next one. Violating this rule might lead to client [equivocation](/references/iota-glossary.mdx#equivocation), which locks up the owned objects involved in the two transactions until the end of the current epoch.
-- Any `iota client` command that crafts a transaction (e.g., `iota client publish`, `iota client call`) can accept the `--serialize-output` flag to output a base64 transaction to be signed.
-- IOTA supports several signature schemes for transaction signing, including native multisig.
+| **Topic** | **Description** |
+|-|-|
+|**Concurrent Transactions**| Avoid signing concurrent transactions involving the same owned object. Use independent objects or wait for one transaction to finish to prevent client [equivocation](/references/iota-glossary.mdx#equivocation), which can lock the objects until the epoch ends. |
+|**CLI transaction**| Use the `--serialize-output` flag with any iota client command (e.g., `publish`, `call`) to generate a base64 transaction for signing. |
+|**Transaction Signing**| IOTA supports several signature schemes for transaction signing, including native multisig.|