A questão mais ampla:
Você já ouviu falar desse padrão sendo imposto? Se sim, qual foi o motivo por trás disso?
Sim, ouvi falar disso e o uso de nomes de objetos totalmente qualificados evita colisões de nomes. Embora raro, quando eles acontecem, eles podem ser excepcionalmente espinhosos para descobrir.
Um exemplo:
esse tipo de cenário provavelmente é melhor explicado com um exemplo.
Digamos que temos dois Lists<T>pertencentes a dois projetos separados.
System.Collections.Generic.List<T>
MyCorp.CustomCollections.Optimized.List<T>
Quando usamos o nome completo do objeto, fica claro qual List<T>está sendo usado. Essa clareza obviamente vem à custa da verbosidade.
E você pode estar argumentando: "Espere! Ninguém jamais usaria duas listas como essa!" É aí que vou apontar o cenário de manutenção.
Você é um módulo escrito Foopara sua empresa que usa a empresa aprovada, otimizada List<T>.
using MyCorp.CustomCollections.Optimized;
public class Foo {
List<object> myList = ...;
}
Mais tarde, um novo desenvolvedor decide estender o trabalho que você está fazendo. Sem conhecer os padrões da empresa, eles atualizam o usingbloco:
using MyCorp.CustomCollections.Optimized;
using System.Collections.Generic;
E você pode ver como as coisas correm mal com pressa.
Deve ser trivial ressaltar que você pode ter duas classes proprietárias com o mesmo nome, mas em espaços para nome diferentes no mesmo projeto. Portanto, não é apenas uma preocupação em colidir com as classes fornecidas pela estrutura .NET.
MyCorp.WeightsAndLengths.Measurement();
MyCorp.TimeAndSpace.Measurement();
A realidade:
Agora, é provável que isso ocorra na maioria dos projetos? Não, na verdade não. Mas quando você está trabalhando em um projeto grande com muitas entradas, você faz o possível para minimizar as chances de as coisas explodirem em você.
Grandes projetos com várias equipes contribuintes são um tipo especial de fera no mundo das aplicações. As regras que parecem irracionais para outros projetos se tornam mais pertinentes devido aos fluxos de entrada do projeto e à probabilidade de que aqueles que contribuem não tenham lido as diretrizes do projeto.
Isso também pode ocorrer quando dois projetos grandes são mesclados. Se os dois projetos tiverem classes com nomes semelhantes, você verá colisões quando começar a fazer referência de um projeto para o outro. E os projetos podem ser grandes demais para serem refatorados ou a gerência não aprovará a despesa para financiar o tempo gasto na refatoração.
Alternativas:
Embora você não tenha perguntado, vale ressaltar que essa não é uma ótima solução para o problema. Não é uma boa ideia criar classes que colidirão sem suas declarações de namespace.
List<T>, em particular, deve ser tratado como uma palavra reservada e não usado como o nome para suas classes.
Da mesma forma, os espaços para nome individuais no projeto devem se esforçar para ter nomes de classe exclusivos. Ter que tentar lembrar com que namespace Foo()você está trabalhando é uma sobrecarga mental que é melhor evitar. Disse de outra maneira: ter MyCorp.Bar.Foo()e MyCorp.Baz.Foo()vai enganar seus desenvolvedores e é melhor evitar.
Se nada mais, você pode usar espaços para nome parciais para resolver a ambiguidade. Por exemplo, se você absolutamente não puder renomear nenhuma das Foo()classes, poderá usar seus espaços de nomes parciais:
Bar.Foo()
Baz.Foo()
Razões específicas para o seu projeto atual:
Você atualizou sua pergunta com os motivos específicos que lhe foram dados para o seu projeto atual seguindo esse padrão. Vamos dar uma olhada neles e realmente desviar a trilha dos coelhos.
É complicado passar o mouse sobre o nome para obter o tipo totalmente qualificado. É melhor sempre ter o tipo totalmente qualificado visível o tempo todo.
"Pesado?" Hum, não. Irritante, talvez. Mover algumas onças de plástico para deslocar um ponteiro na tela não é complicado . Mas eu discordo.
Essa linha de raciocínio parece mais um encobrimento do que qualquer outra coisa. De antemão, eu acho que as classes no aplicativo têm nomes fracos e você precisa confiar no namespace para coletar a quantidade apropriada de informações semânticas em torno do nome da classe.
Essa não é uma justificativa válida para nomes de classe totalmente qualificados, talvez seja uma justificação válida para o uso de nomes de classe parcialmente qualificados.
Os trechos de código enviados por email não têm o nome completo e, portanto, podem ser difíceis de entender.
Essa linha de raciocínio (continuação?) Reforça minha suspeita de que as classes sejam atualmente mal nomeadas. Novamente, ter nomes de classes ruins não é uma boa justificativa para exigir que tudo use um nome de classe totalmente qualificado. Se o nome da classe é difícil de entender, há muito mais coisas erradas do que o que os nomes de classe totalmente qualificados podem corrigir.
Ao visualizar ou editar o código fora do Visual Studio (Notepad ++, por exemplo), é impossível obter o nome completo do tipo.
De todas as razões, essa quase me fez cuspir minha bebida. Mas, novamente, eu discordo.
Fico imaginando por que a equipe está frequentemente editando ou visualizando o código fora do Visual Studio? E agora estamos analisando uma justificativa bastante ortogonal ao que os namespaces devem fornecer. Esse é um argumento suportado por ferramentas, enquanto os espaços para nome existem para fornecer estrutura organizacional ao código.
Parece que o seu projeto sofre de más convenções de nomenclatura, além de desenvolvedores que não estão tirando proveito do que as ferramentas podem oferecer para eles. E, em vez de resolver esses problemas reais, eles tentaram dar um soco em um dos sintomas e estão exigindo nomes de classe totalmente qualificados. Eu acho que é seguro categorizar isso como uma abordagem equivocada.
Dado que há classes mal nomeadas e supondo que você não possa refatorar, a resposta correta é usar o IDE do Visual Studio para obter todas as vantagens. Possivelmente considere adicionar um plugin como o pacote VS PowerTools. Então, quando estou olhando, AtrociouslyNamedClass()posso clicar no nome da classe, pressionar F12 e ser levado diretamente para a definição da classe, a fim de entender melhor o que ela está tentando fazer. Da mesma forma, posso clicar em Shift-F12 para encontrar todos os pontos no código que atualmente sofrem com o uso AtrociouslyNamedClass().
Em relação às preocupações externas com ferramentas - a melhor coisa a fazer é parar com isso. Não envie trechos por e-mail se eles não estiverem imediatamente claros a que se referem. Não use outras ferramentas fora do Visual Studio, pois elas não possuem a inteligência que envolve o código de que sua equipe precisa. O Notepad ++ é uma ferramenta incrível, mas não é recortada para esta tarefa.
Por isso, concordo com a sua avaliação em relação às três justificativas específicas que lhe foram apresentadas. Dito isto, o que eu acho que lhe disseram foi "Temos problemas subjacentes neste projeto que não podem / não vão resolver e é assim que os 'consertamos'". E isso obviamente aborda questões mais profundas da equipe que podem servir de sinalizador vermelho para você.