The examples in SF.12 are likely to encourage readers to always use the `""` form of `'#include` when including headers from the same project ([discussion](https://github.com/isocpp/CppCoreGuidelines/pull/1596#issuecomment-673266275)). However, in larger projects this may not always be appropriate; `<>` should be used for includes located via a header search path.
This proposed solution adds an example of the later, i.e. where `<>` is used to include a header from the same project.
- Add a cross-reference to C.139 and note that it doesn't matter whether
a function is declared with override or final if the whole class is
already final.
- Fix C.139 to make it clearer that it's about `final` on classes.
explicitly note that "file" refers to as it exists in the location of it being authored/modified.
this is to address any confusion about #including "bar.h" from foo.h based on whether bar.h is relative to foo.h at the time and location foo.h is being modified (e.g. under mylib/foo.h) versus at the time/location from which foo.h is installed to the system and included by the user (e.g. from /usr/include).
Part of SL.str.1 references replacing “const string*” with “string_view”, but the example code above shows “const string&” instead.
This changes the comment to the reference rather than pointer.
As a general rule, `operator()` should be const-qualified.
The exceptions are few and far between.
I was actually looking for a Guideline on that subject;
I grepped for `operator()` and found that not only is there
no such Guideline yet, the doc actually contained these
places that (needlessly) violated the general rule.
* Use '<thing> template' i.s.o. 'template <thing>'
The word 'template' is often wrongly used as an adjective to the 'thing'
it becomes when instantiated.
* Expand succinct formulation for readability
Co-authored-by: Kristoffel Pirard <kristoffel.pirard@vanhool.com>
The _bad_ example wasn't annotated as such and a perfectly fine function
name was marked bad.
Annotate the example as bad and remove the misleading function name
annotation.
For some reason the trailing `e = 3` seemed more of a red flag
than anything else about this line. Let's imply that the programmer
is trying to make some constants for hexadecimal translation.
The current guidance on SF.12 can be over-applied and devolves into "always use <>" because all compilers support adding include directories to the <> search. In this case, even the current directory may be added and so it is always possible to use <> for every header. Applying the guidance then devolves into an undesirable state where <> is always used and include"" is never used.
Instead, the proposed guidance leverages and encourages the distinction between <> and "" to create an easy-to-understand rule that the original guidance hints at and that most developers already follow and understand: "" is for local headers and <> is for library and external headers.
