The Five Rules of Compilation

The complete rules for a compilator based on these three rules:

0. Security: A compiler may not harm any resource or running application.
1. Correctness: A compiler may not harm a source program.
2. Efficiency: A compiler must be fast, except where speed would conflict with the first law.
3. Friendliness: A compiler must assist the user to correct programming errors, as long as such assistance does not conflict with the first and second laws.
4. Informative: A compiler must establish its identiy as the accurate compiler in all cases.
5. Specificness: A compiler must know it is a compiler

Asimov's rules of robotics.

Java interfaces convention

IPortletDefinition or PortletDefinition.
Reasons to drop the I's

• JavaDoc and IDEs like Eclipse differentiate interfaces from classes sufficiently. The Java typing does not also need to be reflected in the type name because our IDEs already give us sufficient visual clues.
• Follow the Sun conventions with the goal of minimizing the "impedance mismatch" between our code-base and the JDK, i.e., our APIs should look like they could be in the JDK. This strategy is helpful pedagogically.
• Keeping with the norm of other open source and java projects.
  

Reasons to keep the I's

• For the sake of consistency between different versions
• To make it easier to tell which files represent java interfaces when viewing files in a list outside of JavaDoc or an IDE like Eclipse, or in Eclipse views which do not illustrate the difference with icons.
• To make it easier to identify java interfaces when looking at java code itself.
• Having the extra I doesn't present a real burden.

The ideot's mission

Knowledge is power - learn it and become a powerman.