欢迎回到我的Cadence博客!我是Josh!我是Dapper实验室Flow团队的一名智能合约工程师，我每两周发表一次关于我们的编程语言Cadence的简短博客。

如果你是Cadence的新用户，请查看我的介绍性博客，以便开始使用!

‍

使用Cadence迈出第一步

每个Flow的新人都应该完成的资源总结，以适应在Cadence中编写智能合约。

joshuahannan.medium.com

‍

在我开始说我的主要观点之前，我想指出Flow社区成员之一的一篇很棒的博文。Benjamin Ebner。Benjamin解释了Cadence和Flow的一些革命性的功能，以及它们如何很好地适用于智能合约编程。这是一篇很好的阅读，如果你还没有，我强烈建议你去看看

‍

Cadence和Flow将如何革新智能合约编程

通过利用资源的力量，Flow的编程语言--Cadence--给人们带来了令人兴奋的新想法。

媒介网

‍

组织和标准化的价值

正如你们中的许多人所知，保持你的代码清晰和有条理是非常重要的，特别是对于智能合约代码。这包括你命名字段和函数的方式，你如何组织合同或交易中的定义和结构，以及代码的文档化程度。所有这些都是非常重要的，我将在未来的某个时候写一篇博文，分享我的想法和提示，我认为这是组织Cadence代码的最有效的方法。

今天，我将谈论一些更高层次的东西：你如何在你的Github repo中组织你的项目的文件。

如果你正在建立一个项目，你希望其他人会想使用、合作，并希望有一天能扩展或模仿，那么你让你的项目尽可能的可访问性是至关重要的。其中的一部分是你如何组织你的项目库。

建立在以太坊上的项目有Truffle框架，这是一个开发者工具，可以帮助开发者让项目轻松设置、测试和部署。我们在Flow的生命周期中还很早，目前还没有一个很好的自动化解决方案，但我们希望很快就会有！我们有一个很好的团队正在开发Flow CLI，可以解决一些问题。我们有一个伟大的团队正在开发Flow CLI，可以解决其中的一些问题，还有一些社区工作正在进行 ，以简化Flow的开发者体验。

对于开发者社区来说，在开发工作流程的标准上保持一致是很重要的，这样可以使实践标准化，重复和改进，使每个人都受益。

同时，我们必须自己管理它，我想我已经找到了一个相当可靠的方法，我希望其他人也能开始实施它！"。如果你检查过nba top shot,fungible token,nft,kitty items, 或者核心合同库，那么你已经接触过这个了。

结构

我花了一些时间来思考这个问题并进行迭代，我相信像Cadence智能合约交互那样复杂，合约和交易应该在典型的 repo或项目中处于最前面和最中心的位置，而应用程序代码和特定语言包在项目层次结构中要么同等重要，要么不那么重要。合约和交易是项目运作的核心，与每个人选择用什么语言来编写他们的应用程序无关，而且对于开发人员来说，在第一次遇到一个项目时，理解和知道在哪里找到是相当关键的。

这个推理告诉我如何构建Flow智能合约的存储库。

重要的目录是。

contracts/: This should house the main contracts for the project. Easily accessible from the top level.

transactions/: This should house all of the transactions and scripts that interact with the contracts and act as a single source of truth. The contents of this directory can be organized any way the developer wants, but would probably have a directory for each contract, with subdirectories for different types of users of the contract, and scripts, as I did with the staking contract:

I’m not sold on the transactions name, so if there is a better idea for the name, I’m all ears. You could also split scripts into a separate top level directory depending on how you want to organize the project.

lib/: This is where I believe language-specific packages and libraries should live. As you can imagine, developers coming from many different backgrounds will want to learn how to interact with the contracts and repos, and exposing access to the contracts isn’t as simple as publishing an ABI that every language can import like in Solidity. Each language needs a set of packages for generating common transactions and scripts for the contracts.

In a mature contract repo, I would imagine something like this for lib/

Then each language could have a contracts, templates, and test package, or whatever organization makes sense for the specific language or project. These packages would take the templates in contracts/ and transactions/ (source of truth top level directories) and package them for their specific language.
Right now, too many projects are just copying and pasting transactions into their application code, which works fine short term, but if there is ever a breaking change in Cadence or in the contract or transaction code, updating that copied and pasted code will be a huge hassle for projects.

Like any other software projects, contracts should publish releases for their transaction and contract packages in the languages they want to support, then projects that depend on them can simply update their versions.

This is how I have organized my contract repos, but so far I only have packages for Go. In the lib/go/ directory, I have these packages:

• contracts : Contains a package to get the contract code for every contract in the repo, replacing the import addresses with addresses that the caller specifies depending on the network being deployed to.
• templates : Contains a package to get the code for every transaction and script template in the repo, replacing the import addresses with addresses that the caller specifies depending on the network being deployed to.
• test : Contains emulator automated tests for the smart contracts and transactions. This makes use of the packages in the contracts and templates directories for the test, as well as language specific utility methods to make unit testing easier.

I unfortunately haven’t gotten enough help in building packages for languages besides Go, so if anyone is interested in helping, I would appreciate it very much!

We’re planning on creating a testing framework that allows unit testing directly in Cadence, but that still is in very early stages. Once that is ready, I could imagine that another top level directory could contain tests/ that are written in Cadence.

Application Code

Lastly, the application code needs a place. This is where I have the least experience from app development best practices, but I think a project could choose between two options.

• Option 1: Use a different repo for the application: Since an application isn’t directly tied to a smart contract, an argument can be made that it should be in a different repo, and then import the packages from the main contract repo. This encourages the decentralized mindset, allows projects to protect proprietary application code, and de-clutters the main contract repo so that the focus can be on the most important part, the contracts.
• Option 2: Use the same repo, but put the application in one or more top level directories. This would make testing and running the application easier, but could complicate the organization of the repository.

I lean towards option 1, but I might be a little biased because I am primarily a smart contract developer. I acknowledge that I am probably missing some pros and cons for the different options for everything I’ve talked about, so I am definitely open for feedback. Even if my structure is deemed the preferred, it still needs a lot of streamlining to be the best it can be.

Conclusion

I’m excited to hear what everyone thinks! I’d like to start coming to consensus soon so the community can standardizing this. Feel free to leave comments here, or we also have a post in the Flow Forum where you can leave more feedback if you want.

Flow Discord: https://discord.gg/flow

Flow Forum: https://forum.onflow.org

Flow Github: https://github.com/onflow/flow

See you next week! 👋