What is the point of fully qualified class names?

I have a third party SDK in C# which has class names like this:

com.companyname.productclass.enterprise.productname.sdkname.namespace
com.companyname.productclass.enterprise.productname.sdkname.namespace.objects
开发者_高级运维com.companyname.productclass.enterprise.productname.sdkname.namespace.objects.fields
com.companyname.productclass.enterprise.productname.sdkname.namespace.objects.fields.data
com.companyname.productclass.enterprise.productname.sdkname.namespace.security

... and so on.

Is there some point to this that I'm missing? Or is just a matter of coding style?

The SDK is rather more verbose than seems necessary in several ways, resulting in multi-thousand line .cs files, so I'm willing to accept the person(s) that wrote it have a different coding style to what I'm used to (or were being paid per byte :D )

The point is to avoid naming conflicts. For example, if I created a class library with an "objects" namespace as in

com.davidstratton.productclass.enerprise.productname.sdkname.objects

it could exists side-by-side with the other classes.

It may seem like overkill, but keep in mind the days of "dll hell" that plagued development in pre .Net days. To companies could (and did) product classes with the same name, so that installing one application could break another application. One of the design goals of .Net was to avoid this.

The naming convention you are asking about is actually specified in the Class Design guidelines as documented here: http://msdn.microsoft.com/en-us/library/ms229048.aspx.

Edit - Added

My statement above is incorrect in saying that this is in the "official guidelines". I'm not sure where I saw the "com.companyname.blah.foo.bar" naming recommendation, but it's not in the current definition or older definitions that I can find. I must have imagined reading it somewhere.

So I officially agree with everyone who said it's overkill.

Overly verbose. It wouldn't surprise me if somehow this SDK was a port of a Java codebase or has been mainly written by Java developers.

The namespace convention is definitely not in line with general best practices and Microsoft recommendations.

See: Namespace Naming Guidelines

That looks over the top, but you should always include a namespace so that isn't going to conflict with other ones (e.g. based on the company's domain) - this is especially important with an SDK as I guess the intention is that it will be used in a wide variety of contexts.

If you don't then you'll end up potentially regretting it eventually and have a refactoring job ahead to fix it. Using statements at the top of files isn't a big burden really.

You should read the post (also on stackoverflow) about the clever programmer who created a global variable named, "int." That'll answer this question in a hurry!

It's to prevent class naming conflicts, which can occur frequently when you're using multiple libraries in your project.

A good example within the .NET framework itself: there is an Image class in the System.Web.UI.WebControls namespace, and an Image class in the System.Drawing namespace. Without namespaces, these classes would conflict with one another.