Contracts should be deployed with the same compiler version and flags that they have been tested the most with. Locking the pragma helps ensure that contracts do not accidentally get deployed using, for example, the latest compiler which may have higher risks of undiscovered bugs. Contracts may also be deployed by others and the pragma indicates the compiler version intended by the original authors.

for more info reach out this below---
Lock pragmas to specific compiler version

Fallback functions are executed whenever a particular contract receives plain Ether without any other data associated with the transaction.
The truth about fallback functions in Solidity
solidity Documentation

Consider preventing the transfer of tokens to the same address of the smart contract.

validating that the "to" address is neither 0x0 nor the smart contract's own address:

modifier validDestination( address to ) {
    require(to != address(0x0));
    require(to != address(this) );
    _;
}

The modifier should then be applied to the "transfer" and "transferFrom" methods:

If it can’t overflow without uint256(-1) calls, you don’t need to check for overflow

Save gas and avoid safemath with unchecked {} , this one is Solidity only but I wanted to include it, I was tired of seeing counters using Safemath, it is cost-prohibitive enough to call a contract billions of times to prevent an attack.

for more info reach out.

write NftMarket_test.js inside test using chai framework for NftMarket.sol and test using harhat

Resources-ERC721, Hardhat _testing

comment working of function in test_file

Adding pause functionality to secure Solidity smart contracts

Pause capability is one way to protect functions that will be available to all users (e.g., public or external functions). A pause modifier or condition can temporarily remove a function’s ability to work, without impacting other contract functions and without opting to destroy the entire contract and start from scratch.

for adding a pausable function in smart contract use openzapplien, read carefully

for more information read this article

go to solidity documentation and openzeppelin erc721 and add comment in smart_contract file.

update function hash for each function in smart contract and rearrange based on hash

deploy smart contract on local blockchain network Ganache

    $ npm install -g ganache-cli
    $ truffle migrate --reset

found error -Error: Could not find artifacts for 2_initial_migration from any sources

Constant variables are replaced at compile time by their values, while immutable variables are replaced at deployment time. Either way, we avoid the annoying fees required with doing an SLOAD operation.
They are replaced with literals at compile time and will prevent you from having to a read a value from memory or storage. For writing Yul - replace all known values and constant values with literals to save gas and comment what they are.

for more info reach out
more info

When writing a for loop instead of writing uint256 index = 0; instead write uint256 index; as being a uin256 it will be 0 by default so you can save some gas by avoiding initialization.

for more info reach out

Optimizing smart contracts may reduce gas consumption and therefore the associated cost of executing transactions. It also has the potential to mitigate against malicious exploitation of smart contracts.

reference - Gas and Fee , Ethereum yellow paper

Use remix ide for estimate gas price of function

How to estimate gas prices of a function in Remix IDE

Update MyNft_test.js using chai framework for MyNft.sol for ERC721 token

Resources-ERC721, Hardhat _testing

comment working of function in file

Smart contracts in Ethereum are immutable by default. Once you create them there is no way to alter them, effectively acting as an unbreakable contract among participants.

However, for some scenarios, it is desirable to be able to modify them. Think of a traditional contract between two parties: if they both agreed to change it, they would be able to do so. On Ethereum, they may desire to alter a smart contract to fix a bug they found (which might even lead to a hacker stealing their funds!), to add additional features, or simply to change the rules enforced by it.

Here’s what you’d need to do to fix a bug in a contract you cannot upgrade:

1. Deploy a new version of the contract
2. Manually migrate all state from the old one contract to the new one (which can be very expensive in terms of gas fees!)
3. Update all contracts that interacted with the old contract to use the address of the new one
4. Reach out to all your users and convince them to start using the new deployment (and handle both contracts being used simultaneously, as users are slow to migrate)

To avoid going through this mess, we have built contract upgrades directly into our plugins. This allows us to change the contract code, while preserving the state, balance, and address.

for more information about upgradable smart contract reach out this

openzeppelin-contracts-upgradeable

Save Gas on Contract Deployments using Minimal Proxies

Minimal proxies are used to deploy low-gas-cost versions of a contract that otherwise would need to be deployed entirely, many times. So pretty much... clones! The flow is like this:

1. Create a base implementation contract that contains all your desired logic and functions
2. Instead of having to re-deploy the entire contract every time, an end-user can deploy a "clone" version of it that is much cheaper in gas

for more information about how to use minimal proxies