diff --git a/docs/anti-patterns.md b/docs/anti-patterns.md index 5f32402b..962e9403 100644 --- a/docs/anti-patterns.md +++ b/docs/anti-patterns.md @@ -1,6 +1,6 @@ --- title: Cadence Anti-Patterns -sidebar_position: 6 +sidebar_position: 8 sidebar_label: Anti-Patterns --- diff --git a/docs/cadence-migration-guide/_category_.json b/docs/cadence-migration-guide/_category_.json index 6af9d91c..cb66e293 100644 --- a/docs/cadence-migration-guide/_category_.json +++ b/docs/cadence-migration-guide/_category_.json @@ -1,3 +1,3 @@ { - "position": 5 + "position": 6 } diff --git a/docs/contract-upgrades.md b/docs/contract-upgrades.md index 172f69d4..d743fb09 100644 --- a/docs/contract-upgrades.md +++ b/docs/contract-upgrades.md @@ -1,5 +1,6 @@ --- title: Contract Upgrades with Incompatible Changes +sidebar_position: 11 --- ### Problem diff --git a/docs/design-patterns.md b/docs/design-patterns.md index 46f3107d..05b2b558 100644 --- a/docs/design-patterns.md +++ b/docs/design-patterns.md @@ -1,6 +1,6 @@ --- title: Cadence Design Patterns -sidebar_position: 5 +sidebar_position: 7 sidebar_label: Design Patterns --- diff --git a/docs/json-cadence-spec.md b/docs/json-cadence-spec.md index c56d3a91..c3de50b9 100644 --- a/docs/json-cadence-spec.md +++ b/docs/json-cadence-spec.md @@ -1,6 +1,7 @@ --- title: JSON-Cadence Data Interchange Format -sidebar_label: JSON-Cadence format +sidebar_label: JSON-Cadence Format +sidebar_position: 12 --- > Version 0.3.1 diff --git a/docs/language/_category_.json b/docs/language/_category_.json index 6959092e..6af9d91c 100644 --- a/docs/language/_category_.json +++ b/docs/language/_category_.json @@ -1,3 +1,3 @@ { - "position": 4 + "position": 5 } diff --git a/docs/language/access-control.md b/docs/language/access-control.md index 505b4942..3c3a5fda 100644 --- a/docs/language/access-control.md +++ b/docs/language/access-control.md @@ -1,6 +1,6 @@ --- title: Access control -sidebar_position: 10 +sidebar_position: 11 --- Access control allows making certain parts of a program accessible/visible diff --git a/docs/language/accounts/_category_.json b/docs/language/accounts/_category_.json index 41f320af..be737976 100644 --- a/docs/language/accounts/_category_.json +++ b/docs/language/accounts/_category_.json @@ -1,3 +1,3 @@ { - "position": 16 + "position": 17 } diff --git a/docs/language/attachments.mdx b/docs/language/attachments.mdx index fb7910ff..141244b7 100644 --- a/docs/language/attachments.mdx +++ b/docs/language/attachments.mdx @@ -1,6 +1,6 @@ --- title: Attachments -sidebar_position: 17 +sidebar_position: 18 --- Attachments are a feature of Cadence designed to allow developers to extend a struct or resource type diff --git a/docs/language/built-in-functions.mdx b/docs/language/built-in-functions.mdx index f4b50f0a..b3e82927 100644 --- a/docs/language/built-in-functions.mdx +++ b/docs/language/built-in-functions.mdx @@ -1,6 +1,6 @@ --- title: Built-in Functions -sidebar_position: 23 +sidebar_position: 24 --- ## `panic` diff --git a/docs/language/capabilities.md b/docs/language/capabilities.md index d9565023..43699677 100644 --- a/docs/language/capabilities.md +++ b/docs/language/capabilities.md @@ -1,6 +1,6 @@ --- title: Capabilities -sidebar_position: 11 +sidebar_position: 12 --- Cadence supports [capability-based security](https://en.wikipedia.org/wiki/Capability-based_security) diff --git a/docs/language/contract-updatability.md b/docs/language/contract-updatability.md index 5dc72e0a..06bc429e 100644 --- a/docs/language/contract-updatability.md +++ b/docs/language/contract-updatability.md @@ -1,6 +1,6 @@ --- title: Contract Updatability -sidebar_position: 19 +sidebar_position: 20 --- ## Introduction diff --git a/docs/language/contracts.mdx b/docs/language/contracts.mdx index e4286473..289802c3 100644 --- a/docs/language/contracts.mdx +++ b/docs/language/contracts.mdx @@ -1,6 +1,6 @@ --- title: Contracts -sidebar_position: 18 +sidebar_position: 19 --- A contract is a collection of type definitions, diff --git a/docs/language/control-flow.md b/docs/language/control-flow.md index a60ea347..c82ee118 100644 --- a/docs/language/control-flow.md +++ b/docs/language/control-flow.md @@ -1,6 +1,6 @@ --- title: Control Flow -sidebar_position: 7 +sidebar_position: 8 --- Control flow statements control the flow of execution in a function. diff --git a/docs/language/core-events.md b/docs/language/core-events.md index 053ef66c..03194ac5 100644 --- a/docs/language/core-events.md +++ b/docs/language/core-events.md @@ -1,6 +1,6 @@ --- title: Core Events -sidebar_position: 22 +sidebar_position: 23 --- Core events are events emitted directly from the FVM (Flow Virtual Machine). diff --git a/docs/language/crypto.mdx b/docs/language/crypto.mdx index ac46b39f..e407b7a8 100644 --- a/docs/language/crypto.mdx +++ b/docs/language/crypto.mdx @@ -1,6 +1,6 @@ --- title: Crypto -sidebar_position: 25 +sidebar_position: 26 --- ## Hash algorithms diff --git a/docs/language/enumerations.md b/docs/language/enumerations.md index 72640ac0..fb34b3c4 100644 --- a/docs/language/enumerations.md +++ b/docs/language/enumerations.md @@ -1,6 +1,6 @@ --- title: Enumerations -sidebar_position: 13 +sidebar_position: 14 --- Enumerations are sets of symbolic names bound to unique, constant values, diff --git a/docs/language/environment-information.md b/docs/language/environment-information.md index cebb0112..cef9cd9c 100644 --- a/docs/language/environment-information.md +++ b/docs/language/environment-information.md @@ -1,6 +1,6 @@ --- title: Environment Information -sidebar_position: 24 +sidebar_position: 25 --- ## Transaction Information diff --git a/docs/language/events.md b/docs/language/events.md index 56dc2ac1..6a93839c 100644 --- a/docs/language/events.md +++ b/docs/language/events.md @@ -1,6 +1,6 @@ --- title: Events -sidebar_position: 21 +sidebar_position: 22 --- Events are special values that can be emitted during the execution of a program. diff --git a/docs/language/functions.mdx b/docs/language/functions.mdx index 9643d02d..d9ff11c6 100644 --- a/docs/language/functions.mdx +++ b/docs/language/functions.mdx @@ -405,85 +405,9 @@ fun test(x: Int) { } ``` -## Function Preconditions and Postconditions +## Function pre-conditions and post-conditions -Functions may have preconditions and may have postconditions. -Preconditions and postconditions can be used to restrict the inputs (values for parameters) -and output (return value) of a function. - -Preconditions must be true right before the execution of the function. -Preconditions are part of the function and introduced by the `pre` keyword, -followed by the condition block. - -Postconditions must be true right after the execution of the function. -Postconditions are part of the function and introduced by the `post` keyword, -followed by the condition block. -Postconditions may only occur after preconditions, if any. - -A conditions block consists of one or more conditions. -Conditions are expressions evaluating to a boolean. - -Conditions may be written on separate lines, -or multiple conditions can be written on the same line, -separated by a semicolon. -This syntax follows the syntax for [statements](./syntax.md#semicolons). - -Following each condition, an optional description can be provided after a colon. -The condition description is used as an error message when the condition fails. - -In postconditions, the special constant `result` refers to the result of the function. - -```cadence -fun factorial(_ n: Int): Int { - pre { - // Require the parameter `n` to be greater than or equal to zero. - // - n >= 0: - "factorial is only defined for integers greater than or equal to zero" - } - post { - // Ensure the result will be greater than or equal to 1. - // - result >= 1: - "the result must be greater than or equal to 1" - } - - if n < 1 { - return 1 - } - - return n * factorial(n - 1) -} - -factorial(5) // is `120` - -// Run-time error: The given argument does not satisfy -// the precondition `n >= 0` of the function, the program aborts. -// -factorial(-2) -``` - -In postconditions, the special function `before` can be used -to get the value of an expression just before the function is called. - -```cadence -var n = 0 - -fun incrementN() { - post { - // Require the new value of `n` to be the old value of `n`, plus one. - // - n == before(n) + 1: - "n must be incremented by 1" - } - - n = n + 1 -} -``` - -Both preconditions and postconditions are considered [`view` contexts](#view-functions); -any operations that are not legal in functions with `view` annotations are also not allowed in conditions. -In particular, this means that if you wish to call a function in a condition, that function must be `view`. +See [function pre-condition and post-condition] for more information. ## View Functions @@ -617,3 +541,7 @@ let newIntegers = transform(function: double, integers: [1, 2, 3]) // `newIntegers` is `[2, 4, 6]` ``` + + +[function pre-condition and post-condition]: ./pre-and-post-conditions.md#function-pre-conditions-and-post-conditions + diff --git a/docs/language/glossary.mdx b/docs/language/glossary.mdx index 4440baf4..9342ceac 100644 --- a/docs/language/glossary.mdx +++ b/docs/language/glossary.mdx @@ -1,6 +1,6 @@ --- title: Glossary -sidebar_position: 26 +sidebar_position: 27 --- diff --git a/docs/language/imports.mdx b/docs/language/imports.mdx index cc104a6a..2c27c594 100644 --- a/docs/language/imports.mdx +++ b/docs/language/imports.mdx @@ -1,6 +1,6 @@ --- title: Imports -sidebar_position: 15 +sidebar_position: 16 --- Programs can import declarations (types, functions, variables, etc.) from other programs. diff --git a/docs/language/interfaces.mdx b/docs/language/interfaces.mdx index 620efa95..79cd302f 100644 --- a/docs/language/interfaces.mdx +++ b/docs/language/interfaces.mdx @@ -1,6 +1,6 @@ --- title: Interfaces -sidebar_position: 12 +sidebar_position: 13 --- An interface is an abstract type that specifies the behavior of types @@ -48,113 +48,7 @@ some aspects of them will always hold. ## Interface Declaration -Interfaces are declared using the `struct`, `resource`, or `contract` keyword, -followed by the `interface` keyword, -the name of the interface, -and the requirements, which must be enclosed in opening and closing braces. - -Field requirements can be annotated to -require the implementation to be a variable field, by using the `var` keyword; -require the implementation to be a constant field, by using the `let` keyword; -or the field requirement may specify nothing, -in which case the implementation may either be a variable or a constant field. - -Field requirements and function requirements must specify the required level of access. -The access must be at least be public, so the `access(all)` keyword must be provided. - -Interfaces can be used in types. -This is explained in detail in the section [Interfaces in Types](#interfaces-in-types). -For now, the syntax `{I}` can be read as the type of any value that implements the interface `I`. - -```cadence -// Declare a resource interface for a fungible token. -// Only resources can implement this resource interface. -// -access(all) -resource interface FungibleToken { - - // Require the implementing type to provide a field for the balance - // that is readable in all scopes (`access(all)`). - // - // Neither the `var` keyword, nor the `let` keyword is used, - // so the field may be implemented as either a variable - // or as a constant field. - // - access(all) - balance: Int - - // Require the implementing type to provide an initializer that - // given the initial balance, must initialize the balance field. - // - init(balance: Int) { - pre { - balance >= 0: - "Balances are always non-negative" - } - post { - self.balance == balance: - "the balance must be initialized to the initial balance" - } - - // NOTE: The declaration contains no implementation code. - } - - // Require the implementing type to provide a function that is - // callable in all scopes, which withdraws an amount from - // this fungible token and returns the withdrawn amount as - // a new fungible token. - // - // The given amount must be positive and the function implementation - // must add the amount to the balance. - // - // The function must return a new fungible token. - // The type `{FungibleToken}` is the type of any resource - // that implements the resource interface `FungibleToken`. - // - access(all) - fun withdraw(amount: Int): @{FungibleToken} { - pre { - amount > 0: - "the amount must be positive" - amount <= self.balance: - "insufficient funds: the amount must be smaller or equal to the balance" - } - post { - self.balance == before(self.balance) - amount: - "the amount must be deducted from the balance" - } - - // NOTE: The declaration contains no implementation code. - } - - // Require the implementing type to provide a function that is - // callable in all scopes, which deposits a fungible token - // into this fungible token. - // - // No precondition is required to check the given token's balance - // is positive, as this condition is already ensured by - // the field requirement. - // - // The parameter type `{FungibleToken}` is the type of any resource - // that implements the resource interface `FungibleToken`. - // - access(all) - fun deposit(_ token: @{FungibleToken}) { - post { - self.balance == before(self.balance) + token.balance: - "the amount must be added to the balance" - } - - // NOTE: The declaration contains no implementation code. - } -} -``` - -Note that the required initializer and functions do not have any executable code. - -Struct and resource Interfaces can only be declared directly inside contracts, -i.e. not inside of functions. -Contract interfaces can only be declared globally and not inside contracts. +See [interface declaration] for more information. ## Interface Implementation @@ -1058,3 +952,7 @@ D B A ``` + + + +[interface declaration]: ./pre-and-post-conditions.md#interface-declaration \ No newline at end of file diff --git a/docs/language/pre-and-post-conditions.md b/docs/language/pre-and-post-conditions.md new file mode 100644 index 00000000..058df68c --- /dev/null +++ b/docs/language/pre-and-post-conditions.md @@ -0,0 +1,220 @@ +--- +title: Pre- and Post-Conditions +sidebar_position: 7 +--- + +## Pre-conditions + +Transaction pre-conditions are just like [pre-conditions of functions]. + +Pre-conditions are optional and are declared in a `pre` block. They are executed after the `prepare` phase, and are used for checking if explicit conditions hold before executing the remainder of the transaction. The block can have zero or more conditions. + +For example, a pre-condition might check the balance before transferring tokens between accounts: + +```cadence +pre { + sendingAccount.balance > 0 +} +``` + +If any of the pre-conditions fail, then the remainder of the transaction is not executed and it is completely reverted. + +## Post-conditions + +Transaction post-conditions are just like [post-conditions of functions]. + +Post-conditions are optional and are declared in a `post` block. They are executed after the execution phase, and are used to verify that the transaction logic has been executed properly. The block can have zero or more conditions. + +For example, a token transfer transaction can ensure that the final balance has a certain value: + +```cadence +post { + signer.balance == 30.0: "Balance after transaction is incorrect!" +} +``` + +If any of the post-conditions fail, then the transaction fails and is completely reverted. + +## Using pre-conditions and post-conditions + +Another function of the pre-conditions and post-conditions is to describe the effects of a transaction on the involved accounts. They are essential for users to verify what a transaction does before submitting it. The conditions are an easy way to introspect transactions before they are executed. + +For example, the software that a user uses to sign and send a transaction could analyze and interpret the transaction into a human-readable description, such as "This transaction will transfer 30 tokens from A to B. The balance of A will decrease by 30 tokens and the balance of B will increase by 30 tokens." + +## Function pre-conditions and post-conditions + +Functions may have pre-conditions and may have post-conditions. Pre-conditions and post-conditions can be used to restrict the inputs (values for parameters) and output (return value) of a function. + +Pre-conditions must be true right before the execution of the function. Pre-conditions are part of the function and introduced by the `pre` keyword, followed by the condition block. + +Post-conditions must be true right after the execution of the function. Post-conditions are part of the function and introduced by the `post` keyword, followed by the condition block. Post-conditions may only occur after pre-conditions, if any. + +A conditions block consists of one or more conditions. Conditions are expressions evaluating to a boolean. + +Conditions may be written on separate lines, or multiple conditions can be written on the same line, separated by a semicolon. This syntax follows the syntax for [statements]. + +Following each condition, an optional description can be provided after a colon. The condition description is used as an error message when the condition fails. + +In post-conditions, the special constant `result` refers to the result of the function: + +```cadence +fun factorial(_ n: Int): Int { + pre { + // Require the parameter `n` to be greater than or equal to zero. + // + n >= 0: + "factorial is only defined for integers greater than or equal to zero" + } + post { + // Ensure the result will be greater than or equal to 1. + // + result >= 1: + "the result must be greater than or equal to 1" + } + + if n < 1 { + return 1 + } + + return n * factorial(n - 1) +} + +factorial(5) // is `120` + +// Run-time error: The given argument does not satisfy +// the pre-condition `n >= 0` of the function, the program aborts. +// +factorial(-2) +``` + +In post-conditions, the special function `before` can be used to get the value of an expression just before the function is called: + +```cadence +var n = 0 + +fun incrementN() { + post { + // Require the new value of `n` to be the old value of `n`, plus one. + // + n == before(n) + 1: + "n must be incremented by 1" + } + + n = n + 1 +} +``` + +Both pre-conditions and post-conditions are considered [`view` contexts]; any operations that are not legal in functions with `view` annotations are also not allowed in conditions. In particular, this means that if you wish to call a function in a condition, that function must be `view`. + +## Interface declaration + +Interfaces are declared using the `struct`, `resource`, or `contract` keyword, followed by the `interface` keyword, the name of the interface, and the requirements, which must be enclosed in opening and closing braces. + +Field requirements can be annotated to require the implementation to be a variable field, by using the `var` keyword; to require the implementation to be a constant field, use the `let` keyword; or, the field requirement may specify nothing, in which case the implementation may either be a variable or a constant field. + +Field requirements and function requirements must specify the required level of access. The access must be at least public, so the `access(all)` keyword must be provided. + +Interfaces can be used in types. This is explained in detail in the [Interfaces in types] section. For now, the syntax `{I}` can be read as the type of any value that implements the interface `I`: + +```cadence +// Declare a resource interface for a fungible token. +// Only resources can implement this resource interface. +// +access(all) +resource interface FungibleToken { + + // Require the implementing type to provide a field for the balance + // that is readable in all scopes (`access(all)`). + // + // Neither the `var` keyword, nor the `let` keyword is used, + // so the field may be implemented as either a variable + // or as a constant field. + // + access(all) + balance: Int + + // Require the implementing type to provide an initializer that + // given the initial balance, must initialize the balance field. + // + init(balance: Int) { + pre { + balance >= 0: + "Balances are always non-negative" + } + post { + self.balance == balance: + "the balance must be initialized to the initial balance" + } + + // NOTE: The declaration contains no implementation code. + } + + // Require the implementing type to provide a function that is + // callable in all scopes, which withdraws an amount from + // this fungible token and returns the withdrawn amount as + // a new fungible token. + // + // The given amount must be positive and the function implementation + // must add the amount to the balance. + // + // The function must return a new fungible token. + // The type `{FungibleToken}` is the type of any resource + // that implements the resource interface `FungibleToken`. + // + access(all) + fun withdraw(amount: Int): @{FungibleToken} { + pre { + amount > 0: + "the amount must be positive" + amount <= self.balance: + "insufficient funds: the amount must be smaller or equal to the balance" + } + post { + self.balance == before(self.balance) - amount: + "the amount must be deducted from the balance" + } + + // NOTE: The declaration contains no implementation code. + } + + // Require the implementing type to provide a function that is + // callable in all scopes, which deposits a fungible token + // into this fungible token. + // + // No pre-condition is required to check the given token's balance + // is positive, as this condition is already ensured by + // the field requirement. + // + // The parameter type `{FungibleToken}` is the type of any resource + // that implements the resource interface `FungibleToken`. + // + access(all) + fun deposit(_ token: @{FungibleToken}) { + post { + self.balance == before(self.balance) + token.balance: + "the amount must be added to the balance" + } + + // NOTE: The declaration contains no implementation code. + } +} +``` + +:::info + +The required initializer and functions do not have any executable code. + +::: + +Struct and resource interfaces can only be declared directly inside contracts (i.e., not inside of functions). Contract interfaces can only be declared globally and not inside contracts. + +See [Interfaces] for more information. + + + +[Interfaces]: ./interfaces.mdx +[pre-conditions of functions]: #function-pre-conditions-and-post-conditions +[post-conditions of functions]: #function-pre-conditions-and-post-conditions +[statements]: ./syntax.md#semicolons +[`view` contexts]: ./functions.mdx#view-functions +[Interfaces in types]: ./interfaces.mdx#interfaces-in-types \ No newline at end of file diff --git a/docs/language/references.mdx b/docs/language/references.mdx index ea9aa69b..42c3ab60 100644 --- a/docs/language/references.mdx +++ b/docs/language/references.mdx @@ -1,6 +1,6 @@ --- title: References -sidebar_position: 14 +sidebar_position: 15 --- It is possible to create references to objects, i.e. resources or structures. diff --git a/docs/language/resources.mdx b/docs/language/resources.mdx index 430b1d54..4b2512c9 100644 --- a/docs/language/resources.mdx +++ b/docs/language/resources.mdx @@ -1,7 +1,7 @@ --- title: Resources description: Enables resource-oriented programming on Flow -sidebar_position: 9 +sidebar_position: 10 --- Resources are types that can only exist in **one** location at a time diff --git a/docs/language/scope.md b/docs/language/scope.md index 1efb8eec..ee2371aa 100644 --- a/docs/language/scope.md +++ b/docs/language/scope.md @@ -1,6 +1,6 @@ --- title: Scope -sidebar_position: 8 +sidebar_position: 9 --- Every function and block (`{` ... `}`) introduces a new scope for declarations. diff --git a/docs/language/transactions.md b/docs/language/transactions.md index 9e0d0885..12641382 100644 --- a/docs/language/transactions.md +++ b/docs/language/transactions.md @@ -1,6 +1,6 @@ --- title: Transactions -sidebar_position: 20 +sidebar_position: 21 --- Transactions are objects that are signed with keys of one or more [accounts](./accounts/index.mdx) @@ -124,24 +124,7 @@ as it requires access to the account storage, but perform the deposit in the `ex ### Pre-conditions -Transaction pre-conditions are just like -[pre-conditions of functions](./functions.mdx#function-preconditions-and-postconditions). - -Pre-conditions are optional and are declared in a `pre` block. -They are executed after the `prepare` phase, -and are used for checking if explicit conditions hold before executing the remainder of the transaction. -The block can have zero or more conditions. - -For example, a pre-condition might check the balance before transferring tokens between accounts. - -```cadence -pre { - sendingAccount.balance > 0 -} -``` - -If any of the pre-conditions fail, -then the remainder of the transaction is not executed and it is completely reverted. +See [pre-conditions] for more information. ### Execute phase @@ -168,36 +151,11 @@ transaction { ### Post-conditions -Transaction post-conditions are just like -[post-conditions of functions](./functions.mdx#function-preconditions-and-postconditions). +See [post-conditions] for more information. -Post-conditions are optional and are declared in a `post` block. -They are executed after the execution phase, -and are used to verify that the transaction logic has been executed properly. -The block can have zero or more conditions. +### Using pre-conditions and post-conditions -For example, a token transfer transaction can ensure that the final balance has a certain value: - -```cadence -post { - signer.balance == 30.0: "Balance after transaction is incorrect!" -} -``` - -If any of the post-conditions fail, -then the transaction fails and is completely reverted. - -### Pre-conditions and post-conditions - -Another function of the pre-conditions and post-conditions -is to describe the effects of a transaction on the involved accounts. -They are essential for users to verify what a transaction does before submitting it. -The conditions an easy way to introspect transactions before they are executed. - -For example, the software that a user uses to sign and send a transaction -could analyze and interpret the transaction into a human-readable description, like -"This transaction will transfer 30 tokens from A to B. -The balance of A will decrease by 30 tokens and the balance of B will increase by 30 tokens." +See [using pre-conditons and post-conditions] for more information. ## Summary @@ -244,3 +202,9 @@ transaction { } } ``` + + + +[pre-conditions]: ./pre-and-post-conditions.md#pre-conditions +[post-conditions]: ./pre-and-post-conditions.md#post-conditions +[using pre-conditons and post-conditions]: ./pre-and-post-conditions.md#using-pre-conditions-and-post-conditions diff --git a/docs/measuring-time.mdx b/docs/measuring-time.mdx index fb567b8d..444404d0 100644 --- a/docs/measuring-time.mdx +++ b/docs/measuring-time.mdx @@ -1,6 +1,7 @@ --- title: Measuring Time In Cadence sidebar_label: Measuring Time +sidebar_position: 13 --- ## Accessing Time From Cadence diff --git a/docs/project-development-tips.md b/docs/project-development-tips.md index fbc637a1..2490d41d 100644 --- a/docs/project-development-tips.md +++ b/docs/project-development-tips.md @@ -1,7 +1,7 @@ --- title: Flow Smart Contract Project Development Standards sidebar_label: Development Standards -sidebar_position: 7 +sidebar_position: 9 description: "Learn how to effectively organize and manage a Cadence project" --- diff --git a/docs/security-best-practices.md b/docs/security-best-practices.md index c5ce803d..5854de10 100644 --- a/docs/security-best-practices.md +++ b/docs/security-best-practices.md @@ -1,7 +1,7 @@ --- title: Cadence Security Best Practices sidebar_label: Security Best Practices -sidebar_position: 7 +sidebar_position: 10 --- This is an opinionated list of best practices Cadence developers should follow to write more secure Cadence code. diff --git a/docs/solidity-to-cadence.md b/docs/solidity-to-cadence.md index 42c29788..0f99a6a1 100644 --- a/docs/solidity-to-cadence.md +++ b/docs/solidity-to-cadence.md @@ -1,7 +1,7 @@ --- title: Cadence Guide for Solidity Developers sidebar_label: Cadence Guide for Solidity Developers -sidebar_position: 8 +sidebar_position: 3 --- Cadence introduces a different way to approach smart contract development which may feel unfamiliar to Solidity developers. There are fundamental mindset and platform differences, and also several new language features that have no diff --git a/docs/testing-framework.mdx b/docs/testing-framework.mdx index 1e43bd91..0aad57f2 100644 --- a/docs/testing-framework.mdx +++ b/docs/testing-framework.mdx @@ -1,6 +1,7 @@ --- title: Cadence Testing Framework sidebar_label: Testing +sidebar_position: 14 --- The Cadence testing framework provides a convenient way to write tests for Cadence programs in Cadence. diff --git a/docs/tutorial/_category_.json b/docs/tutorial/_category_.json index 42d32d19..66eabb91 100644 --- a/docs/tutorial/_category_.json +++ b/docs/tutorial/_category_.json @@ -1,4 +1,4 @@ { - "position": 3, + "position": 4, "label": "Tutorial" }