Timeswap contest - Awesome's results

1. Add whitespace between comment

To increase the readability of comment codes add at least 1 space at the beginning of single-line comments. If you are using multi-line comments add at least 1 space/newline at the beginning and end.

Here are a few examples of lousy comment spacing:

//This is a comment with no whitespace at the beginning

/*This is a comment with no whitespace at the beginning */

/* This is a comment with a whitespace at the beginning but not the end*/

Here are a few examples of good comment spacing:

// This is a comment with a whitespace at the beginning

/* This is a comment with a whitespace at the beginning */

/*
 * This is a comment with a whitespace at the beginning
 */

/*
This comment has a newline
*/

Affected lines:

• BytesLib.sol#L1

• BytesLib.sol#L55-L56

• BytesLib.sol#L59

• BytesLib.sol#L62-L63

• BytesLib.sol#L1

2. Use mixedCase

It is recommended to use the mixedCase naming convention for improving the readability of source code.

This convention involves combining words with no spaces, with the first letter of each word capitalized except for the first word.

For more information, see the Solidity style guide at the following links:

• Naming Convention For Function Names

• Naming Convention For Local and State Variable Names

Affected lines of code:

• BytesLib.sol#L33

3. inadequate NatSpec

Contracts can use the Ethereum Natural Language Specification Format (NatSpec) to provide detailed documentation for functions, return variables, and other elements of the contract. This is done using a special type of comment within the contract code.

You can find more information about NatSpec and its usage in Solidity contracts at the following link NatSpec Format

Affected code:

• FeesPosition.sol

4. Use the delete operator to clear variables, rather than assigning a value of zero.

To clear variables, consider using the delete operator rather than assigning to zero, because this conveys the intention more clearly and is more idiomatic.

As an example on line 685 you can refactor the code like so:

Line 685:    delete pool.long1Balance;

Affected line of code:

• Pool.sol#L685
• FullMath.sol#L166

5. Unspecific Compiler Version Pragma

It is generally not recommended to use floating pragmas (i.e. pragmas that do not specify a specific compiler version) in contracts that are not intended to be used as libraries.

This is because using floating pragmas in application contracts can pose a security risk.

For example, a known vulnerable compiler version may be selected by mistake, or security tools might revert to an older compiler version that produces a different EVM compilation than the one intended to be deployed on the blockchain.

To avoid these potential issues, consider specifying a specific compiler version in your pragmas.

So instead of using a floating pragma like pragma solidity ^0.8.0;, it is better to use a concrete compiler version like pragma solidity 0.8.4;.

More information can be found in the following links:

• Consensys Audit of 1inch
• Solidity docs
• Solidity Specific

Affected line of code:

• TimeswapV2LiquidityToken.sol#L2
• TimeswapV2Token.sol#L2

6. Unused returns

Remove unused returns to improve clarity

Affected line:

• Math.sol#L88-L90

7. Code headers

Consider using this code header for your codebase layout for readability

• https://github.com/transmissions11/headers

/*//////////////////////////////////////////////////////////////
                           EXAMPLE TEXT
//////////////////////////////////////////////////////////////*/

8. Fix typos to improve readability

File: /packages/v2-library/src/FullMath.sol
Line  40:    /// @param addendA0 The least signficant part of addendA.
...
Line 250:    // correct result modulo 2**256. Since the precoditions guarantee

Consider making the following changes to FullMath.sol:

• signficant To significant (Line 40)
• precoditions To preconditions (Line 250)

File: /packages/v2-pool/src/structs/Pool.sol
Line 155:    /// @param to The receipient of the liquidity positions.
...
Line 168:    // Update the fee growth and fees of receipient.
...
Line 178:    /// @param to The receipient of the transaction fees.
Line 179:    /// @param long0Fees The amount of long0 position fees transferrred.
Line 180:    /// @param long1Fees The amount of long1 position fees transferrred.
Line 181:    /// @param shortFees The amount of short position fees transferrred.

Consider making the following changes to Pool.sol:

• receipient To recipient (Line 155, Line 168, Line 178)
• transferrred To transferred (Line 179-181)

File: /packages/v2-pool/src/TimeswapV2Pool.sol
Line 222:    /// @dev Transfer long0 positions, long1 positions, and/or short positions to the receipients.
...
Line 225:    /// @param long0To The receipient of long0 positions.
Line 226:    /// @param long1To The receipient of long1 positions.
Line 227:    /// @param shortTo The receipient of short positions.
...
Line 332:    // Transfer the positions to the receipients.
...
Line 399:    // Transfer short positions to the receipient.
...
Line 446:    // Transfer the positions to the receipients.
...
Line 486:    // Transfer the positions to the receipients.

Consider making the following changes to TimeswapV2Pool.sol:

• receipients To recipients (Line 222, Line 332, Line 446, Line 486)
• receipient To recipient (Line 225-227, Line 399)

File: /packages/v2-pool/src/libraries/ConstantProduct.sol
Line 394:    /// @return sqrtDiscriminant The square root disriminant calculated.

Consider making the following change to ConstantProduct.sol:

• disriminant To discriminant (Line 394)