Solidity Imports: Organizing Code Efficiently

Solidity developers should always use named imports to efficiently manage contracts and avoid unnecessary complications.

### Efficient Solidity Development: Mastering Imports and Version Control
* 📚 "Just by learning this, you are already **better than 80% of the current Solidity developers**, so congratulations."
* 🔄 We learned how to **import our simple storage** from simplestorage.sol using an advanced method, while **managing different Solidity versions effectively**.
* ⚙ If the Solidity version of storage Factory is changed to **0.7.6**, it will cause a **compilation error** when trying to compile with simple storage, highlighting the **importance of version compatibility**.
* 🗂 To maintain a clean codebase, we can utilize the **import keyword** to bring in **only the necessary contracts**, avoiding **redundancy and clutter**.
* 📜 Instead of importing entire files, we can specify exact contracts to import, such as using **"import simple storage from simplestorage.sol,"** which is **more efficient**.
* 🔍 Named imports are recommended over generic imports as they help **avoid unnecessary computations** and **potential compatibility issues** in the future.
* 🚀 By organizing our contracts this way, we **enhance our workflow and reduce deployment costs**, making our development process **smoother and more manageable**.
* 🏗 As we advance in Solidity, understanding these **import strategies and version control** will be crucial for **successful contract management and deployment**.

but the thing is, like I was saying, if we just add all of our contracts into the same file, and we have these massive contracts all interweaved between each other, and get very cluttered and very confusing, so is there a better way we can actually arrange and organize our code other than this? And this is actually even a little bit redundant since we already have our simplestorage.sol. If I change something in here, then I would also have to go and change it in here, and that's too much work for me as an engineer. I will work incredibly hard to be incredibly lazy. So instead of doing this, we can use what's called an import. If we go ahead and delete our contract simple storage in our storage Factory here, so that now we just have the storage Factory contract, we can go ahead and use the import keyword to import simple storage.sol. So we can do Imports dot slash simplestorage.sol and a little semicolon here. This import dot slash simplestorage.sol is the exact same as if we had this giant simple storage in

here. So, this import simple storage.sol is a shorthand version of copy-pasting that simple storage.sol into this contract. And now we're able to have simple storage.sol in its own file, and storage Factory just imports it from simple storage, making our lives much easier. It takes our path package or GitHub, which we'll explain in a little bit, and imports and copy-pastes whatever in that file at the top of our file. Literally, Solidity for us is copy-pasting everything in here and sticking it up here so we can go ahead and run this again. Let's compile the old contract. We're on Remix VM. Let's be sure we're on storage Factory. We'll go to storage Factory. We'll deploy it. Scroll down. Click here. Simple storage starts up as nothing. Create simple storage. Oh my God, this look. We deployed a contract. Huzzah! Great work. So now that we're starting to work with different files, there's a number of things we want to consider. The first one is actually the Solidity version. So right now, we're using 0.8.8.

with no carrot and in storage Factor, we're using 0.8.8 with a carrot. If I were to, for example, move the solidity version of this down to 0.8.16 and go to compile this with a different version, remix is actually gonna automatically bump this up to 0.8.19 or actually remix is actually going to automatically bump this up to 0.8.18 if I'm on the simple storage because 0.8.18 is the version that works for simple storage and it still is compatible with storage Factory. However, if I were to take storage Factory and move it to 0.7.6 and try to compile, it's going to try to compile this with 0.7.6 and our simple storage with 0.7.6 and a stock will be able to do it for both, and so we're going to get a compilation error. So, when working with multiple files, it's important to keep the version of solidity in mind because

you want to make sure that all of your contracts can actually compile together. So, this is great and all, but right from the get-go, I want to teach you the more advanced import that you should always use. So, this is good, but we actually never want to default to this. We want to default to something called named Imports. Let's say our simplestorage.soul contract had a ton of other contracts like contract simple storage 2, simple storage 3, simple storage 4, and these were all massive, massive contracts. As we have this right now, import simplestorage.soul would import everything from here: simple storage, simple storage 2, simple storage 3, simple storage 4. And if these files were incredibly big, when we deploy our storage Factory, it would have to calculate all this extra computation, making the deployment of our storage Factory more expensive. If that's confusing to you, don't worry about it right now. Additionally, in the future, these can import from weird places that aren't compatible with storage Factory. Again, that's not going to make sense quite yet, and that's okay, but in any

case there's a way for us to not import this whole file but only a very specific contract or a specific section of our simplestorage.soul. So, instead, what we can do is in our import statement, we can specify the exact contract that we want to import from this file. So, in our simplestorage.sol, let's say we do have these other contracts in here. We could say we only want to import simple storage, not simple storage 2, not simple storage 3, not simple storage 4, by saying import these little brackets here, simple storage from simplestorage.soul. And this goes ahead and compiles correctly. We can also import multiple contracts from our simple storage. For example, we could do import simple storage, simple storage 2 from simplestorage.soul. This way, we only import the exact specific contracts that we want from these other files. And I promise you, in the future, always referring to named imports instead of this type of imports will save you a lot of headache in the future. So, always default to this, never default to this.

Just by learning this, you are already better than 80% of the current Solidity developers, so congratulations. But all right, fantastic. So, we've learned about imports. We're able to import our simple storage from simplestorage.soul. We're importing it in the more advanced way. Congratulations.

Lesson 3 Part 4 | Imports - Solidity & Foundry Full Course

Book a smart contract audit here 👇
https://www.cyfrin.io/


Cyfrin Audits

Using a single file for multiple contracts can lead to confusion and redundancy.

Instead, the import keyword can be used to bring in contracts from other files, reducing clutter.

Named imports allow for importing specific contracts, making the code more organized and manageable.

Importing and Using Simple Storage in Solidity

The contract is using a shorthand import for simple storage, allowing it to be in its own file.

This import process copies the content of simple storage into the contract, making it easier to manage.

The contract is deployed successfully, and the Solidity version being used is 0.

The Importance of Named Imports in Contract Compilation

Using named imports is crucial for managing contracts with multiple dependencies.

Importing everything from a large contract can lead to increased computational costs during deployment.

Named imports help avoid potential compatibility issues and make the deployment of related contracts more efficient.

Managing Solidity Versions in Multiple Files

Importing contracts in Solidity requires careful version management.

Remix automatically adjusts the Solidity version to maintain compatibility between imported files.

Mismatched versions can lead to compilation errors, so it's crucial to keep them aligned when working with multiple files.