Distractions: Been There, Done That

Just coming from the mainframe over to the Windows and Web development platform, you have possibly faced adversity. It is likely that you have encountered pessimists and naysayers on both sides (mainframe and Windows/Web) of the fence.

While licking your wounds, you have tried to avoid those who seemed to have personal vendettas against anything that looked , felt, or acted like a mainframe. All along, you simply sought to broaden your skill set and build upon your respectable COBOL CICS mainframe programmer foundation. You worked hard to learn .NET and Windows and Web development. The last thing that you need is to let a distraction throw you off track.

While on the mainframe, maybe you had your share of COBOL language versus assembler language debates. But that s behind you now, right? Are these opportunities for distraction all behind you now? After all, you have survived the journey into the world of .NET Windows and Web development. Unfortunately, they are not. Let s take a look at a few of them now. It will serve you well to be familiar with those few distractions that are the most common.

Compiler Differences

In this book, I ve advocated being bilingual ” learning both Visual Basic .NET (VB .NET) and COBOL .NET. Other than the fact that programming is fun and using multiple languages is even more fun, being bilingual is a wise career choice. If using two .NET languages were not enough, as Appendix B showed you can even go on to include C# and J# as additional .NET language choices. The more the merrier.

Tip  

Be aware that there is a faction of the Visual Basic community that is strongly defending the choice to code in VB .NET instead of in C#. At the same time, portions of the C++, J++, and Java developer communities are rallying behind C# as "the" .NET language of choice. As you broaden your skill set by picking up a second .NET language (to add to your COBOL coding skills), be aware of this heated battle going on between some portions of the developer community.

I believe that having flexibility in your language choice will simply open new doors for you while keeping many existing doors open . Additionally, your developing technique in each programming language typically improves as you learn other techniques common in different languages.

In the safe confines of this book, a language-neutral approach has been very easy to take. I ve enjoyed the freedom of being able to focus on your retraining needs. Rather than getting into personal issues and attempting to sway you to or from one language or another, I concentrated on .NET and related development concerns. In the end, the language you happen to develop with doesn t have to be a black-and-white, either-or type of choice. At least that s how I see it.

Tip  

Be sure to familiarize yourself with how some .NET languages will use either a zero-based index or a one-based index for arrays and/or collections. Some developers tend to take this particular issue very personally . Be prepared.

Unfortunately, the rest of the world is not so kind, not so liberal . In the real world, there are those who frown on developers who freely switch from one devel opment language to the other. There are those who will even go so far as to mention disloyalty, betrayal, and treason when describing a developer who is open to trying new languages, new compilers, and so forth.

Therefore, simply be prepared to discuss why you choose to code in one spe cific .NET language or a combination of .NET languages. I like having those types of discussions. I have found that when you can openly discuss the pros and cons of one language or another, you have a readily available disarming tactic.

Tip  

Spend some time looking into how each .NET language represents the Boolean true value. Specifically , check to see if true is represented as “1 (negative 1) or +1 (positive 1), or if the language syntax advocates using the string literal true to set a Boolean type operator. This issue is a hot button for some developers.

On the note of disarming tactics, try this one on for size . Let s say that you see two professional developers in heated battle over language compiler differences: verboseness versus terseness . Perhaps they are wrestling over the fact that both the COBOL and Visual Basic languages lean more toward being verbose. C#, J#, and C++, on the other hand, are generally referred to as being terse. As the two profes sional developers finish their wrestling competition and proceed to challenge each other in a friendly tug-of-war match, kindly interrupt them. Suggest to them that they are both wrong.

Ask them if they have coded any .NET applications using regular expressions. Tell them that they should spend some time exploring the use of the .NET Framework namespace System.Text.RegularExpressions (specifically, the Regex , Match , and Group classes) . Proudly inform them that the syntax of regular expres sions, hands down, exemplifies the essence of terseness ”real terseness. Mention to the two dumbfounded professional developers that all .NET languages are verbose when compared with the language syntax of regular expressions.

Further, mention that all .NET languages can take advantage of the language syntax of regular expressions through the System.Text.RegularExpressions namespace. Ask these two professional developers the following question: "If all .NET languages can leverage the ultimately terse syntax of regular expressions, why not put to rest the whole verbose versus terse debate?"

Hopefully, this will be enough of an interruption to interject the thought that the terseness of a language is relative and ultimately less important than simply getting the job done. If this tactic does not work, perhaps the two professional developers can just return to their "my language is more terse than your language" debate.

Vendor and Platform Competition

It is not a secret that some companies and corporations do not get along that well with Microsoft. If you were to make a list of these companies, Sun Microsystems and IBM might be good candidates for this short list. Why Sun Microsystems and IBM?

The latest strategy in winning the developer platform war is winning the hearts and souls of developers. Sun Microsystems and IBM, along with Microsoft, are working hard to capture the attention and resulting loyalty of major portions of the developer community.

In Chapter 1, I presented to you a summary of the recent COBOL-related activities of several companies. If you look beyond COBOL, you will find other pieces of this "competition puzzle" coming together. Both Sun Microsystems and IBM are developing their own developer platforms. For the most part, their devel opment platforms will have the opportunity to compete with Microsoft s .NET platform. That s business, right?

The problem is that you will come across individual developers who have taken it up as their own personal mission to side with one vendor or another. Effectively, some developers enlist to join the war against (or with) Microsoft. In these cases, you will come across rather heated conversations in which Microsoft s .NET technologies are pitted against both Sun s J2EE product family and IBM s WebSphere product suite. And I do mean heated conversations.

Tip  

IBM s announcement regarding their purchase of Rational Software Corporation will certainly heat up the "company versus company" and "developer platform versus developer platform" conversations (see http://www.ibm.com/news/us/2002/12/061.html ).

More recently, the developer community has loosely referred to these heated conversations as a holy war. Unfortunately, some developers take this whole "business competition" thing personally. You would almost think that they actually owned one of these companies.

On the note of company ownership, consider this little experiment. The next time you come across someone who claims to "hate" Microsoft, ask that person if he or she happens to be one of the many who chooses to invest 401(k) retirement funds into Microsoft stock (either directly or through a mutual fund). More often than not, the answer you receive may surprise you.

How can you recognize those developers among us who spend way too much energy worrying about these sorts of things? If you come across someone proudly pointing out that Microsoft s C# is just a Java rip-off and that .NET s CLR is a Java Virtual Machine wanna-be, you have found your person. It s true that Microsoft s products resemble other products, other predecessors. But who cares, really?

Tip  

You will notice that JavaScript is not mentioned in most of Microsoft s documentation. Microsoft s documentation clearly explains how to use JScript or VBScript as a scripting language choice. At the same time, if you happen to look at any documentation sponsored by Netscape or Sun Microsystems, JavaScript is typically the only scripting language discussed. Realize that this has a lot to do with vendor and platform competition and less to do with which scripting language might be the best language to get the job done.

Just consider this a heads-up. If you do not want to waste valuable devel opment time debating about the ethics of business competition, simply avoid getting into these types of "Microsoft versus the world" conversations. Let Microsoft s competitors worry about competing with Microsoft. As a developer, consider simply learning and using the toolset that makes you marketable and keeps you employed.

Coding Style: Casing

Working with COBOL .NET, you have certainly come across occasions where proper casing was important. You have also discovered that VB .NET (and even C#) handles the issue of casing differently. Each compiler enforces casing syntax rules that eventually encourage formal coding styles and standards. For example, you will come across the terms "Pascal" and "Camel," as in Pascal casing and Camel casing.

Pascal casing, in which the first letter of each word is capitalized, is a coding style preferred by some. You will notice that Microsoft uses the Pascal casing con vention when naming namespaces (e.g., System.Web.Services, System.Text.RegularExpressions, and so on).

Camel casing, in which the first letter of each word except the first word is cap italized, is also a popular convention. Microsoft s documentation suggests that this coding style is useful when naming variables .

The question is, should you follow Microsoft s conventions and suggestions or create your own coding style? This is where the controversy lies. Why? What you think and want personally may not be what your neighbor or your coworker thinks and wants. This is yet another opportunity for distraction ”another opportunity for developers to lose focus on the spirit of the law while debating about the letter of the law .

I believe there isn t a right or wrong answer to picking a casing convention. Which way you go should depend on the agreed coding standard of your entire development team and your organization. If your team can t agree on a casing convention, you have a management issue, not a coding style issue. In the end, what s important is that your coding style is consistent with the coding style of your coworkers. This makes for more maintainable code.

Coding Style: Notation

The topic of notation as a coding style is another opportunity for disagreement . One of the most popular forms of notation is Hungarian notation. Some love it and swear by it. Others think it is a total waste of time and keystrokes.

For those who may not know, Hungarian notation is a coding style that sug gests adding a small prefix in front of variable names to indicate the data type of the variable. For example, strDescription identifies a string data type. Likewise, intCounter identifies an integer data type. Dr. Charles Simonyi (who happens to be from Hungary), a Microsoft employee, is credited with creating this notation style, which some thought looked more like non-English words or, rather, more like Hungarian words.

As with any other coding style, Hungarian notation is used by some, but not everyone. If you really enjoy debating and arguing, try this little experiment. First, find someone who feels very strongly about using Hungarian notation. Next, ask this person to explain to you the premise of Hungarian notation.Then, suggest to this Hungarian notation advocate that you are going to start naming all of your .NET variables using the prefix "obj" (i.e., objDescription, objCounter, and so forth). Mention that because all .NET classes ultimately inherit from System.Object, it s clear to you that "obj" will accurately identify all of your .NET variables.

Naturally, you might not want to try this experiment with your manager or supervisor. However, it will prove to be a good conversation opener . If you can turn this debate into a productive conversation, you will be headed into the right direction. One point that you will want to explore is the need for a given team and the resulting modules that they work on to be in-sync. This will expedite the level of maintainability in your application. Having this value lost among those who would rather be right and have things their way is simply wasteful .

Coding Style: To GO TO, GoTo, goto or Not To

The coding style of using goto logic certainly ranks high on the list of potential landmines, sore spots, and potential arguable points. The mainframe developer community has debated about this coding style in both COBOL and assembler programs. Additionally, the Visual Basic developer community has weighed in on this contentious and controversial coding style.

As you have learned about .NET features, it is likely that you have learned that structured Try/Catch exception handling is hyped as being worlds better than the older, more traditional goto error-handling logic. Even on the mainframe, recall that the use of inline PERFORM statements was suggested as a way to help put an end to goto-style logic. All in all, the use of a goto coding style is often said to encourage the creation of spaghetti code, or code that is difficult to maintain.

Now it s time to ruffle a few feathers. Consider the following questions:

• Why did Microsoft decide to support the goto statement in the C# language?

• Why did Microsoft decide to support the goto switch-case in the C# switch statement?

• Why did Microsoft decide to include the .NET Framework class System.CodeDom.CodeGotoStatement ?

• Why did Microsoft decide to support both structured exception handling and the legacy coding style of On Error GoTo in VB .NET?

• Why did Fujitsu decide to provide support for the GO TO statement in their NetCOBOL for .NET compiler?

Of course, I have my own answers to these questions. Maybe you have your answers as well. One explanation, perhaps one that you and I may agree on, is that there is the need to provide support that is backward compatible. However, this argument only goes so far. Consider the following possibilities:

• VB .NET represented a housecleaning opportunity for Microsoft ”a chance to "clean up" the Visual Basic language.

• C# is a new language. Because C# is a new language, what would a C# application be backward compatible with?

It appears to me that Microsoft (and Fujitsu) recognizes that not everyone agrees on whether or not goto logic is forbidden. So, to be somewhat neutral, the feature is supported. Hence, my point: You too should realize that not everyone agrees that goto logic is evil and bad. Although there may be some objective- sounding reasons against using goto logic, some will still argue in favor of using goto logic.

As you engage in these heated debates, defending your honor and your turf, remember that you and I and the guy next door all have a job to do. Of course, that is what matters. In the end, I suppose that this is just one more reason why being a developer is one of life s greatest pleasures ”a treat indeed.