Programming Rules

I read an article on the web by Rob Pike. He is an important guy in the UNIX/C world. I know I own at least one UNIX text authored by him. For some reason, I thought he was also one of the authors of the awk scripting language. However that does not seem to make sense as the letters in awk are supposed to represent the first letter of the last names of the three guys who invented the language.

It seems I digress. The article I read was entitled “Notes on Programming in C”. The funny thing is that many of the topics discussed by Pike are not specific to C. They can be applied to most programming languages. That is kind of like a Code Complete by McConnell. Let’s start with some of the C specific items as they are few. One is that you should not include another file within an include file itself. In other words, you should not nest include files. Another tip was that pointers are preferable to objects. I think that means pass pointers to objects instead of making copies of the objects themselves.

Now let’s move on to some of the guidance that can be applied whatever programming language you are working with. The first is the short variable names are often better. For instance, it is reasonable to use the variable i for a loop index variable. Next you should strive to eliminate comments. This may sound contrary to what you were taught when you first started programming. However the best code is clean, simple, and easy to understand on its own. It does not need to be littered with comments. This eases maintainability. You can also trust the code always. Comments that are wrong or misleading are harmful.

Finally let’s talk about procedures and functions. Procedure should be named according to what they actually do. That sounds simple. But you would be surprised how some procedures are named which have nothing to do with their function. Next you know that a function returns a value. You should name the function based on the type of value it returns. Any functions returning a BOOL should be in the form of a question. Examples of this are isOpen() and canDelete().

More Object Oriented

Some time back I went back over a textbook I had from my Object Oriented Analysis and Design class. The book was authored by Grady Booch. The title of the book was Object-Oriented Analysis and Design with Applications. I have covered some ideas from this book in previous blog posts. This time I want to finish up some topics I read in the book.

A very popular term within the OO world is polymorphism. This means one name with many implementations. In other words, you have multiple related classes with the same function name. Then depending on the object upon which you are calling the method, you will get the right implementation executed.

There is another scenario where you have the same function name, but multiple implementations. This is where you have multiple functions within the same class that have the same name. However they are differentiated by the number and/or types of parameters that are passed in to the function. The official name for this behavior is overloading.

Another key idea in OO is that of aggregation. This is a big word to say that one object has another object or item as part of it. A synonym for this idea is containment. There are some lesser used OO topics that Booch mentions. One of them is that of a meta class, where the instances of the class are classes themselves. That does not sound familiar from my experience.

Some techniques for performing object oriented analysis and design are use cases and CRC cards. I have only hear about but never participated in CRC card analysis. Apparently you get together in a room and write down things on physical cards. I have done a lot of use case work in the past. However these days we skip that during out analysis phase. So do our requirements people.

Finally I read up on parametrized classes. These are classes whose behavior depends on parameters passed to the class. In C++, this idea is implemented as templates. I do have a little experience with templates in general. However I believe I want to beef up that experience.

Object Oriented

Some time ago I reread an Object Oriented Analysis and Design book by Grady Booch. It brought back a lot of memories from my first college class on OOA. So I thought I would talk about some more main topics from this book.

As far as programming languages go, the two ends of the spectrum are static binding and late binding. Most languages may one or the other. However a language may fall between the two extremes. Static binding is where variable types are fixed at compile time. It is also called early binding.

Dynamic binding is where variable types are not all known at compile type. This is also known as late binding. Having just completed an introductory class on Java, I now know that Java is a language with dynamic binding.

Why do object oriented modeling anyway? In theory, it encourages reuse of design. It also allows you to build upon components which are already tested and known good. Furthermore, some of the object oriented outlook feels nature to people. Evangelists say that Object Oriented Programming gives you great power. I am not so sure about that claim.

Let’s wrap up by defining some important terms in OOA. State is the properties of objects, along with the current value of those properties. A class defines a common structure and behavior for objects. And cardinality refers to the numeric relationship between classes. For example, a car has four wheels.

Next time I will go into big topics such as polymorphism and aggregation. Again this all seems very relevant as I just learn Java, which is an object oriented language.

Universal Object Oriented Topics

I am a veteran C++ programmer. This year I decided to seriously take of the challenge of learning to program in Java. Now I am starting to see that many object oriented topics are universal. They are language independent. Yes this might be obvious to some. But given my long history with C++, I always seemed to think of the principles in terms of how C++ implements them. Here I will discuss some of these universal topics that I recalled by reading a book by Grady Booch.

An abstraction denotes the essential characteristics of an object. Encapsulation divides structure and behavior. It separates interfaces and implementation. This is all done through information hiding. Modularity refers to decomposes complexity into separate products.

Abstractions are related in a hierarchical manner. One example of this is multiple inheritance. You can receive behavior from more than one source. Another example is aggregation. This is a fancy way of stating that something contains something else.

Typing is enforcing a class on an object. It restricts and defines what the object can and can not do. It prevents a programmer from exchanging objects that have different types. This is a safety feature. Most of the time, if you try to assign something of the wrong type to something else, you have a bug.

Like I mentioned earlier, I am learning Java programming. Unfortunately we are learning the basics of the programming language. So we have not covered some of the deeper topics like inheritance. However a good thing about this is that we are taking it from the very top. So we are covering basic things such as encapsulation and abstraction.

Object Oriented

I had reread a book by Grady Booch and recalled some topics about object oriented analysis and design that I had learned a while ago. And I thought I would share and discuss some of these ideas here. The first topic is that of complex systems.

Complex systems have a number of shared traits. They have a lot of subsystems. There is often an arbitrary choice of components in the system. There are dependencies between these components. The subsystems are combined in different ways. They often have evolved from a simple working prototype system.

There are a number of approaches that can be taken to design complex systems. There is a top down structured design. There is also a data driven design approach. And finally there is the object oriented design approach. When we use the word object, we are referring to a tangible entity that has a well defined behavior.

Object oriented analysis is an examination of the requirements in terms of classes and objects. Object oriented design has multiple facets. There is an object oriented decomposition of the problem. There is notational symbols for both the logical and physical design models. And there is also notation for both static and dynamic models.

Likewise, object oriented programming has multiple parts to it. Programs are made up of cooperating objects. The objects themselves are instances of classes which are the blueprints. Classes are arranged in a hierarchical structure. The classes in the structure are related by a term called inheritance.

There is a lot more to object orientation that what I discussed here. This is merely a review if you are already somewhat familiar with object oriented analysis and design. Normally I would point newcomers to the actual text of Grady Booch himself. However given enough time, I might be able to start a number of articles here that teaches this in more detail.

Web Skills

The Nettuts blog had a recent post about the skills required for web developers. This comes at an apt time for me. Our system might be going to the web sometime soon. The problem is that I am not a web developer. I am a client server developer. Usually that means you find another job. However I love the current project I am working on. I have been working on it for a long time. And I would like to continue this. Therefore it might be time to start shoring up my web development skill set.

The first item needed for good web developers is knowing a popular framework. Yes I have seen all the hype about Ruby on Rails. I dismissed most of it as hype. The only frameworks I know are those for client server development. However the hot new frameworks like Django seem to be web based. Maybe I will give them some time.

The next item required for web devs is knowing how to create widgets. That also seems like a good idea. I got a little excited when there was much hoopla over Google Gadgets. However I thought it more of a marketing ploy than anything else. You build a Gadget and get people to visit your web site. Maybe there is more to it than this.

Another web dev area is content management systems. Due to my blogging interest, I would not mind learning Wordpress or Moveable Type. Right now I just am a Blogger user. However the time may be right to understand more of what goes on behind the scenes. Our company is getting into social networking. The time may be right.

There are a lot of other web dev skills that were listed in the blog. The only other one that seems of interest to me would be ecommerce. It would be nice to know how to implement a payment system on a web site. For this I would probably go with the Paypal solution as they are very popular.

So far I have obtained approval to attend a Java class at the local community college. The company is going to pay for me. However I can see myself taking a Javascript class next. I like to have a college class drive me to learn these web development topics. It will also give me a good chance to network with other web devs.

Power of Metrics

The author of the Software Maintenance blog has found that metrics are not all they are cracked up to be. Yes in general metrics can be beneficial. But that presupposes that you use them correctly. The team should also know about the metrics process and understand how they are computed.

Sure you could conduct metrics gathering and analysis in secret. What good would that do? You could be sure that you have some objective handle on how a software project is progressing. However you want the metrics to work for you.

The trick is to be able to share the information on metrics without causing developers to game the system. For example, if you are tracking the number of days to complete a trouble ticket, developers could try to minimize this to the detriment of the project. Developers might only work on the easy problems. Or they could rush to close out other problems without truly resolving the problem. You definitely don't want to do this. But you do want the knowledge of metrics collection to spur developers on to good deeds. This is a tough balance to strike. Perhaps I shall post some more thought on this later.