
<h1 align="center">Eclipse Platform/Core Coding Conventions</h1>
<p align="left">Here are some of the Coding Conventions that we use as a team. 
  Common code makes it easier for everyone to read and understand.</p>
<h3>Code Formatter:</h3>
<ul>
  <li>set line length to be something large (like 800)</li>
  <li>turn off formatting for comments</li>
  <li> use the core formatting settings found <a href="core_formatting.xml">here</a></li>
</ul>
<h3>Organize imports:</h3>
<ul>
  <li> number of imports needed for *: 3</li>
  <li> remove all entries in list so we don't use the grouping feature</li>
  <li> its all about space...extra blank lines make it hard to read code when 
    you have a small editor window</li>
</ul>
<h3>Copyright:</h3>
<ul>
  <li> make sure the code has the correct copyright.</li>
  <li>if the code was written in 2003, don't have 2000,2003 in the copyright</li>
  <li>the copyright can be found on the <a href="http://www.eclipse.org/eclipse/eclipse-charter.html%20">Eclipse 
    Project Charter</a> page.</li>
</ul>
<h3>Code Comments:</h3>
<ul>
  <li> comments are a good thing.</li>
  <li> comment all &quot;unobvious&quot; things (e.g. don't comment setters/getters)</li>
</ul>
<h3>The art of naming</h3>
<ul>
	<li>Chose class/method/field names that describe the purpose of the entire method/class</li>
	<li>Don't use word fragments (getProjectValue is better than getProjVal)</li>
	<li>Don't use generic variable names like &quot;temp&quot; or &quot;index&quot;
	(Exception: really short methods where usage is very straight-forward.  Ok to use i,j, 
	it for loop indexes)</li>
	<li>Don't use get/set prefix unless the method really is just an accessor. If the
	method does real work, it's not an accessor. (Note: we don't always follow
	this rigorously, but we try).</li>
</ul>

<h3>General: (use the tool!)</h3>
<ul>
  <li>Turn on all the compiler prefs including unused temps, synthetic accessor 
    methods, unused imports, unused parameters, non-NLS'd strings, etc etc</li>
  <li>Turn on compiler warnings for javadoc<br>
    &nbsp;&nbsp;Javadoc -&gt; Process Javadoc comments<br>
    &nbsp;&nbsp;&nbsp;&nbsp;- Malformed Javadoc comments -&gt; warning <br>
    &nbsp;&nbsp;&nbsp;&nbsp;- Report Errors in tags -&gt; true </li>
  <li> NLS your strings. Look at the Policy class.</li>
  <li> Compiler tasks. We have 3 that we use as a team (TODO, FIXME, XXX) Do not 
    add your own as this is unecessary and requires everyone on the team to change 
    their compiler settings in order to see these tasks.</li>
  <li>Sort the methods within a class alphabetically (use the sort members action).</li>
  <li> All classes MUST have a copyright notice.</li>
  <li> data type size initialization -&gt; use meaningful values if possible, 
    not things like: new HashSet(65)</li>
  <li> Use interfaces when declaring variable types and in method signatures unless 
    it is necessary to use implementing class</li>
  <li> use accessor methods, don't access variables on other classes directly</li>
  <li> in general, we use the &quot;true&quot; case of an &quot;if&quot; clause 
    at the beginning. we also use it to exit a method early. If the whole method 
    is inside an &quot;if (!foo) {}&quot; then just say &quot;if (foo) return&quot;.</li>
  <li> ignored exceptions must have a comment saying that they are being ignored 
    on purpose (compiler warning)</li>
  <li> the lines where we create new CoreExceptions and throw them can become 
    quite long. We usually declare the String message on the line previous to 
    make it easier to read.</li>
  <li> check for null if null could be returned (table look-ups, etc)</li>
  <li> should use IPath for path logic rather than Strings and concatination</li>
  <li> IPaths are your friend. Replace &quot;new File(location.toOSString())&quot; 
    with location.toFile();</li>
  <li> Don't catch Exception unless you have to. Try to catch specific exceptions.</li>
  <li> Don't wrap the whole method in a try {} catch {} block. This makes it hard 
    to generate specific error messages</li>
  <li> if you have nested readers/streams you should only have to call #close() 
    on the outside one and all wrapped streams should be closed automatically 
    (note: you may have to call #flush() first)</li>
  <li> Ensure all file I/O is buffered.</li>
  <li> When sharing code with others, ensure that all the code released to the 
    repository at least compiles. </li>
  <li> Policy.bind() has multiple methods, one of which accepts a single string 
    as an arg so you don't have to call Policy.bind(&quot;message.key&quot;, new 
    String[] { &quot;text&quot; });</li>
</ul>
<h3>NLS'ing your code: messages.properties</h3>
<ul>
  <li> all sentences which are displayed to the user must end with a period</li>
  <li> include parameters if possible</li>
  <li> remove unused messages</li>
  <li> make sure if the message accepts a parameter then you pass one in</li>
</ul>
<p>&nbsp;</p>