2

My team is currently working on a single smart contract that contains multiple functions that share state. We are using Git, and are constantly facing merge conflicts. The best way to reduce conflicts is to split work across multiple files.

Is it possible to split Solidity contracts into multiple "parts" that compose functionality into the same contract? (possibly one function group per file)

2
  • 1
    There's a pretty good chance that the best way to deal with it architectural-wise is to split the functionality across multiple contracts. The work itself will subsequently be split as well, though it is not the primary goal here. If you found yourself with having to split functionalities between different teams, then these functionalities most likely are more suitable to be implemented in different contracts. Build your system from small building blocks - it will help you in debugging, testing and coverage (and if you do it wisely, it will not impact the gas cost dramatically). Nov 28 '18 at 12:31
  • It’s not a duplicate, as we want the end result to be a single contract, not multiple. Nov 28 '18 at 20:53
3

Consider using inheritance, creating contracts inside others using new Contract() or libraries with just internal functions (when library functions are internal there is no need to deploy the library separately and link to it).

Note that although you may create many contracts using the methods above, the compilation process combines the code in all of the contracts and only outputs one contract.

Splitting up code into individual contracts/libraries is useful for adding context to individual pieces of functionality making them easier to understand. It also enables reuse of code and can reduce merge conflicts.

1

No, you cannot split the same contract in multiple files, there is no way to do so at compile time.

The inclusion or inheritance simply move the moment in which the code will be composed and then compiled.

The libraries could permit you to compile in a different moment and then link, but they are not useful for general purposes.

That is not the way.

Encapsulated global area and infinite small contracts accessing it via methods of the so defined object is the way.

By the way, that is Xbdao (our current development) architecture, and it works very well.

May be some re-design can help.

Not the answer you're looking for? Browse other questions tagged or ask your own question.