Lines Matching refs:code
14 particularly important for large-scale code bases that follow a library-based
23 **If you are extending, enhancing, or bug fixing already implemented code,
27 Note that some code bases (e.g. ``libc++``) have special reasons to deviate
31 There are some conventions that are not uniformly followed in the code base
33 lot of code was written before they were put in place. Our long term goal is
35 want patches that do large-scale reformatting of existing code. On the other
38 make code review easier.
46 Most source code in LLVM and other LLVM projects using these coding standards
47 is C++ code. There are some places where C code is used either due to
49 code imported into the tree. Generally, our preference is for standards
50 conforming, modern, and portable C++ code as the implementation language of
57 code and avoid unnecessary vendor-specific extensions.
99 Guidelines for Go code
102 Any code written in the Go programming language is not subject to the
106 Go code should strive to be idiomatic. Two good sets of guidelines for what
129 Aim to describe what the code is trying to do and why, not *how* it does it at
140 .. code-block:: c++
168 code can be distributed under and should not be modified in any way.
201 the code itself.
213 #. When writing C code to be compatible with C89.
225 .. code-block:: c++
231 .. code-block:: c++
235 Commenting out large blocks of code is discouraged, but if you really have to do
257 Wrap non-inline code examples in ``\code ... \endcode``.
269 .. code-block:: c++
276 .. code-block:: c++
283 /// \code
307 .. code-block:: c++
321 .. code-block:: c++
346 .. code-block:: none
353 .. code-block:: none
413 Write your code to fit within 80 columns.
415 There must be some limit to the width of the code in
420 and would be detrimental to printing out code. Also many other projects have
430 tabs out to different tab stops. This can cause your code to look completely
433 As always, follow the `Golden Rule`_ above: follow the style of existing code
443 When formatting a multi-line lambda, format it like a block of code. If there
446 indent for a block of code, as if it were an if-block opened by the preceding
449 .. code-block:: c++
467 .. code-block:: c++
494 function arguments, and lambdas. We suggest new code use a simple rule for
499 .. code-block:: c++
519 Compiler warnings are often useful and help improve the code. Those that are
520 not useful, can be often suppressed with a small code change. For example, an
523 .. code-block:: c++
529 Several compilers will print a warning for the code above. It can be suppressed
532 .. code-block:: c++
541 In almost all cases, it is possible to write completely portable code. When
542 you need to rely on non-portable code, put it behind a well-defined and
548 In an effort to reduce code and executable size, LLVM does not use exceptions
564 constructor or destructor) should not be added to the code base, and should be
568 <https://yosefk.com/c++fqa/ctors.html#fqa-10.12>`, making the code more
587 .. code-block:: c++
599 .. code-block:: c++
630 .. code-block:: c++
651 .. code-block:: c++
659 uses a more moderate stance. Use ``auto`` if and only if it makes the code more
679 .. code-block:: c++
698 result in non-deterministic code generation. While the generated code
821 .. code-block:: c++
836 declaration from the header. For example, the following C++ code defines a new
840 .. code-block:: c++
862 When reading code, keep in mind how much state and how many previous decisions
863 have to be remembered by the reader to understand a block of code. Aim to
865 understand the code. One great way to do this is by making use of early exits
866 and the ``continue`` keyword in long loops. Consider this code that does not
869 .. code-block:: c++
874 ... some long code ....
880 This code has several problems if the body of the ``'if'`` is large. When
886 within the body of the code, it is indented an extra level. Finally, when
891 It is much preferred to format the code like this:
893 .. code-block:: c++
909 ... some long code ....
915 .. code-block:: c++
929 understand at a glance. The problem with this sort of code is that it gets very
930 nested very quickly. Meaning that the reader of the code has to keep a lot of
935 .. code-block:: c++
961 .. code-block:: c++
985 .. code-block:: c++
1005 .. code-block:: c++
1020 The idea is to reduce indentation and the amount of code you have to keep track
1021 of when reading the code.
1030 .. code-block:: c++
1046 .. code-block:: c++
1062 code which can often be shared by other code that checks for the same predicate.
1066 the reader to understand the code that queries for this predicate. Instead of
1113 .. code-block:: c++
1128 .. code-block:: c++
1159 .. code-block:: c++
1168 .. code-block:: c++
1182 In the past, asserts were used to indicate a piece of code that should not be
1185 .. code-block:: c++
1195 .. code-block:: c++
1202 code for this branch. If the compiler does not support this, it will fall back
1205 Use ``llvm_unreachable`` to mark a specific point in code that should never be
1207 branches, etc., but can be used whenever reaching a particular code path is
1218 value" warning when assertions are disabled. For example, this code will warn:
1220 .. code-block:: c++
1233 disable the warning. To be specific, it is preferred to write the code like
1236 .. code-block:: c++
1256 makes the code **clearer**, because it is immediately obvious what facilities
1258 namespace clashes cannot occur between LLVM code and other namespaces. The
1265 namespace) is for implementation files. For example, all of the code in the
1266 LLVM project implements code that lives in the 'llvm' namespace. As such, it is
1271 is that any ``.cpp`` file that implements code in any namespace may use that
1306 loops wherever possible for all newly added code. For example:
1308 .. code-block:: c++
1325 .. code-block:: c++
1336 .. code-block:: c++
1362 container isn't being modified, which makes it easier to read the code and
1382 New code should always use `raw_ostream`_ for writing, or the
1392 ``std::ostream``. All new code should use ``raw_ostream`` instead of
1407 .. code-block:: c++
1423 .. code-block:: c++
1434 .. code-block:: c++
1455 .. code-block:: c++
1488 because we want code to `fit into 80 columns`_ without excessive wrapping, but
1489 also because it makes it easier to understand the code. To facilitate this and
1494 .. code-block:: c++
1544 .. code-block:: c++
1565 .. code-block:: c++
1590 maintainability of the code.
1611 .. code-block:: c++