6502/llvm-6502
1
0
Fork 0
mirror of https://github.com/c64scene-ar/llvm-6502.git synced 2025-08-08 19:25:47 +00:00
Code Issues Projects Releases Wiki Activity

restructure this for readability, correct the example to follow the public ivar name convention

Browse Source 
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@121443 91177308-0d34-0410-b5e6-96231b3b80d8
This commit is contained in:
Chris Lattner
2010-12-10 00:52:35 +00:00
parent 2ea8ee7c76
commit 69ad797214
1 changed files with 45 additions and 27 deletions
Download Patch File Download Diff File Expand all files Collapse all files

72
docs/CodingStandards.html
View File

@@ -814,32 +814,46 @@ locality.</p>
</div> </div>
<div class="doc_text"> <div class="doc_text">
<p>Poorly-chosen names mislead the reader and cause bugs. We cannot <p>Poorly-chosen names can mislead the reader and cause bugs. We cannot
stress enough how important it is to use <em>descriptive</em> names. stress enough how important it is to use <em>descriptive</em> names.
Pick names that match the semantics and role of the underlying Pick names that match the semantics and role of the underlying
entities, within reason. Avoid abbreviations unless they are well entities, within reason. Avoid abbreviations unless they are well
known.</p> known. After picking a good name, make sure to use consistent capitalization
for the name, as inconsistency requires clients to either memorize the APIs or
to look it up to find the exact spelling.
</p>
<p>In general, names of types, functions, variables, and enumerators <p>In general, names should be in camel case (e.g. <tt>TextFileReader</tt>
should be in camel case (e.g. <tt>TextFileReader</tt> and <tt>isLValue()</tt>). Different kinds of declarations have different rules:
and <tt>isLValue()</tt>). Type names (including classes, structs, </p>
enums, typedefs, etc) should be nouns and start with an upper-case
letter (e.g. <tt>TextFileReader</tt>). An <tt>enum</tt> for all the
different kinds of something should be named with the <tt>Kind</tt>
suffix. Function names should be verb phrases (as they represent
actions) and start with a lower-case letter (e.g. a predicate may be
named <tt>isFoo()</tt> or <tt>hasBar()</tt>, while the name of a
command-like function should be imperative,
like <tt>openFile()</tt>).</p>
<p>Enumerators and public member variables should start with an <ul>
upper-case letter, just like types. Unless the enumerators are <li><b>Type names</b> (including classes, structs, enums, typedefs, etc) should
defined in their own small namespace or inside a class, they should be nouns and start with an upper-case letter (e.g. <tt>TextFileReader</tt>).
have a prefix. For example, <tt>enum ValueKind { ... };</tt> may </li>
contain enumerators like
<tt>VK_Argument</tt>, <tt>VK_BasicBlock</tt>, etc. Enumerators that <li><b>Function names</b> should be verb phrases (as they represent
are just convenience constants are exempt from the requirement for a actions), and command-like function should be imperative. The name should
prefix. For instance:</p> be camel case, and start with a lower case letter (e.g. <tt>openFile()</tt>
or <tt>isFoo()</tt>).
</li>
<li><b>Enum declarations</b> (e.g. "enum Foo {...}") are types, so they should
follow the naming conventions for types. A common use for enums is as a
discriminator for a union, or an indicator of a subclass. When an enum is
used for something like this, it should have a "Kind" suffix (e.g.
"ValueKind").
</li>
<li><b>Enumerators</b> (e.g. enum { Foo, Bar }) and
<b>public member variables</b> should start with an upper-case letter, just
like types. Unless the enumerators are defined in their own small
namespace or inside a class, enumerators should have a prefix corresponding
to the enum declaration name. For example, <tt>enum ValueKind { ... };</tt>
may contain enumerators like <tt>VK_Argument</tt>, <tt>VK_BasicBlock</tt>,
etc. Enumerators that are just convenience constants are exempt from the
requirement for a prefix. For instance:</p>
<div class="doc_code"> <div class="doc_code">
<pre> <pre>
enum { enum {
@@ -849,6 +863,10 @@ enum {
</pre> </pre>
</div> </div>
</li>
</ul>
<p>As an exception, classes that mimic STL classes can have member names <p>As an exception, classes that mimic STL classes can have member names
in STL's style of lower-case words separated by underscores in STL's style of lower-case words separated by underscores
(e.g. <tt>begin()</tt>, <tt>push_back()</tt>, and <tt>empty()</tt>).</p> (e.g. <tt>begin()</tt>, <tt>push_back()</tt>, and <tt>empty()</tt>).</p>
@@ -858,16 +876,16 @@ in STL's style of lower-case words separated by underscores
<pre> <pre>
class VehicleMaker { class VehicleMaker {
... ...
Factory&lt;Tire&gt; f; // Bad -- abbreviation and non-descriptive. Factory&lt;Tire&gt; F; // Bad -- abbreviation and non-descriptive.
Factory&lt;Tire&gt; factory; // Better. Factory&lt;Tire&gt; Factory; // Better.
Factory&lt;Tire&gt; tireFactory; // Even better -- if VehicleMaker has more than one Factory&lt;Tire&gt; TireFactory; // Even better -- if VehicleMaker has more than one
// kind of factories. // kind of factories.
}; };
Vehicle MakeVehicle(VehicleType Type) { Vehicle MakeVehicle(VehicleType Type) {
VehicleMaker m; // Might be OK if having a short life-span. VehicleMaker M; // Might be OK if having a short life-span.
Tire tmp1 = m.makeTire(); // Bad -- 'tmp1' provides no information. Tire tmp1 = M.makeTire(); // Bad -- 'tmp1' provides no information.
Light headlight = m.makeLight("head"); // Good -- descriptive. Light headlight = M.makeLight("head"); // Good -- descriptive.
... ...
} }
</pre> </pre>