puppy, whatever be your goal,
Keep your eye on the donut, and not the hole."
I admit, in my
Through the years, I have interpreted and reinterpreted that piece of advice. My latest interpretation
The first portion of this appendix covers a few compiler differences that some developers tend to care a lot about. From there, you will
Just coming from the mainframe over to the Windows and Web development platform, you have possibly faced adversity. It is likely that you have
While licking your wounds, you have tried to avoid those who seemed to have personal vendettas against anything that
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.
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.
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
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
Be sure to familiarize yourself with how some .NET languages will use either a
Unfortunately, the rest of the world is not so kind, not so
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.
On the note of disarming tactics, try this one on for
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
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.
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
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
IBM s announcement regarding their purchase of Rational Software Corporation will
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
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?
Just consider this a heads-up. If you do not want to waste
Working with COBOL .NET, you have certainly come across occasions where proper casing was important. You have also
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).
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
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
The topic of notation as a coding style is another opportunity for
For those who may not know,
is a coding style that sug gests adding a small prefix in front of variable
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
Naturally, you might not want to try this experiment with your manager or supervisor. However, it will
The coding style of using
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
As you have learned about .NET features, it is likely that you have learned that structured Try/Catch exception handling is hyped as being
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