Modifier ordering plays a significant role in modifier efficacy
The `nonReentrant` and `refundFinalBalance` modifiers always appear together across the 0x monorepo. When used, they invariably appear with `nonReentrant` listed first, followed by `refundFinalBalance`. This specific order appears inconsequential at first glance but is actually important. The order of execution is as follows:\\nThe `nonReentrant` modifier runs (_lockMutexOrThrowIfAlreadyLocked).\\nIf `refundFinalBalance` had a prefix, it would run now.\\nThe function itself runs.\\nThe `refundFinalBalance` modifier runs (_refundNonZeroBalanceIfEnabled).\\nThe `nonReentrant` modifier runs (_unlockMutex).\\nThe fact that the `refundFinalBalance` modifier runs before the mutex is unlocked is of particular importance because it potentially invokes an external call, which may reenter. If the order of the two modifiers were flipped, the mutex would unlock before the external call, defeating the purpose of the reentrancy guard.\\n```\\nnonReentrant\\nrefundFinalBalance\\n```\\n
Resolution\\nThis is fixed in 0xProject/0x-monorepo#2228 by introducing a new modifier that combines the two: `refundFinalBalance`.\\nAlthough the order of the modifiers is correct as-is, this pattern introduces cognitive overhead when making or reviewing changes to the 0x codebase. Because the two modifiers always appear together, it may make sense to combine the two into a single modifier where the order of operations is explicit.
```\\nnonReentrant\\nrefundFinalBalance\\n```\\n