Skip to main content
Software Engineering

Return to Answer

Keeping my unique style
Source Link
Ewan
Ewan
  • 79.9k
  • 5
  • 83
  • 179

I did work at one company where they had many classes with the same name, but in different class libraries.

For example,

  • Domain.Customer
  • Legacy.Customer
  • ServiceX.Customer
  • ViewModel.Customer
  • Database.Customer

Bad design, you might say, but you know how these things develop organically, and what's the alternative - rename all the classes to include the namespace? Major refactoring of everything?

In any case, there were several places where projects which referenced all these different libraries needed to use multiple versions of the class.

With the using directly at the top, this was a major pain in the arse, ReSharper would do odd things to try and make it work, rewriting the using directives on the fly, you would get Customer-can't-be-cast-as-Customer-style errors and not know which type was the correct one.

So, having at least the partial namespace,

var cust = new Domain.Customer

or

public void Purchase(ViewModel.Customer customer)

greatly improved the readability of the code and made it explicit which object you wanted.

It wasn't a coding standard, it wasn't the full namespace, and it wasn't applied to all classes as standard.

I did work at one company where they had many classes with the same name, but in different class libraries.

For example,

  • Domain.Customer
  • Legacy.Customer
  • ServiceX.Customer
  • ViewModel.Customer
  • Database.Customer

Bad design, you might say, but you know how these things develop organically, and what's the alternative - rename all the classes to include the namespace? Major refactoring of everything?

In any case, there were several places where projects which referenced all these different libraries needed to use multiple versions of the class.

With the using directly at the top, this was a major pain, ReSharper would do odd things to try and make it work, rewriting the using directives on the fly, you would get Customer-can't-be-cast-as-Customer-style errors and not know which type was the correct one.

So, having at least the partial namespace,

var cust = new Domain.Customer

or

public void Purchase(ViewModel.Customer customer)

greatly improved the readability of the code and made it explicit which object you wanted.

It wasn't a coding standard, it wasn't the full namespace, and it wasn't applied to all classes as standard.

I did work at one company where they had many classes with the same name, but in different class libraries.

For example,

  • Domain.Customer
  • Legacy.Customer
  • ServiceX.Customer
  • ViewModel.Customer
  • Database.Customer

Bad design, you might say, but you know how these things develop organically, and what's the alternative - rename all the classes to include the namespace? Major refactoring of everything?

In any case, there were several places where projects which referenced all these different libraries needed to use multiple versions of the class.

With the using directly at the top, this was a major pain in the arse, ReSharper would do odd things to try and make it work, rewriting the using directives on the fly, you would get Customer-can't-be-cast-as-Customer-style errors and not know which type was the correct one.

So, having at least the partial namespace,

var cust = new Domain.Customer

or

public void Purchase(ViewModel.Customer customer)

greatly improved the readability of the code and made it explicit which object you wanted.

It wasn't a coding standard, it wasn't the full namespace, and it wasn't applied to all classes as standard.

Improve wording and grammar
Source Link
edit approved Oct 9, 2015 at 15:52
psmears
edit approved Oct 9, 2015 at 15:52
psmears
  • 194
  • 4

I did work at one company where they had many classes with the same name, but in different class libraryslibraries.

For example,

  • Domain.Customer
  • Legacy.Customer
  • ServiceX.Customer
  • ViewModel.Customer
  • Database.Customer

Bad design, you might say, but you know how these things develop organically, and what's the alternative, - rename all the classes to include the namespace? Major refactoring of everything?

In any case, there were several places where projects, which referenced all these different libraries needed to use multiple versions of the class.

With the using directly at the top, this was a major pain in the arse, ReSharper would do odd things to try and make it work, rewriting the using directives on the fly, you would get Customer-can't-be-cast-as-Customer-style errors and not know which type was the correct one.

So, having at least the partial namespace,

var cust = new Domain.Customer

or

public void Purchase(ViewModel.Customer customer)

greatly improved the readability of the code and made it explicit which object you wanted.

It wasn't a coding standard, it wasn't the full namespace, and it wasn't applied to all classes as standard.

I did work at one company where they had many classes with the same name, but in different class librarys.

For example,

  • Domain.Customer
  • Legacy.Customer
  • ServiceX.Customer
  • ViewModel.Customer
  • Database.Customer

Bad design you might say, but you know how these things develop organically, and what's the alternative, rename all the classes to include the namespace? Major refactoring of everything?

In any case, there were several places where projects, which referenced all these different libraries needed to use multiple versions of the class.

With the using directly at the top, this was a major pain in the arse, ReSharper would do odd things to try and make it work, rewriting the using directives on the fly, you would get Customer-can't-be-cast-as-Customer-style errors and not know which type was the correct one.

So, having at least the partial namespace,

var cust = new Domain.Customer

or

public void Purchase(ViewModel.Customer customer)

greatly improved the readability of the code and made it explicit which object you wanted.

It wasn't a coding standard, it wasn't the full namespace, and it wasn't applied to all classes as standard.

I did work at one company where they had many classes with the same name, but in different class libraries.

For example,

  • Domain.Customer
  • Legacy.Customer
  • ServiceX.Customer
  • ViewModel.Customer
  • Database.Customer

Bad design, you might say, but you know how these things develop organically, and what's the alternative - rename all the classes to include the namespace? Major refactoring of everything?

In any case, there were several places where projects which referenced all these different libraries needed to use multiple versions of the class.

With the using directly at the top, this was a major pain, ReSharper would do odd things to try and make it work, rewriting the using directives on the fly, you would get Customer-can't-be-cast-as-Customer-style errors and not know which type was the correct one.

So, having at least the partial namespace,

var cust = new Domain.Customer

or

public void Purchase(ViewModel.Customer customer)

greatly improved the readability of the code and made it explicit which object you wanted.

It wasn't a coding standard, it wasn't the full namespace, and it wasn't applied to all classes as standard.

Copy edited. Removed meta information (this can be put in comments). Added some context.
Source Link
edit approved Oct 8, 2015 at 17:58
Peter Mortensen
edit approved Oct 8, 2015 at 17:58
Peter Mortensen
  • 1k
  • 2
  • 12
  • 14

OK, gona take a run at this.

I did work at one company where they had many classes with the same name, but in different class libslibrarys.

eg.For example,

  • Domain.Customer
  • Legacy.Customer
  • ServiceX.Customer
  • ViewModel.Customer
  • Database.Customer

Bad design you might say, but you know how these things develop organically, and whatswhat's the alternative, rename all the classes to include the namespace? majorMajor refactoring of everything?

In any case, there were several places where projects, which referenced all these different libraries needed to use multiple versions of the class.

With the usingusing directly at the top, this was a major pain in the arse, resharperReSharper would do odd things to try and make it work, rewriting the usingusing directives on the fly, you would get Customer cant be cast as Customer style-can't-be-cast-as-Customer-style errors and not know which type was the correct one.

soSo, having at least the partial namespace,

var cust = new Domain.Customer

or

public void Purchase(ViewModel.Customer customer)

greatly improved the readability of the code and made it explicit which object you wanted.

It wasn't a coding standard  , it wasn't the full namespace, and it wasn't applied to all classes as standard.

OK, gona take a run at this.

I did work at one company where they had many classes with the same name but in different class libs.

eg.

  • Domain.Customer
  • Legacy.Customer
  • ServiceX.Customer
  • ViewModel.Customer
  • Database.Customer

Bad design you might say, but you know how these things develop organically, and whats the alternative, rename all the classes to include the namespace? major refactoring of everything?

In any case, there were several places where projects, which referenced all these different libraries needed to use multiple versions of the class.

With the using directly at the top, this was a major pain in the arse, resharper would do odd things to try and make it work, rewriting the using directives on the fly, you would get Customer cant be cast as Customer style errors and not know which type was the correct one.

so, having at least the partial namespace,

var cust = new Domain.Customer

or

public void Purchase(ViewModel.Customer customer)

greatly improved the readability of the code and made it explicit which object you wanted.

It wasn't a coding standard  , it wasn't the full namespace and it wasn't applied to all classes as standard.

I did work at one company where they had many classes with the same name, but in different class librarys.

For example,

  • Domain.Customer
  • Legacy.Customer
  • ServiceX.Customer
  • ViewModel.Customer
  • Database.Customer

Bad design you might say, but you know how these things develop organically, and what's the alternative, rename all the classes to include the namespace? Major refactoring of everything?

In any case, there were several places where projects, which referenced all these different libraries needed to use multiple versions of the class.

With the using directly at the top, this was a major pain in the arse, ReSharper would do odd things to try and make it work, rewriting the using directives on the fly, you would get Customer-can't-be-cast-as-Customer-style errors and not know which type was the correct one.

So, having at least the partial namespace,

var cust = new Domain.Customer

or

public void Purchase(ViewModel.Customer customer)

greatly improved the readability of the code and made it explicit which object you wanted.

It wasn't a coding standard, it wasn't the full namespace, and it wasn't applied to all classes as standard.

Source Link
Ewan
Ewan
  • 79.9k
  • 5
  • 83
  • 179