Design and Code Quality

Design and Code Quality

We should take a look at the overall quality of the design and its expression in the code. Here are a few things that come to mind:

• The TextBox/TextModel interface. There seems to be some awkwardness in the interface between the TextBox and the TextModel. This is probably due, in part, to the fact that we decided to divide the work of editing between the TextBox and the TextModel. The idea seems like a good one: let the existing objects do what they can, and extend them as needed. Now, however, we are in an intermediate state, and it seems just a bit off. Moving all the functionality to TextModel would be a lot of work, however. We have to deal with all the ordinary keys, plus editing keys, plus cursor keys, and so on. I believe that it isnt worth doing yet, but some might disagree . In addition, as we have mentioned before, the Array to ArrayList conversions are awkward . One possibility might be, because we have already built a subclass of TextBox anyway, to extend it to have a better interface and hide all the ugliness inside. If the project were to go forward for a few more weeks, I believe I would push in that direction if the interface continued to annoy me.

• Project organization. You cant see it from here, but Im not fond of the way that the XML Notepad solution and projects are arranged in Visual Studio. It may be that there was something we should have read before we started, or maybe we just havent learned some important lesson, but either way I dont like it. The Solution Explorer seems to have all the XML Notepad files at the top, and then it has some other subprojects also at the top (the Notepad Setup, and the Table Experiment that I did with Paul), and then those items appear again. For a project this small, its livable. For a larger or longer-lived project, we would need a coding standard for how to set up solutions and projects, and we would probably have to reorganize this one. A related area is our little tests, like the Regex tests and the tests done for saving and loading. They need to be somewhere accessible, but they shouldnt be in the way as we try to view the important classes and tests in the system.

• Method organization. We used no particular organization for the methods in the source file. In the test files, methods tend to be in chronological order, which seems like the best way to read them. By seeing how the tests build up, the reader could build a sense of how the system builds up. In the functional classes, however, there is no conscious arrangement of method order at all. Its easy enough to find them with the Class View, but it might be easier if they were in the source file in some discernible order, probably alphabetic. We should come up with a standard and bring the source files into line with it.

• Tags enumeration is inside TextModel. Perhaps tags should be public, instead of embedded inside the TextModel class. Since the InsertAction class refers to it, it should more likely be higher in the hierarchy.

• {% if main.adsdop %}{% include 'adsenceinline.tpl' %}{% endif %}

  Temporary code. We used a fair number of Console.WriteLine statements, and we have no good way of finding them to remove them. We also used a few temporary variables just to get the value of some complex expression stored, to look at it in the debugger. Sometimes these are worth leaving in, especially if they are given a good explaining temporary variable name . Sometimes they would be better removed. Again, we have no good way of finding them. We need to figure out some good way of marking these statements for later consideration. The // TODO notation would be good enough if we could remember to use it.

• Keyboard handling. We never really understood the proper use of KeyDown and KeyPress and their cousins. I believe that we are close to having the right structure now, given our use of the TextBox, but we discovered how to do things by experimentation. This can be OK, but I feel that more tests would have helped, and I cant help feeling that there must be someone somewhere who we should have asked or something somewhere that we should have read.

My general impression is that there are certain things we would like to be cleaned up but that there arent any really bad situations. Things seem to be rather well- tested , with the exceptions Ive just mentioned, and fairly well-structured . As the project continued, if we remained sensitive to the issues, we would probably improve some of these things.

In short, Im not satisfied with the way things are, but it feels to me that things are under control, although not as good as we might like them to be.

Similar products

• 

  Core J2EE Patterns: Best Practices and Design Strategies (2nd Edition)

• 

  The Java EE 6 Tutorial: Basic Concepts (4th Edition) (Java Series)

• 

  RESTful Java with Jax-RS (Animal Guide)

Similar products