Coding Standards...

JavaPro has a piece on Why Coding Standards?, and I could not agree more. Each developer having their own style really makes maintenance and reading code much harder, and one problem that generally comes out of this is that branches are merged that reformat the code to the next developers tastes, and they happen to fix some bug in the middle of the code. These types of branches are the worst, because it makes it near impossible to compare the latest version of code to an older versions, since this stylistic factor overtakes the code, and you cannot make heads or tails of the changes.

Of equal annoyance are those developers who redo the code without understanding what the code actually does. Just earlier today I was reminded of this, as I was shown a piece of code that the person purported was mine. I looked at it, and I was rather surprised that it was mine as I quickly noticed a few obvious mistakes in the code. Looking through the history of this particular file, I was able to track down that the same developer who was confused of the code was actually the one who had rewritten the original code for simply stylistic reasons. This cannot be confused with refactoring, since the code was changed without maintaining the original contracts.

Coding standards can help to prevent bugs. I always use and highly recommend the standard that the article discusses from Sun, where statements are always surrounded by brackets, has prevented many bugs, and sometimes some confusion, simply by using this style. The next one regarding commenting is not one that I fully subscribe to though, since this generally produces code that has no comments what so ever, and such code may make sense today, but in the future, it can be hard to actually understand what the algorithm or function is suppose to do. This particular article hints that JavaDocs could be used instead of this, which could work nicely, since your methods should be short.

In the area of coding standards, getting very strict can make all the code look as it were developed by a single developer. To do this, though, some help of tools generally help. Tools like Borland's JBuilder has some reformatting and analysis capabilities that allows you to check your code against the standards while you are writting it, and this can be very useful.

Choosing the right standards, however, can be involved, and this is not covered by the article. For Java, many developers follow the Sun Coding Convension. For C++, this is hard one; from what I have seen, this may be C++ Coding Standards by Herb Sutter and Andre Alexandrescu, but there are really many topics and things to consider in such standards. Definitely some common knowledge, such as that of Effective Java, Effective C++, More Effective C++, Effective STL, Large Scale c++, and a variety of other books should be part of that coding standard.

Standards simply make better code, but you cannot apply such standards blindly; you need to understand why you are applying the standard, and more specifically, you need to know when you can break the rules. If you do not have a coding standard, it is probably time you have one.

Got your back...

Peter Varhol has posted a blog entitled Got Your Back, and in it, he talks about ways to ensure stable code, by essentially knowing how to use tools. His examples note code reviews, unit tests, and exception handling in the list of tools, but I would also add in logging in this list, since when you log sufficient information, it can be used to also see situations and bugs that would be extremely harder using other methods.

All of these tools are essentially insurance for your software, which could contain anything from a simple one line bug or a complex architectural problem. The aforementioned tools will attempt to exercise your software in ways to expose these conditions. Of course, this means that you really have to include code reviews in your process, and to actually attempt to break code when creating test suites and run such automated tests regularly. This means that you have to use language features to make your productivity higher, and that you need to actually log information in an accessible and usable fashion.

At present, you need people to ensure that these things happen, and this comes back to the broken window theory. If a developer is used to strict coding standards, and is then exposed to a group with no coding standard, chances are that his own code will get slightly sloppier, simply out of the case that there is no authority to curve this. But such examples are an over abundance in business, as discussed in books such as Database Systems Management and Design.

There is, however, no question that such behaviours are time consuming, and as such, it would be great to automate these to take some burden off the people involved in a project, but as Peter says, we are not there yet, and I think we are far off. Modern IDE's have been improving significantly over the years, and movements into this direction are highlighted by Borland's integration of their Caliber requirements management application into their IDE's. And while this does seem that it would allow for tracking of software features from inception to delivery, I suspect that such products will suffer from how they are used and maintaining that ever important shared vision. Specifically, if the tools are not properly integrated, I see developers using them in vastly different ways, and while this flexibility is good for some aspects, this flexibility could harm the usability of feature tracking. But also such tools will still require human intervention for many years to come, as they will not really be able to decide the completeness of a feature alone, let alone whether the implementation accurately reflects the desires of the user.

Until we are presented with software that can think for itself, there is no way to get rid of people completely, but by using unit tests, language features, and logging coupled with code reviews, quality software can be not only developed, but maintained.

Some Environmental Antipatterns...

The October issue of ACM's Queue has an interesting piece by Phillip Laplante, which discusses some anti-patterns in our industry. These antipatterns and more are going to be published in the book Antipatterns for IT, co-authored by Colin Neill.

The first one discussed is called, “The Burning Bag of Dung” and relates to the prank of lighting up a bag of dog-doings on a neighbours porch, ringing the door bell, and fleeing. We have all have been left with some such bag at some point of our lives, as Phillip enumerates, such as poor software development practices, and usually addressing such problems is not easy. He does present an example and some ways to resolve the issue, but these are rather specific to the example.

The next antipattern described is Founderitis, which describes an organization where the founder has problems letting go when the organization gets bigger than the person can handle, since the talents required to startup an organization are different than those required to run a successful organization. The example he presents are a few organizations that have more than $100 million in revenues, and the founder is still an active developer and approves all changes to the code base. He states that most venture capitalists will recognize this, and will remove the founder from the organization, although Phillip does mention other solutions. This is similar to something I was told regarding an organization, where the new management inquired who were the people that the company could not survive without, and when they received this list, they proceeded to fire all those people. While it seemed as strange logic then, in retrospect, the company was able to succeed, partially because of this.

Another very interesting one was the one entitled the “Shoeless Children,” in which is based on the fable that the children of the shoemaker do not have shoes, since the shoemaker is too busy servicing his clients. The analogy is how some organizations are too busy creating new and better tools for their customers and use the latest technology for this, however, they do not create tools to help themselves and their own infrastructure is no where near their client's infrastructure. This is often based on penny-pinching, but its solution is not always as easy as expanding the budget, and Phillip provides a little more description in the article about the situations around it.

The final one is called “worshiping the Golden Calf,” and this is about hoping that a new technology or methodology will solve all the problems, but this new technology or methodology is poorly understood. This situation usually occurs where there is a poor shared vision or poor leadership. This “golden calf” could also be unknown, such as in the “hockey stick” revenue projection, where after a number of poor quarters, there are a few good quarters, and people start to believe that the ship is turning around and that it will continue in this pattern. Solving the pattern is not easy though.

I really enjoyed the article, and I look forward to seeing their book, as I am sure that it will open your eyes to situations which are around you. And knowing that there is a potential problem is the first step towards fixing it.

J#'s raison d'être...

Jim Fawcette has blogged a piece stating that Sun's law suit undermined Java, stating that the law suit against Microsoft discouraged Microsoft from using Java as its primary development language, but I do not buy this. With this logic, I can only guess that one of the UML vendors has also sued Microsoft, and this is what forced Microsoft to develop their new modeling language?

I am not arguing that the Sun law suit was a good thing for Java, but Microsoft has a long history of developing their own proprietary tools, and there are always reasons behind their decisions. Specifically, as noted by here, J# was late in the announcements, and I remember reading at one point that the reason for this was more that Microsoft was originally not going to provide a Java implementation, but later realized that Java was part of the U.S. college and university curricula as soon as late 1997, and by not providing a Java implementation, new developers would not be exposed to their technologies, and this is the reason that J# was added.

In the case of their proprietary modeling language, we received a demo of Visual Studio 2005 at OOPSLA during Richard Rashid's keynote entitled, “The Future Of Programming.” With such a title, I, along with many other attendees, were expecting more of a discussion in the more distant future than next year. Instead he discussed many of the technologies that Microsoft is presently developing and using in-house (such as PreFIX that should come with 2005) and some observations on the future (such as we are now almost at human-scale storage, where we are almost able to keep everything on a hard disk, without ever having to delete anything), but a good portion of this discussion was a demo of Visual Studio, including the model-zooming functionality. Following the keynote, I asked the demo's presenter two questions, first about cross platform tools and secondly about their choice against UML. Regarding the cross platform, he indicated very vaguely that there is something in the plan that he cannot comment right now (Maybe, or rather hopefully, something with Mono?), and regarding the UML question, his answer was simply that not everything is object-oriented. Regarding the latter comment, I find Keith Short's answer at least more in the proper direction, but I am not sure about the approach. I think I will just have to give it a run to see what they have really done.

Jim appears to make some other comments about what might have been, but without any references, it is hard to know whether these are opinions or what. I am not as certain as Jim is that things would be any different than they are now.

J2EE and .NET are friends after all...

Java Developers Journal has an article entitled “J2EE + .NET, in which suggests that a number of organizations are combining J2EE and .NET, taking the best of the two worlds into creating new applications. This is about taking a look at the proper tool for the job and selecting the tool based on all the factors, not just what you know.

While I agree with a good portion of the article, one thing that really sticks out of the article (and perhaps I am just reading into it) is that Microsoft has revolutionized development environments by allowing all developers to be highly productive in the environment, suggesting that the “type in which ever language you prefer” is an advantage. This is not to say that it does not have any advantages, but one major issue that is sometimes overlooked here is that of maintenance of the code. While yes, it is great for the new intern to be completely productive in a non-mainstream language, such as Eiffel ENViSioN, this environment is not a “read in which ever language you prefer” and since code is read more than it is written, the choice of language is still an important issue for maintenance, such as for resolving bugs or to extend the existing functionality.

The other issue is how some of the languages supported are more-or-less coerced onto the CLI framework. An example of this was when I was talking about the C++/CLI extensions, but an even better article on the topic is Richard Grimes article in the November 2004 issue of C++ Users Journal, where he describes extensions for properties, events (delegates), interfaces, generics, and more, and I find these extensions even more disturbing than I did before. Take for example the following sample class from Listing 2 of the article:

ref class Person {
public:
  property String^ Name
  {
      String ^ get() { return name; }
      void set(String^ b) { name = n; }
  }
  property int Age;
private:
  String^ name;
};

While these constructs are extremely powerful and all, this is not C++, and even with using the preprocessor, it looks like it would be difficult to make this portable in any sense of the word. In order for C++ to be a first-class citizen in CLI and to allow the other languages to work with these assemblies, such changes will need to be throughout the code-base, thus making projects less portable to other platforms, not to fail to mention some initial investment in exposing your API to non-C++ languages. Portability was obviously not one of their aims.

As a few groups that I was talking to at OOPSLA regarding the gcnew changes said, when in Rome, do as the Romans. If you were targeting a .NET application, why would you really want to use C++ in it? Yes, there are some things that C++ can presently do that C# and other languages are not as well suited to do or that you have an investment in current C++ libraries, but developing full applications in C++ would not seem to be a natural fit. This is a similar synopsis that JavaWorld gave to J# a while ago.

I realize that Microsoft is attempting to target C++ for Systems Development, but C++ is already a very confusing language, and adding more confusion to it is not necessary. The effort to migrate all Java applications onto .NET and vice versa was not always a good decision, and the first article mentioned discusses how we can actually bridge the two technologies together. Bridging C++ into the .NET world would have had a vastly different feel than the present Visual Studio 2005 line-up, and as strange as Managed C++ was, at least it was mostly standard C++.