Ideas, Requests Etc.
Ideas, Requests Etc.
1
In the middle of the night, master coder Rupert Longdon got a phone call at his hotel in Sunnyvale, California. Longdon, who was an expert with modern symbols mostly found on computer keyboards and was in town to convert the local Java gurus to another development environment from way up North, was confused.
"Mr Longdon?"
"Speaking."
"Mr Longdon, this is the Sunnyvale Police. My name is Captain Faché."
"Yes?"
"Have you talked to any Java people recently?"
Strange. Maybe the Sunnyvale Police knows why nobody showed up at his presentation earlier?
"Yes. But there was nobody there."
"Mr Longdon, this is because tonight, under very strange circumstances, Java got killed. I'm sending a car over to pick you up. We need your help to solve this mystery."
2
Half an hour later, Rupert Longdon stood over the dead corpse of Java. It was surrounded by strange symbols carved in the floor, visible only to the trained eye. Who could have done this? Longdon wondered. As if he could read his guest's mind, Faché answered.
"Java did this to itself."
"Java committed suicide? Why?" Longdon couldn't believe it.
Faché pointed to the strange symbols surrounding Java's lifeless shell. Very bizarre indeed. On Java's left side were the following words and numbers:
8 5 0 13 3 1 2 1 21 ...
Bag, Sell It!
A Stud, Louis IV!
On Java's right side was simply written:
.NET
"Does all of this mean anything to you?" Faché wondered.
"Only that I've read about a similar case recently, during my vacation," Longdon responded. "But that is not relevant here."
3
Longdon studied the symbols carefully, made some calculations and was happy to give Captain Faché, who was getting anxious to crack the case quickly, an answer to the first riddle.
"NET can be read backwards, saying 'TEN'. This probably means that Java was attacked by ten maniacs, backwards. This would also explain the dot at the beginning of .NET, which would signify the end, when read back to front."
"Interesting hypothesis," Faché had to acknowledge. "What about the rest?"
"The rest was written by someone who knows more about math than Dan Brown, the mystery author."
"Oh? Why is that?" Faché wanted to know.
"Because the number 0 is included. This, my dear Captain, is the beginning of the Fibonacci sequence, including the zero."
"Mr Brown omitted the zero, is that what you're saying?"
"Indeed," Longdon replied. "And he forgot to mention that the Fibonacci sequence is endless -- it doesn't end at 21."
Faché had to admit that his guest had a point. Which was unfortunate, because Faché had hoped to frame him for Java's demise. He decided to give it another try anyway.
"What about the funny order of the numbers? Isn't the Fibonacci sequence in order?"
"That is right. It goes 0, 1, 1, 2, 3, 5, etc. Maybe Java was dyslexic, that would explain what we're seeing here."
"Mr Longdon," Faché replied calmly, "I can assure you that with assumptions like the ones you make, you're not going to make many friends in some communities that may read my report. What else can you tell me?"
The computer symbologist gave it some thought.
"Maybe the other lines are in the wrong order, too. Maybe 'Bag, Sell It' has to be changed somehow, mingled, mixed, repositioned, to point to the Java killer."
He didn't realize at the time how right he was. "Ti Less Gab" was not the answer, but Longdon was close.
4
"I think we have to look for the solution somewhere else," offered Sophie VB, the just-arrived cryptologist who invented the late-bound variant-type variable. "I mean, let's look at the rivals of Java. Who would be happy with Java's demise?"
Faché decided to have a go.
"Starbucks?"
"Close, but no cigar. Bag, Sell It is an anagram..."
"Of Bill Gates!" Longdon exclaimed. And indeed it was.
"Java points to Bill Gates as the reason it was dying?" Faché wondered. "It makes sense. What about the bottom line?"
"The bottom line is that .NET, certainly the new version, is becoming the development environment of choice for many programmers who used to code in Java," Sophie replied.
"No, I mean, the bottom line of the riddle?"
"The reason Java was dying when it wrote down the mysterious symbols?"
The three of them looked at the desperate cry for help that was carved in the floor next to Java's corpse.
A Stud, Louis IV!
What could it mean?
It's been a couple of months since Jelle Druyts organized the First Belgian Geek Dinner. I think it's time to come together again, this time in even greater numbers.
As venue, I propose the tavern/restaurant De Pelgrom, Pelgrimstraat 15, Antwerp (03-234 08 09). As for the date, I propose Tuesday, October 12. What do you guys think?
Update: Some people have requested that we move the date from Tuesday, October 12 to Friday, October 15. Please cast your votes...
Please leave me a message here or at roy.dictus@gmail.com so I can make reservations...
Very often, when I'm on projects, I get asked about how namespace hierarchies should be structured. There isn't much literature available about it. So here goes:
Just Be Consistent
Of course there are several approaches to structuring namespaces, and I think there is no "Single Right Choice" that fits all. So you'll have to choose between alternatives. That is no problem, as long as you're consistent. The choice of namespace hierarchy type is one that will probably have to apply to all your company's projects.
Here are a few proposals for namespace hierarchies, or Namespace Patterns if you will. Pick your favorite. It is assumed that you're writing a client/server application in these cases. For other types of applications, other patterns may apply.
Let me illustrate by an example. Let's assume that your application, called ApplicationX, consists of the following layers:
- Web UI + Windows UI Layer
- Service Layer (Façade)
- Business Layer
- Data Access + Service Agents Layer
Besides these layers, there are typed DataSets and other objects that are common across the layers, so you could say there is a "vertical layer", a Common block.
Then the basic namespaces could look like so (of course the idea is to use the pattern as a starting point, and then extend it with the needs of your own organization and your application(s)):
Pattern #1: Layer-First
The Layer-First namespace pattern structures its hierarchy based on layers. The pattern is as follows:
Company name.Application name.Layer.Subsystem.Class
Example
CompanyX.ApplicationX.
- Web
- UI: contains the Web UI elements
- Security: dealing with Web-based security
- Windows
- UI: contains Windows UI elements (WinForms forms and controls)
- Security: dealing with Windows client-based security
- Services: contains Windows Services (previously known as NT Services)
- Services
- Entity classes (web services or Remoted objects) for the Service/Façade layer (for example, Orders, Invoices, Personnel)
- Security: dealing with service-layer security (auth&auth of requests, matching roles etc.)
- Business
- Entity classes for the Business layer
- DataAccess
- Entity classes for the Data Access sublayer
- ServiceAgents
- Entity classes for the Service Agents sublayer
- Common: Classes in the Common block; i.e. that must be accessible to all layers (such as DataSets etc.)
- Data: Common DataSets, data transfer objects
So, there would be a Web page called CompanyX.ApplicationX.Web.UI.Default, and a Web service called CompanyX.ApplicationX.Services.Orders as well as a business class CompanyX.ApplicationX.Business.Orders and a data access class CompanyX.ApplicationX.DataAccess.Orders, for example.
The hierarchy above is a good pattern, or template, if you want to group classes by layer.
Pattern #2: Subsystem-First
The Subsystem-First namespace pattern structures its hierarchy based on subsystems. The pattern is as follows:
Company name.Application name.Subsystem.Layer.Class
Example
CompanyX.ApplicationX.
- Web
- UI: contains the Web UI elements
- Security: dealing with Web-based security
- Windows
- UI: contains Windows UI elements (WinForms forms and controls)
- Security: dealing with Windows client-based security
- Services: contains Windows Services (previously known as NT Services)
- Security: contains classes that implement security on the Service/Façade layer
- Entity Name (such as Orders, Invoices, Personnel)
- Service: entity class for the Service/Façade layer
- Business: entity class(es) for the Business layer
- DataAccess: entity class(es) for the Data Access sublayer
- ServiceAgents: entity class(es) for the Service Agents sublayer
- Common: Classes in the Common block
- Data: Common DataSets, data transfer objects
So using this pattern, you would have a Web page called CompanyX.ApplicationX.Web.UI.Default (that doesn't change), and a Web service called CompanyX.ApplicationX.Orders.Service as well as a business class CompanyX.ApplicationX.Orders.Business and a data access class CompanyX.ApplicationX.Orders.DataAccess, for instance, or even a class CompanyX.ApplicationX.Orders.DataAccess.SqlServer and another one called CompanyX.ApplicationX.Orders.DataAccess.Oracle.
What is important among both patterns is that there is a clear separation between the layers. It is a good practice to map the layer structure onto the namespace structure. I've seen namespace designs where the data access layer is hierarchically under the business layer, so there would be a data access class called CompanyX.ApplicationX.Business.Orders.DataAccess, for instance. This is clearly bad as it is a logical mix of layers. It's almost like pouring Coca-Cola on your fries. They're good together, but should't be mixed on your plate...
OK, so what about Exceptions and Interfaces?
Another common question is where to put Exceptions, and where to put Interfaces. Many companies adopt the practice of putting exceptions in a separate Exceptions namespace, and Interfaces in their own Interface namespace. I don't think this is necessary. I think it's best to put either just where they belong. For example, an Exception that gets thrown by classes in the Business layer should itself be in the CompanyX.ApplicationX.Business namespace. In the same line of thinking, an Interface for data access classes should be defined in the CompanyX.ApplicationX.DataAccess namespace. It is then defined where it is used, just like the exceptions. This is also the way the .Net Framework places Exceptions and Interfaces in its hierarchy. I usually find that a good guideline: what does the .Net Framework do?
However, there are cases where it is not so obvious as in these examples. You may have Interfaces defined in the Service/Façade layer that must also be used on a disconnected (smart) client. That client is deployed independently of the Service layer, and so it must get its own copy of the Interfaces that the Service layer offers.
Make it Public
In that case, what you could do is create a CompanyX.ApplicationX.Public namespace that contains all elements that must be shared by the UI and Service/Façade layers. All elements (Exceptions, Interfaces, data transfer objects even maybe, if they need to be deployed all the way to the UI) are referenced and deployed in UI and Service/Façade projects. Of course it is important then that there are little changes to the classes in this namespace, or at least that the UI and Service projects are kept in sync.
Application Blocks
When designing your namespaces, you may run into cases where your team is going to write code for your app, when in fact that code is very likely to be reused. Examples are Web controls, Helper classes etc. A good idea then is to define separate projects for this reusable code, and to create Application Blocks for them. You may have a set of Helper classes, for example, say FileHelper, DirectoryHelper and StreamHelper. You could create a library called the File Handling Application Block and put the classes in there. The Application Block would get its own project, be deployed on all developer workstations and be referenced by all projects that need it, just like the Microsoft Application Blocks.
Of course, the namespace hierarchy would reflect the reusability of the code. You can tell that the CompanyX.ApplicationBlocks.FileHandling.FileHelper class isn't part of the CompanyX.ApplicationX project, and it keeps ApplicationX's namespace hierarchy cleaner.
What about Solution structure?
So, does all this namespace structuring affect how we structure Solutions? You better believe it.
I think a Visual Studio.Net Solution should mimic the namespace hierarchy as much as possible. So, if at all doable, I think there should be one project per namespace, that gets the name of that namespace. So CompanyX.ApplicationX.Web.UI.WebControls is a project name and a namespace name, for example. Pages in CompanyX.ApplicationX.Web.UI.Pages can be found in another project. And if you're looking for code in the CompanyX.ApplicationX.DataAccess namespace, you know in which project to look.
Project names and file system hierarchy
I guess the next question is then how to name project folders. Should the Orders data access class be found in the CompanyX.ApplicationX.DataAccess\bin folder or in ApplicationX\DataAccess\bin, or somewhere else?
I guess it doesn't matter much, as long as you're consistent. I prefer the first approach; it lists all your projects nicely in your Solution, and you don't have to dig three levels deep to find the implementation of a data access class. But that's a matter of personal preference, I guess. Maybe you have a different view on things, and for good reason--if so, please let's hear them!
Feedback is always welcome! You can leave your comments right here.
Recently, someone asked me, "What is your view on Exceptions? Should we or should we not use Exceptions to steer logic flow, and why (not) ?"
My view is that Exceptions are errors. They're the same thing. In my view, an Exception is something that never occurs in a perfect world (i.e. with perfect software running on perfect hardware). In the non-perfect world, a hard disk may fail to write (causing an Exception in the software that is trying to save a file), and software may be buggy because its assumptions are wrong (trying to read from a file that isn't there also causes an Exception). But when, in a soccer game, a player scores a goal, in my view that is not an Exception. Even if such moments are rare or, ahem, exceptional.
Using Exceptions for logic flow == bad
Again, in my view, it is bad to use Exceptions for anything other than managing errors. Code that expects an exception is bad (unless it is unit-testing code). Take the following example (pseudocode-ish):
try {
myFile = File.OpenText(fileName);
} catch (Exception e) {
myFile = File.CreateText(fileName);
}
...
I think this is horrible code. This is the hand of a lazy programmer. Try to open a file, and if you get an error, create the file. The following is much better:
if (!File.Exists(fileName)) {
myFile = File.CreateText(fileName);
} else {
myFile = File.OpenText(fileName);
}
...
This code is robust: it verifies its assumptions, and if they aren't met, takes appropriate action. Here, if an Exception occurs, it is unexpected.
Exception management is expensive, in the sense that takes more CPU cycles than being proactive as in the example above. I've measured performance differences between implementations that did and did not rely on Exception handling for logic flow, and the ones that did not performed better. That's another reason, although not a silver-bullet one, to view Exceptions strictly as errors.
What's the scientific point of view?
Now, I've spent some time trying to find the "scientific" point of view regarding this matter, but couldn't come up with anything solid in an acceptable timeframe. Is my view on things shared by the academic O-O world or not? What about you?
Maybe I should ask this directly to Eric Gunnerson or other guys from Redmond, but here goes:
I would like the .Net language compilers to support given coding standards, and refuse to compile code that doesn't meet them.
Update: make that "I would like the MSBuild system to support given coding standards, and refuse to build solutions that don't meet them." Makes a lot more sense... Thanks to Scott Galloway for remarking that.
One example is a maximum Cyclomatic Complexity for methods. Cyclomatic Complexity, also called McCabe Complexity or McCabe's Metric, is a software metric that computes the complexity of a function. In short, it equals 1 + the number of branches (ifs, whiles, foreaches etc.). A CC of more than 20 is considered too complex; so if a method has a CC of more than 20, it should be refactored.
Wouldn't it be cool if MSBuild would refuse to compile methods that exceeded a given (configurable?) complexity? This would mean developers wouldn't even be allowed to check in code that is too complex. Of course, you should be able to turn this off, so that you'd still be able to work in "Quick & Dirty" mode for a while. But once it's decided that all code must meet given minimum standards, why not let the development environment enforce them?
Another example: the compilers could refuse to compile classes that contain only static (Shared) methods and (a) constructor(s). This type of code is a violation of good coding behavior, so the developer would either have to remove the constructor(s) or make (some) methods un-static, so to speak. (As Marc Sigrist remarked, the example is badly chosen because its situation may actually be what the author wants (if the constructor is private). Thanks Marc!)
What do you guys think?
As much as I love the MSDN Library, and as much as I am very much impressed with Microsoft's efforts to provide us architects and developers with as much support as they can -- much more than any other development tools vendor --, I have some issues with the MSDN Library and the SDKs that Microsoft provides.
Don't get me wrong, I don't hate Microsoft--hey, I used to work for the company and I still love it. So don't bash me for bashing Microsoft. At least not today.
I just think Microsoft, as a provider of the platform, the tools and much of the technical resources that go with them, has a responsibility to teach the architects and developers who work on their platform how to do it right. And, even with all the richness that's in MSDN, in some areas they fall short of that. Many code samples in the Library and the SDKs use, well, Worst Practices.
A couple of examples to illustrate:
- ASP.NET Pages that access the database directly. This is a very bad example, while at the same time the company (and especially its consulting division, Microsoft Consulting Services) is trying to evangelize N-Tier Design;
- VB6 code in VB.NET Samples. No, we shouldn't be using CInt() and Left$ anymore, thank you, they are not O-O but imperative functions. I understand that Microsoft provided these methods into the Microsoft.VisualBasic namespace so that VB6 developers wouldn't feel left out, but the reality of it is that developers who used to work in VB6 continue to use their old habits, even if .Net is a totally different environment. But how are VB.NET developers supposed to know they need to use Convert.ToInt32() and string.Substring() instead if their VB6 counterparts are found in so many examples? Especially if the documentation encourages old-style VB6?
- .Net Naming Conventions as described in the .Net Framework Design Guidelines and enforced by FxCop: these rules are violated by MSDN Library code examples almost everywhere. There are namespaces with underscores in their names, identifiers with 3 or more capitals in a row or--can you believe it?--Hungarian notation and "m" prefixes for member variables;
- Use of public fields rather than properties. This goes hand-in-hand with the violation of naming conventions and the fact that "property" values cannot be validated and are thus always assumed right;
- The Exception constructor documentation gives an example of how to implement custom exceptions--but they derive from System.Exception rather than the recommended ApplicationException or even the base exception found in the Exception Management Application Block.
I think the issue is, basically, that MSDN doesn't enforce coding conventions or even naming conventions in their examples. This is strange because these are the lowest-hanging fruit in the Best Practices Tree and MSDN, by its very nature, should lead by example (right...?)
So, a request for the MSDN Team and the team program managers responsible for the SDKs: please, please, pretty please, can you create a set of coding conventions and stick to them, as well as to the "standard" Fx naming conventions? Can you please make these public and make sure that all contributors to MSDN, worldwide, stick to them? Please use your influence not just to get more architects and developers onto the platform, but also to make them create better, more robust, more maintainable applications.
Many thanks in advance!!
Man, I can't tell you how good it feels to finally get that off my chest!
Here's an idea for Microsoft's Visual Studio.Net Editor team, or for the guys doing SharpDevelop or other IDEs...
What about having a code editor with code visibility modes? For example, Full Mode, Debug Mode and Release Mode.
When editing in Debug mode, stuff like Debug.Assert statements and #if DEBUG... #endif code would be visible; when editing in Release mode, they would not (but #if RELEASE...#endif etc. would). When editing in Full Mode, everything would be visible.
This way, developers can switch off display of Debug stuff when they really need to focus on algorithms and other implementation details, without being bothered by ugly-looking Debug code.
What do you think?