| |
| <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.php">Eclipse |
| Project Charter</a> page.</li> |
| </ul> |
| <h3>Code Comments:</h3> |
| <ul> |
| <li> comments are a good thing.</li> |
| <li> comment all "unobvious" 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 "temp" or "index" |
| (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> |
| Javadoc -> Process Javadoc comments<br> |
| - Malformed Javadoc comments -> warning <br> |
| - Report Errors in tags -> 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 -> 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 "true" case of an "if" clause |
| at the beginning. we also use it to exit a method early. If the whole method |
| is inside an "if (!foo) {}" then just say "if (foo) return".</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 "new File(location.toOSString())" |
| 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("message.key", new |
| String[] { "text" });</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> </p> |