diff options
author | chriseth <chris@ethereum.org> | 2016-08-12 21:20:02 +0800 |
---|---|---|
committer | GitHub <noreply@github.com> | 2016-08-12 21:20:02 +0800 |
commit | c389f894b569dda3841cb0d076e28b8fa5725bf7 (patch) | |
tree | ea58f8e27ab9685e93ba910d52a3cee48ca82544 /docs | |
parent | 04db7b0e525431b4f51f4a13506e85b47451ba7b (diff) | |
parent | 1634a79bd8ecfe2445bef7a9af26887aa638c15e (diff) | |
download | dexon-solidity-c389f894b569dda3841cb0d076e28b8fa5725bf7.tar dexon-solidity-c389f894b569dda3841cb0d076e28b8fa5725bf7.tar.gz dexon-solidity-c389f894b569dda3841cb0d076e28b8fa5725bf7.tar.bz2 dexon-solidity-c389f894b569dda3841cb0d076e28b8fa5725bf7.tar.lz dexon-solidity-c389f894b569dda3841cb0d076e28b8fa5725bf7.tar.xz dexon-solidity-c389f894b569dda3841cb0d076e28b8fa5725bf7.tar.zst dexon-solidity-c389f894b569dda3841cb0d076e28b8fa5725bf7.zip |
Merge pull request #858 from Denton-L/quotes-docs
Document existence of single-quotes
Diffstat (limited to 'docs')
-rw-r--r-- | docs/control-structures.rst | 2 | ||||
-rw-r--r-- | docs/frequently-asked-questions.rst | 10 | ||||
-rw-r--r-- | docs/style-guide.rst | 14 | ||||
-rw-r--r-- | docs/types.rst | 10 |
4 files changed, 24 insertions, 12 deletions
diff --git a/docs/control-structures.rst b/docs/control-structures.rst index 2f131c55..e03d8d6a 100644 --- a/docs/control-structures.rst +++ b/docs/control-structures.rst @@ -337,7 +337,7 @@ Inline assembly parses comments, literals and identifiers exactly as Solidity, s usual ``//`` and ``/* */`` comments. Inline assembly is initiated by ``assembly { ... }`` and inside these curly braces, the following can be used (see the later sections for more details) - - literals, i.e. ``0x123``, ``42`` or ``"abc"`` (strings up to 32 characters) + - literals, e.g. ``0x123``, ``42`` or ``"abc"`` (strings up to 32 characters) - opcodes (in "instruction style"), e.g. ``mload sload dup1 sstore``, for a list see below - opcodes in functional style, e.g. ``add(1, mlod(0))`` - labels, e.g. ``name:`` diff --git a/docs/frequently-asked-questions.rst b/docs/frequently-asked-questions.rst index b3667a11..c28b4ab7 100644 --- a/docs/frequently-asked-questions.rst +++ b/docs/frequently-asked-questions.rst @@ -399,7 +399,7 @@ What character set does Solidity use? ===================================== Solidity is character set agnostic concerning strings in the source code, although -utf-8 is recommended. Identifiers (variables, functions, ...) can only use +UTF-8 is recommended. Identifiers (variables, functions, ...) can only use ASCII. What are some examples of basic string manipulation (``substring``, ``indexOf``, ``charAt``, etc)? @@ -741,15 +741,15 @@ see a 32-byte hex value, this is just ``"stringliteral"`` in hex. The type ``bytes`` is similar, only that it can change its length. Finally, ``string`` is basically identical to ``bytes`` only that it is assumed -to hold the utf-8 encoding of a real string. Since ``string`` stores the -data in utf-8 encoding it is quite expensive to compute the number of +to hold the UTF-8 encoding of a real string. Since ``string`` stores the +data in UTF-8 encoding it is quite expensive to compute the number of characters in the string (the encoding of some characters takes more than a single byte). Because of that, ``string s; s.length`` is not yet supported and not even index access ``s[2]``. But if you want to access the low-level byte encoding of the string, you can use ``bytes(s).length`` and ``bytes(s)[2]`` which will result in the number -of bytes in the utf-8 encoding of the string (not the number of -characters) and the second byte (not character) of the utf-8 encoded +of bytes in the UTF-8 encoding of the string (not the number of +characters) and the second byte (not character) of the UTF-8 encoded string, respectively. diff --git a/docs/style-guide.rst b/docs/style-guide.rst index c509a9d4..c7b13efa 100644 --- a/docs/style-guide.rst +++ b/docs/style-guide.rst @@ -118,7 +118,7 @@ Source File Encoding UTF-8 or ASCII encoding is preferred. Imports -========== +======= Import statements should always be placed at the top of the file. @@ -519,6 +519,18 @@ No:: Other Recommendations ===================== +* Strings should be quoted with double-quotes instead of single-quotes. + +Yes:: + + str = "foo"; + str = "Hamlet says, 'To be or not to be...'"; + +No:: + + str = 'bar'; + str = '"Be yourself; everyone else is already taken." -Oscar Wilde'; + * Surround operators with a single space on either side. Yes:: diff --git a/docs/types.rst b/docs/types.rst index 0c5aaf1b..12a35aaf 100644 --- a/docs/types.rst +++ b/docs/types.rst @@ -147,10 +147,10 @@ Dynamically-sized byte array ``bytes``: Dynamically-sized byte array, see :ref:`arrays`. Not a value-type! ``string``: - Dynamically-sized UTF8-encoded string, see :ref:`arrays`. Not a value-type! + Dynamically-sized UTF-8-encoded string, see :ref:`arrays`. Not a value-type! As a rule of thumb, use ``bytes`` for arbitrary-length raw byte data and ``string`` -for arbitrary-length string (utf-8) data. If you can limit the length to a certain +for arbitrary-length string (UTF-8) data. If you can limit the length to a certain number of bytes, always use one of ``bytes1`` to ``bytes32`` because they are much cheaper. .. index:: ! ufixed, ! fixed, ! fixed point number @@ -214,9 +214,9 @@ a non-rational number). String Literals --------------- -String Literals are written with double quotes (``"abc"``). As with integer literals, their type can vary, but they are implicitly convertible to ``bytes1``, ..., ``bytes32`` if they fit, to ``bytes`` and to ``string``. +String literals are written with either double or single-quotes (``"foo"`` or ``'bar'``). As with integer literals, their type can vary, but they are implicitly convertible to ``bytes1``, ..., ``bytes32``, if they fit, to ``bytes`` and to ``string``. -String Literals support escape characters, such as ``\n``, ``\xNN`` and ``\uNNNN``. ``\xNN`` takes a hex value and inserts the appropriate byte, while ``\uNNNN`` takes a Unicode codepoint and inserts an UTF8 sequence. +String literals support escape characters, such as ``\n``, ``\xNN`` and ``\uNNNN``. ``\xNN`` takes a hex value and inserts the appropriate byte, while ``\uNNNN`` takes a Unicode codepoint and inserts an UTF-8 sequence. .. index:: enum @@ -353,7 +353,7 @@ So ``bytes`` should always be preferred over ``byte[]`` because it is cheaper. .. note:: If you want to access the byte-representation of a string ``s``, use ``bytes(s).length`` / ``bytes(s)[7] = 'x';``. Keep in mind - that you are accessing the low-level bytes of the utf-8 representation, + that you are accessing the low-level bytes of the UTF-8 representation, and not the individual characters! .. index:: ! array;allocating, new |