blob: 5f72d164efa47351deab2a0ae1eb7a22ba7e764e [file] [log] [blame]
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:TaskDescription xmi:version="2.0"
xmlns:xmi="" xmlns:org.eclipse.epf.uma=""
xmlns:epf="" epf:version="1.2.0" xmi:id="-qIbMRqe8wqKN2-HLtNUcLw"
name="define_coding_standard,{C88D5B0A-1A59-4575-ADDF-8ECBBAB83410}" guid="-qIbMRqe8wqKN2-HLtNUcLw"
<sections xmi:id="_oCfyEGE-EdqnIZeW8YpHcA" name=" Write Prototypical Classes " guid="_oCfyEGE-EdqnIZeW8YpHcA">
<sectionDescription>&lt;a id=&quot;Step1&quot; name=&quot;Step1&quot;>&lt;/a>
When deciding on a coding standard, take the time to write a few classes which use a particular style. Should the curly
braces be flush with the indentation of the line above? Do we use tabs or spaces? Are abbreviations permitted? If so,
do we have a short list?
<sections xmi:id="_oCfyEWE-EdqnIZeW8YpHcA" name=" Discuss Standard " guid="_oCfyEWE-EdqnIZeW8YpHcA">
<sectionDescription>&lt;a id=&quot;Step2&quot; name=&quot;Step2&quot;>&lt;/a>
The coding standard for a project should be as simple as possible. The goal is not to forbid error prone constructs,
but rather to make the code as communicative and uniform as possible so it can be understood and worked on readily. If
the team cannot reach consensus, use majority rule. Having a standard is more important than the specific details.
&lt;br />
<purpose>&lt;a id=&quot;XE_define_coding_standard__activity_definition&quot; name=&quot;XE_define_coding_standard__activity_definition&quot;>&lt;/a> &#xD;
To aid clarity by making the style of code as familiar as possible.&#xD;