Modified introduction-to-smart-contracts.rst

Corrected inline code syntax

1 files changed, 25 insertions, 25 deletions

diff --git a/docs/introduction-to-smart-contracts.rst b/docs/introduction-to-smart-contracts.rst
index 7743c53d..d9d1b6cd 100644
--- a/docs/introduction-to-smart-contracts.rst
+++ b/docs/introduction-to-smart-contracts.rst
@@ -32,20 +32,20 @@ Storage
 
 A contract in the sense of Solidity is a collection of code (its functions) and
 data (its *state*) that resides at a specific address on the Ethereum
-blockchain. The line `uint storedData;` declares a state variable called `storedData` of
-type `uint` (unsigned integer of 256 bits). You can think of it as a single slot
+blockchain. The line :code:`uint storedData;` declares a state variable called :code:`storedData` of
+type :code:`uint` (unsigned integer of 256 bits). You can think of it as a single slot
 in a database that can be queried and altered by calling functions of the
 code that manages the database. In the case of Ethereum, this is always the owning
-contract. And in this case, the functions `set` and `get` can be used to modify
+contract. And in this case, the functions :code:`set` and :code:`get` can be used to modify
 or retrieve the value of the variable.
 
-To access a state variable, you do not need the prefix `this.` as is common in
+To access a state variable, you do not need the prefix :code:`this.` as is common in
 other languages.
 
 This contract does not yet do much apart from (due to the infrastructure
 built by Ethereum) allowing anyone to store a single number that is accessible by
 anyone in the world without (feasible) a way to prevent you from publishing
-this number. Of course, anyone could just call `set` again with a different value
+this number. Of course, anyone could just call :code:`set` again with a different value
 and overwrite your number, but the number will still be stored in the history
 of the blockchain. Later, we will see how you can impose access restrictions
 so that only you can alter the number.
@@ -98,11 +98,11 @@ registering with username and password - all you need is an Ethereum keypair.
 
 This contract introduces some new concepts, let us go through them one by one.
 
-The line `address public minter;` declares a state variable of type address
-that is publicly accessible. The `address` type is a 160 bit value
+The line :code:`address public minter;` declares a state variable of type address
+that is publicly accessible. The :code:`address` type is a 160 bit value
 that does not allow any arithmetic operations. It is suitable for
 storing addresses of contracts or keypairs belonging to external
-persons. The keyword `public` automatically generates a function that
+persons. The keyword :code:`public` automatically generates a function that
 allows you to access the current value of the state variable.
 Without this keyword, other contracts have no way to access the variable
 and only the code of this contract can write to it.
@@ -117,7 +117,7 @@ get the idea - the compiler figures that out for you.
 
 .. index:: mapping
 
-The next line, `mapping (address => uint) public balances;` also
+The next line, :code:`mapping (address => uint) public balances;` also
 creates a public state variable, but it is a more complex datatype.
 The type maps addresses to unsigned integers.
 Mappings can be seen as hashtables which are
@@ -127,7 +127,7 @@ too far, though, as it is neither possible to obtain a list of all keys of
 a mapping, nor a list of all values. So either keep in mind (or
 better, keep a list or use a more advanced data type) what you
 added to the mapping or use it in a context where this is not needed,
-like this one. The accessor function created by the `public` keyword
+like this one. The accessor function created by the :code:`public` keyword
 is a bit more complex in this case. It roughly looks like the
 following::
 
@@ -140,12 +140,12 @@ single account.
 
 .. index:: event
 
-The line `event Sent(address from, address to, uint value);` declares
+The line :code:`event Sent(address from, address to, uint value);` declares
 a so-called "event" which is fired in the last line of the function
-`send`. User interfaces (as well as server appliances of course) can
+:code:`send`. User interfaces (as well as server appliances of course) can
 listen for those events being fired on the blockchain without much
 cost. As soon as it is fired, the listener will also receive the
-arguments `from`, `to` and `value`, which makes it easy to track
+arguments :code:`from`, :code:`to` and :code:`value`, which makes it easy to track
 transactions. In order to listen for this event, you would use ::
 
     Coin.Sent().watch({}, '', function(error, result) {
@@ -159,22 +159,22 @@ transactions. In order to listen for this event, you would use ::
         }
     }
 
-Note how the automatically generated function `balances` is called from
+Note how the automatically generated function :code:`balances` is called from
 the user interface.
 
 .. index:: coin
 
-The special function `Coin` is the
+The special function :code:`Coin` is the
 constructor which is run during creation of the contract and
 cannot be called afterwards. It permanently stores the address of the person creating the
-contract: `msg` (together with `tx` and `block`) is a magic global variable that
-contains some properties which allow access to the blockchain. `msg.sender` is
+contract: :code:`msg` (together with :code:`tx` and :code:`block`) is a magic global variable that
+contains some properties which allow access to the blockchain. :code:`msg.sender` is
 always the address where the current (external) function call came from.
 
 Finally, the functions that will actually end up with the contract and can be called
-by users and contracts alike are `mint` and `send`.
-If `mint` is called by anyone except the account that created the contract,
-nothing will happen. On the other hand, `send` can be used by anyone (who already
+by users and contracts alike are :code:`mint` and :code:`send`.
+If :code:`mint` is called by anyone except the account that created the contract,
+nothing will happen. On the other hand, :code:`send` can be used by anyone (who already
 has some of these coins) to send coins to anyone else. Note that if you use
 this contract to send coins to an address, you will not see anything when you
 look at that address on a blockchain explorer, because the fact that you sent
@@ -301,7 +301,7 @@ If the target account contains code, that code is executed and
 the payload is provided as input data.
 
 If the target account is the zero-account (the account with the
-address `0`), the transaction creates a **new contract**.
+address :code:`0`), the transaction creates a **new contract**.
 As already mentioned, the address of that contract is not
 the zero address but an address derived from the sender and
 its number of transaction sent (the "nonce"). The payload
@@ -323,7 +323,7 @@ the transaction and to pay for this execution. While the EVM executes the
 transaction, the gas is gradually depleted according to specific rules.
 
 The **gas price** is a value set by the creator of the transaction, who
-has to pay `gas_price * gas` up front from the sending account.
+has to pay :code:`gas_price * gas` up front from the sending account.
 If some gas is left after the execution, it is refunded in the same way.
 
 If the gas is used up at any point (i.e. it is negative),
@@ -410,7 +410,7 @@ Delegatecall / Callcode and Libraries
 There exists a special variant of a message call, named **delegatecall**
 which is identical to a message call apart from the fact that
 the code at the target address is executed in the context of the calling
-contract and `msg.sender` and `msg.value` do not change their values.
+contract and :code:`msg.sender` and :code:`msg.value` do not change their values.
 
 This means that a contract can dynamically load code from a different
 address at runtime. Storage, current address and balance still
@@ -452,9 +452,9 @@ Selfdestruct
 ============
 
 The only possibility that code is removed from the blockchain is
-when a contract at that address performs the `SELFDESTRUCT` operation.
+when a contract at that address performs the :code:`SELFDESTRUCT` operation.
 The remaining Ether stored at that address is sent to a designated
 target and then the storage and code is removed.
 
-Note that even if a contract's code does not contain the `SELFDESTRUCT`
+Note that even if a contract's code does not contain the :code:`SELFDESTRUCT`
 opcode, it can still perform that operation using delegatecall or callcode.