The point is clearly about programming practice. In February 2014, Apple faced an SSL bug. This was a very simple code mistake due to conditional sequences.

Because of the conditional aspect, we easily focus on curly braces. Two comments suggested the solution to such a problem could be about test cases (both articles provide simple code extracts of the guilty section):

• Apple's SSL/TLS bug by Adam Langley
• Reflections on Curly Braces by Tobias Goeschel </li> </ul>

  For sure, testing is an important point in code quality. In an ideal world there would be a test case for any code piece. For sure, there are excellent other tools. I previously wrote about design by contract. Coding a verified program, checking Hoare 's axioms is also an important topic. When it comes to software quality, I won't say any practice is inappropriate.

  Stop dreaming about a world with perfect programs. Let the code verification/prove apart and come back to the code. Adam Langley also suggests code reviews are important. Curly braces ? Perhaps the point isn't central. What matter is a readable code. Some interesting code conventions exist, especially in large organizations such as Google (the naming section is especially interesting). But is respecting rules enough ? Many programmers write endless code sequences. What could be the solution ?

  We, French people, tend to be very verbose in our texts. At school, we are taught to be concise. We do not succeed in any case. How would it be possible in code ? Think about Twitter 140 characters. Just consider what a French journalist could write in 2011. Nowadays, very few journalists still criticize the system. Conciseness can be very precious.

  When it comes to quality control, human verifications are weak. I think the twitter limitation is an interesting idea. In writing programs, we have the advantage of compilation to induce strict checking. Why don't compilers warn when a function exceeds 100 lines (or any number that suits you, to be honest the guilty section is only 80 lines long) ? At first glance, this is not the exact topic because this would not have prevented programmers from coding that bug. In broader sight, I tend to think the solution to that kind of problem is in static checking . It won't be possible to automatically test any piece of written code, or even review it properly.

After some (bad) experiences, I am quite sceptical about MVC frameworks. The hall of fame has accepted a few names: Struts, Play, Wicket... And then ?

Each period has its champion. Struts, as one of the elders, had a long period. So many developers had to use it. But what about software maintenance and evolutions ? Software dependencies between the model, the view and the controller can make moves very challenging. Struts 1 upgrade to version 2 ? What about moving to another technology ?

Quite a nightmare, it is sometimes easier to rewrite completely the application. In my point of view, long term solutions rely directly on the Java platform. The classic Servlet / JSP tandem is not an MVC implementation but is plain and simple and evolutions are easy. I understand JSF enthusiasts. The solution is modern and interesting on a productivity point of view. I have a personal problem with JSF (and others share my opinion) : JSF and JSP are bad companions. What a shame for two specifications...

While the RESTful architectural style is trendy, the idea of integrating JAX-RS and JSPs is interesting (part of Jersey). Hope it will be part of the core specification someday.

Edit (2014-08-21) : the JAX-RS / MVC integration was part of the JSR 339 initial request but was dismissed in the final specification. A recent message on the specification list let me have some hope...

Understanding design by contract is, I think, important for software quality in OOP because the principles are clear and efficient.

B. Bertrand Meyer introduced the idea in 1988. It takes advantage of assertions as defined by C.A.R. Charles Anthony Richard Hoare (1969), the seminal work of an eponymous logic.

Assertions are associated to an object method and qualified in one of three categories :

• Preconditions are assertions true before executing the method
• Postconditions are assertions true after executing the method
• Invariants are assertions true before and after executing the method

Meyer includes his idea in the Eiffel programming language : the assertions are checked in a static way (at compile time).

If the Java programming language provides support for assertions, these are checked only in a dynamic way (at runtime) and disabled by default. Because of runtime checking, exceptions are largely used instead of assertions. In Java, a proper use of exceptions can be more meaningful to the programmer than a proper use of assertions because it provides more details about the malfunction conditions (the stack trace). At first glance, assertions (in the design by contract way) seem to be very far from exceptions. This is to some extent a paradox: I think the developer should consider assertions concepts every time he uses exceptions.

In Effective Java , Bloch defines checked exceptions as recoverable conditions and runtime exceptions as programming errors.

In an non-Java context, Fowler says an exception is a situation where preconditions are satisfied but postconditions can not be satisfied.

I think that, to respect Bloch terms,

• Runtime exceptions should be used for checking preconditions
• Checked exceptions should be used when preconditions are true but postconditions can not be satisfied, assuming that the method is correct (e.g. the network connection is broken). 

If a runtime exception is raised, the calling method should be bugged (or its preconditions are not properly checked).

Some extensions to the Java platform provide support for static testing (assertions checking at compile time). For example, JML takes advantage of Java comments: this is interesting for traditional compiling compliance.

According to The Unified Modeling Language User Guide, object-oriented software elements belong to one of these four categories:

• Structural things
• Behavioral things
• Grouping things
• Notational things

Obviously, classes are structural elements. According to this same book, packaging is the act of grouping classes.

Something is bothering me about packaging. All programs I have been working on, and all courses I have been following, share a single vision of the way these groups should be considered.

In this single vision, classes are grouped on structural criteria. In a same package, we will find objects assuming a single role: DAOs with DAOs, entities with entities, controllers with controllers. To be honest, this helps designing interesting class diagrams. This has a real interest for building effective heritage hierarchies.

But in my point of view, we let apart behavioral criteria. One DAO object usually interacts only with a single entity class and a few services. This means, if we design sequence, activity or state diagrams, the involved objects will belong to different packages. This would be very helpful to help software maintenance: in a single set we have all the relevant elements.

1. Usually, package elements grouping is based on classes roles to help software design
2. Package elements grouping should also be based on classes interactions to help software maintenance

If we would like to design really modular applications, I think we should consider these two axes while packaging. On a pure design point of view, a class should belong to two packages : one structural (1) and one behavioral (2). This could be possible because one class usually has interactions with a few classes.

In Java, one solution to help set up this second kind of packages could be annotations. But the problem would be in class loading. This wouldn't be a real problem if we all time use to write APIs.

A pragmatic solution would be to change the packaging in the development process. Once the software has been designed building interesting heritage hierarchies based on roles, packaging should be modified to follow classes interactions in order to help software maintenance.