aboutsummaryrefslogtreecommitdiff
path: root/llvm/docs/CodingStandards.rst
AgeCommit message (Collapse)AuthorFilesLines
2025-09-30[CodingStandard] Require Unix line endings for all files (#161228)Rahul Joshi1-0/+6
Require all files to use Unix line endings, formalizing an already followed convention.
2025-09-21Document Policy on supporting newer C++ standard in LLVM codebase (#156823)Mehdi Amini1-0/+6
See RFC: https://discourse.llvm.org/t/policy-on-supporting-newer-c-standard-in-llvm-codebase/88114
2025-08-22[llvm] Proofread CodingStandards.rst (#154892)Kazu Hirata1-13/+13
2025-07-28[llvm][docs] Refresh "Restrict Visibility" in Coding Standards (#150914)David Spickett1-12/+24
No change of meaning, just formatting and an extra example to make it easier to comprehend: * Split separate, important points into their own paragraphs. * Remove a contraction. * Finally, show to to use "static" on a function. As before we just showed why namespaces were bad, but not what you should do instead.
2025-07-18[llvm] Improve grammar and punctuation of LLVM Coding Standards (#149463)Kazu Hirata1-23/+23
2025-07-04[llvm] Use llvm::fill instead of std::fill(NFC) (#146911)Austin1-1/+1
Use llvm::fill instead of std::fill
2025-06-25[NFC][CodingStandard] Require``[[maybe_unused]]`` for unused variables in ↵Rahul Joshi1-4/+15
asserts (#142850) Require using attribute `[[maybe_unused]` for assert-only variables that may be unused in non-assert enabled builds to suppress unused variable warnings. --------- Co-authored-by: James Henderson <James.Henderson@sony.com> Co-authored-by: Nikita Popov <github@npopov.com>
2025-03-03[NFC][CodingStandard] Fix text style for C++ keywords (#128932)Rahul Joshi1-11/+12
Fix C++ keywords in Restrict Visibility section to use `` (inline literal) markup to be consistent with the rest of the doc.
2025-02-24[CodingStandard] Rework anonymous namespace section to cover visibility more ↵Rahul Joshi1-11/+17
broadly (#126775) - Rename anonymous namespace section and rework it to cover visibility more broadly. - Add language suggesting restricting visibility as much as possible, using various C++ facilities. --------- Co-authored-by: Aaron Ballman <aaron@aaronballman.com>
2024-12-04[NFC] Eliminate need of Emacs tag and file name in file header (#118553)Rahul Joshi1-12/+2
- Simplify file header to not require file name and C++ Emacs tag. See https://discourse.llvm.org/t/is-c-in-header-files-still-relevant/83124/1
2024-10-14[NFC][CodingStandard] Extend if-else brace example with else-if (#112193)Rahul Joshi1-1/+4
Extend example to document that single statement `else if` needs a brace as well if the associated `if` needs a brace.
2024-10-11[NFC][CodingStandard] Add additional example for if-else brace rule (#111733)Rahul Joshi1-0/+8
Add example to document that single statement `else` needs a brace if the associated `if` needs a brace.
2024-02-13[docs] Update links for C++ compiler supported features in CodingStandards ↵Richard Dzenis1-1/+4
(#81587)
2023-11-09[doc] Add casting style preference to coding standardsJames Henderson1-0/+13
Differential Revision: https://reviews.llvm.org/D151187
2023-10-21[docs] Fix suggested darker command in coding standards (#69860)Jakub Kuderski1-1/+1
Do not attempt to format deleted files.
2023-09-14[docs] Add more details about Python formatting (#66141)Joel E. Denny1-4/+34
Describe the darker utility. Make it clear that black/darker's default rules should be used. Add some examples. See ongoing discussion at <https://discourse.llvm.org/t/rfc-document-and-standardize-python-code-style/68257>.
2023-06-17[Coding style] Fix incorrect link syntaxFelipe de Azevedo Piovezan1-2/+2
2023-06-17[docs] Fix link for static constructors articlePrajwal S N1-2/+2
It was previously present in the inline code block and did not work as a hyperlink. Reviewed By: yassingh Differential Revision: https://reviews.llvm.org/D153061
2023-05-28Fix typos in documentationKazu Hirata1-1/+1
2023-05-15[docs] Add Python coding standard to documentationTobias Hieta1-0/+18
As discussed on the forums: https://discourse.llvm.org/t/rfc-document-and-standardize-python-code-style/ Reviewed By: jhenderson, JDevlieghere Differential Revision: https://reviews.llvm.org/D143852
2023-01-06Revert "CodingStandards: restrict CamelCase variable names guideline to ↵Nikita Popov1-4/+2
llvm/clang/clang-tools-extra/polly/bolt" This reverts commit ee9ccb11036ac46ff9b9f3fa2d459d9d2bce5509. See https://reviews.llvm.org/D140585#4019417 and following. Multiple people requested a revert of this change pending further discussion.
2023-01-05Remove documentation about the Go bindingsAaron Ballman1-19/+0
We removed the Go bindings in https://reviews.llvm.org/D135436 but missed documentation that talks about the bindings.
2022-12-28CodingStandards: restrict CamelCase variable names guideline to ↵Fangrui Song1-2/+4
llvm/clang/clang-tools-extra/polly/bolt See https://discourse.llvm.org/t/top-level-clang-tidy-options-and-variablename-suggestion-on-codingstandards/58783 , the CamelCase variable names guideline does not reflect the truth: flang, libc, libclc, libcxx, libcxxabi, libunwind, lld, mlir, openmp, and pstl use camelCase. lldb uses snake_case. Reviewed By: mehdi_amini Differential Revision: https://reviews.llvm.org/D140585
2022-08-19Update coding standards for constexpr if statements; NFCAaron Ballman1-0/+18
We currently suggest that users not use an else clause after a return statement in a prior if branch. e.g., if (foo) return 1; else // Should remove this else clause return 10; however, this suggestion is incorrect for a constexpr if statement because one of the two branches will be a discarded statement and thus can impact template instantiation behavior. This updates the coding standard to make it clear that it's okay to have a return after an else in a constexpr if statement. I think this is an NFC change to the intent of the rule, which is why I've not started an RFC for the changes. Differential Revision: https://reviews.llvm.org/D132232
2022-08-06[LLVM] Update C++ standard to 17Tobias Hieta1-2/+8
Also make the soft toolchain requirements hard. This allows us to use C++17 features in LLVM now. If we find patterns with C++17 that improve readability it should be recommended in the coding standards. Reviewed By: jhenderson, cor3ntin, MaskRay Differential Revision: https://reviews.llvm.org/D130689
2022-05-31[Docs] Clarify the guideline on omitting bracesowenca1-24/+33
While working on a clang-format option RemoveBracesLLVM that removes braces following the guideline, we were unsure about what to do with the braces of do-while loops. The ratio of using to omitting the braces is about 4:1 in the llvm-project source, so it will help to add an example to the guideline. Also cleans up the original examples including making the nested if example more targeted on avoiding potential dangling else situations. Differential Revision: https://reviews.llvm.org/D126512
2022-05-05Fix "the the" typo in documentation and user facing stringsBrian Tracy1-1/+1
There are many more instances of this pattern, but I chose to limit this change to .rst files (docs), anything in libcxx/include, and string literals. These have the highest chance of being seen by end users. Reviewed By: #libc, Mordante, martong, ldionne Differential Revision: https://reviews.llvm.org/D124708
2021-12-07[doc] Fix namespace comment style in Coding GuidelinesCarlos Galvez1-5/+5
The Coding Guidelines specify that the ending brace of a namespace shall have a comment like: } // end namespace clang However the majority of the code uses a different style: } // namespace clang Indeed: $ git grep '// end' | wc -l 6724 $ git grep '// namespace' | wc -l 14348 Besides, this is the style enforced automatically by clang-format, via the FixNamespaceComments option. Having inconsistencies between the Coding Guidelines and the code/tooling creates confusion, can lead to bikeshedding during reviews and overall delays merging code. Therefore, update the guidelines to reflect current usage. Updating legacy code to the new standard should be done in a separate patch, if wanted. Reviewed By: jyknight Differential Revision: https://reviews.llvm.org/D115115
2021-11-15[NFC] Trim trailing whitespace in *.rstShao-Ce SUN1-3/+3
2021-10-21[docs] Fix broken link rendering in the LLVM Coding Standards.Frederic Cambus1-2/+2
2020-12-21Update references to 'master' branch.Hafiz Abid Qadeer1-1/+1
This commit replace 'master' with 'main' in llvm/docs. Reviewed By: sammccall, kristof.beyls Differential Revision: https://reviews.llvm.org/D92831
2020-11-13llvmbuildectomy - replace llvm-build by plain cmakeserge-sans-paille1-2/+1
No longer rely on an external tool to build the llvm component layout. Instead, leverage the existing `add_llvm_componentlibrary` cmake function and introduce `add_llvm_component_group` to accurately describe component behavior. These function store extra properties in the created targets. These properties are processed once all components are defined to resolve library dependencies and produce the header expected by llvm-config. Differential Revision: https://reviews.llvm.org/D90848
2020-07-30[doc] Describe the header guard styleMircea Trofin1-0/+10
clang-tidy's llvm-header-guard rule references the LLVM style - where it's missing. Differential Revision: https://reviews.llvm.org/D84989
2020-07-15Clarify a bit the guideline on omitting braces, including more examples (NFC)Mehdi Amini1-23/+71
Like most readability rules, it isn't absolute and there is a matter of taste to it. I think more recent part of the project may be more consistent in the current application of the guideline. I suspect sources like mlir/lib/Dialect/StandardOps/IR/Ops.cpp may be examples of this at the moment. Differential Revision: https://reviews.llvm.org/D82594
2020-07-09[Docs] CodingStandards: for_each is discouragedRoman Lebedev1-0/+3
Summary: As per disscussion in D83351, using `for_each` is potentially confusing, at least in regards to inconsistent style (there's less than 100 `for_each` usages in LLVM, but ~100.000 `for` range-based loops Therefore, it should be avoided. Reviewers: dblaikie, nickdesaulniers Reviewed By: dblaikie, nickdesaulniers Subscribers: hubert.reinterpretcast, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D83431
2020-06-15[Docs] Add missing space, requested on c08ea07Erich Keane1-1/+1
2020-06-11Add to the Coding Standard our that single-line bodies omit bracesErich Keane1-15/+62
This is a rule that seems to have been enforced for the better part of the decade, so we should document it for new contributors. Differential Revision: https://reviews.llvm.org/D80947
2020-06-04[docs] Fix self-contradictory description of llvm_unreachableJan Korous1-2/+1
Just two paragraphs above it says: "If the compiler does not support this [skipping code generation for a particular branch], it will fall back to the "abort" implementation." And that actually correctly describes llvm_unreachable implementation. Differential Revision: https://reviews.llvm.org/D81130
2020-03-31[docs] Document coding standard for error and warning messagesJames Henderson1-0/+40
In particular, these messages should start with a lower-case letter and should have no trailing period at the end of the last sentence. See http://lists.llvm.org/pipermail/llvm-dev/2020-March/140178.html for context. Reviewed by: aaron.ballman, hubert.reinterpretcast, rnk, dblaikie Differential Revision: https://reviews.llvm.org/D76833
2020-03-26Clarify use of llvm_unreachable in the coding standard.Aaron Ballman1-0/+7
There has been some ongoing confusion regarding when to use `llvm_unreachable` which this patch attempts to address. Specifically, the confusion has been around whether `llvm_unreachable` is intended to mark only unreachable code paths that the compiler cannot determine itself or to mark a code path which is unconditionally a bug to reach. Based on email and IRC discussions, it sounds like "unconditional bug to reach" is the consensus.
2020-02-18Add coding standard recommending use of qualifiers in cpp filesReid Kleckner1-0/+43
There is prior art for this in the code base itself, and a recent example of this here: c45f8d49897f This came up in discussion on this review where @maskray was going the opposite direction: https://reviews.llvm.org/D68772 Given that there is disagreement, we should make a choice and document it. Thanks to John McCall for the precise wording. Reviewed By: MaskRay, rjmccall Differential Revision: https://reviews.llvm.org/D74515
2020-02-11[CodingStandards] Add link to "Picking the Right Data Structure"Johannes Doerfert1-0/+4
See https://reviews.llvm.org/D74340
2020-02-10[CodingStandards] Clarify C++ Standard Library usageJohannes Doerfert1-10/+18
The existing wording leaves it unclear if C++ standard library data structures should be preferred over custom LLVM ones, e.g., SmallVector, even though common practice seems clear on the issue. This change makes the wording more explicit and aligns it better with the code base. Some motivating statistics: ``` ag SmallVector llvm/lib/ | wc 8846 40306 901421 ag 'std::vector' llvm/lib/ | wc 2123 8990 214482 ag SmallVector clang/lib/ | wc 3023 13824 281691 ag 'std::vector' clang/lib/ | wc 719 2914 72817 ``` Differential Revision: https://reviews.llvm.org/D74340
2020-01-22[llvm] NFC: fix trivial typos in documentsKazuaki Ishizaki1-2/+2
Reviewers: hans, Jim Reviewed By: Jim Subscribers: jvesely, nhaehnle, mgorny, arphaman, bmahjour, kerbowa, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D73017
2019-11-21Make coding standards document more inclusiveDmitri Gribenko1-331/+178
Summary: Patch by Doug Gregor, Tres Popp, and Dmitri Gribenko. Reviewers: chandlerc Subscribers: hfinkel, bmcreusillet, arsenm, doug.gregor, mgrang, arphaman, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D69354
2019-10-23Remove a no longer accurate sentence from the coding standards.Chandler Carruth1-2/+1
(And test my commit access. We're working on larger changes here.)
2019-08-14Move to C++14JF Bastien1-96/+8
Summary: I just bumped the minimum compiler versions to support C++14 in D66188. Following [our process](http://llvm.org/docs/DeveloperPolicy.html#toolchain) and [our previous agreement](http://lists.llvm.org/pipermail/llvm-dev/2019-January/129452.html), I'm now officially bumping the C++ version to 14 and updating the documentation. Subscribers: mgorny, jkorous, dexonsmith, llvm-commits, chandlerc, thakis, EricWF, jyknight, lhames, JDevlieghere Tags: #llvm Differential Revision: https://reviews.llvm.org/D66195 llvm-svn: 368887
2019-01-19Update the coding standards with the new file header.Chandler Carruth1-4/+3
llvm-svn: 351652
2018-11-14Document how to comment an actual parameter.Paul Robinson1-0/+15
Differential Revision: https://reviews.llvm.org/D54446 llvm-svn: 346861
2018-08-26[IR] Replace `isa<TerminatorInst>` with `isTerminator()`.Chandler Carruth1-2/+2
This is a bit awkward in a handful of places where we didn't even have an instruction and now we have to see if we can build one. But on the whole, this seems like a win and at worst a reasonable cost for removing `TerminatorInst`. All of this is part of the removal of `TerminatorInst` from the `Instruction` type hierarchy. llvm-svn: 340701
generated by cgit v1.1 at 2025-10-19 20:19:24 +0000