Falhas de design C # (.NET) [fechado]

Quais são algumas das maiores falhas de design no C # ou no .NET Framework em geral?

Exemplo: não há tipo de string não anulável e você deve verificar se há DBNull ao buscar valores de um IDataReader.

Eu concordo enfaticamente com este post (para aqueles que reclamam da falta de ToString, existe um atributo de depurador para fornecer um formato personalizado para sua classe).

No topo da lista acima, eu também adicionaria as seguintes solicitações razoáveis:

1. tipos de referência não anuláveis ​​como um complemento aos tipos de valor anuláveis,
2. permitem substituir o construtor vazio de uma estrutura,
3. permitir restrições de tipo genérico para especificar classes seladas,
4. Concordo com outro postador aqui que solicitou assinaturas de construtor arbitrárias quando usadas como restrições, ou seja, onde T : new(string)ou ondeT : new(string, int)
5. Também concordo com outro postador aqui sobre a correção de eventos, tanto para listas de eventos vazios quanto na configuração simultânea (embora o último seja complicado),
6. operadores devem ser definidos como métodos de extensão, e não como métodos estáticos da classe (ou não apenas como métodos estáticos, pelo menos),
7. permite propriedades e métodos estáticos para interfaces (Java tem isso, mas C # não),
8. permitir a inicialização de eventos em inicializadores de objetos (apenas campos e propriedades são permitidos atualmente),
9. por que a sintaxe do "inicializador de objeto" só pode ser usada ao criar um objeto? Por que não torná-lo disponível a qualquer momento, ou seja.var e = new Foo(); e { Bar = baz };
10. corrigir o comportamento enumerável quadrático ,
11. todas as coleções devem ter instantâneos imutáveis ​​para iteração (ou seja, alterar a coleção não deve invalidar o iterador),
12. tuplas são fáceis de adicionar, mas um tipo algébrico fechado eficiente como " Either<T>" não é, então eu adoraria alguma maneira de declarar um tipo algébrico fechado e impor correspondência de padrão exaustiva nele (basicamente suporte de primeira classe para o padrão de visitante, mas muito mais eficiente); então apenas pegue enums, estenda-os com suporte exaustivo de correspondência de padrões e não permita casos inválidos,
13. Eu adoraria suporte para correspondência de padrões em geral, mas pelo menos para teste de tipo de objeto; Também gosto da sintaxe do switch proposta em outro post aqui,
14. Concordo com outro post que as System.IOaulas, tipo Stream, são um tanto mal elaboradas; qualquer interface que requer algumas implementações para lançar NotSupportedExceptioné um projeto ruim,
15. IListdeve ser muito mais simples do que é; na verdade, isso pode ser verdade para muitas das interfaces de coleção concretas, como ICollection,
16. muitos métodos lançam exceções, como IDictionary por exemplo,
17. Eu preferiria uma forma de exceções verificadas melhor do que aquela disponível em Java (veja a pesquisa sobre sistemas de tipo e efeito para saber como isso pode ser feito),
18. consertar vários casos incômodos na resolução de sobrecarga de método genérico; por exemplo, tente fornecer dois métodos de extensão sobrecarregados, um que opera em tipos de referência e o outro em tipos de struct anuláveis ​​e veja como sua inferência de tipo gosta disso,
19. fornecem uma maneira de refletir com segurança sobre os nomes dos campos e membros para interfaces como INotifyPropertyChanged, que usam o nome do campo como uma string; você pode fazer isso usando um método de extensão que pega um lambda com a MemberExpression, ie. () => Foo, mas isso não é muito eficiente,
    • Atualização: C # 6.0 adicionou o nameof()operador para nomes de membro único, mas não funciona em genéricos (em nameof(T) == "T"vez do nome do argumento de tipo real: você ainda precisa fazer typeof(T).Name)) - nem permite que você obtenha uma string de "caminho" , por exemplo, nameof(this.ComplexProperty.Value) == "Value"limitando suas possíveis aplicações.
20. permitir operadores em interfaces e implementar todos os tipos de número de núcleo IArithmetic; outras interfaces de operação compartilhadas úteis também são possíveis,
21. tornar mais difícil a mutação de campos / propriedades de objetos ou, pelo menos, permitir a anotação de campos imutáveis ​​e fazer o verificador de tipo aplicá-los (apenas trate-os como propriedade somente getter para chrissakes, não é difícil!); na verdade, unifique campos e propriedades de uma forma mais sensata, já que não adianta ter os dois; As propriedades automáticas do C # 3.0 são um primeiro passo nessa direção, mas não vão longe o suficiente,
    • Atualização: Enquanto C # tinha a readonlypalavra - chave, e C # 6.0 adicionou propriedades automáticas somente leitura, embora não seja tão rigoroso quanto o suporte de linguagem verdadeira para tipos e valores imutáveis.
22. simplificar a declaração de construtores; Eu gosto da abordagem do F #, mas o outro post aqui que requer simplesmente "novo" em vez do nome da classe é pelo menos melhor,

Suponho que seja o suficiente por enquanto. Essas são todas as irritações que encontrei na semana passada. Eu provavelmente poderia continuar por horas se eu realmente me concentrasse nisso. C # 4.0 já está adicionando argumentos nomeados, opcionais e padrão, que eu aprovo enfaticamente.

Agora, para um pedido irracional:

1. seria muito, muito bom se C # / CLR pudesse suportar polimorfismo de construtor de tipo, ou seja, genéricos sobre genéricos,

Por favor? :-)

• o Reset()método on IEnumerator<T>foi um erro (para blocos de iteradores, a especificação da linguagem exige até que isso lance uma exceção)
• os métodos de reflexão que retornam matrizes foram, na opinião de Eric, um erro
• covariância de matriz era e continua sendo uma raridade
  • Atualização: C # 4.0 com .NET 4.0 adicionado suporte covariante / contravariância para interfaces genéricas (como IEnumerable<out T>e Func<in T, out TResult>, mas não tipos concretos (como List<T>).
• ApplicationException em vez disso, caiu em desgraça - foi um erro?
• coleções sincronizadas - uma boa ideia, mas não necessariamente útil na realidade: você geralmente precisa sincronizar várias operações ( Containsentão Add), então uma coleção que sincroniza operações distintas não é tão útil
  • Update: Os System.Collections.Concurrenttipos , com TryAdd, GetOrAdd, TryRemove, etc foram adicionados no .NET Framework 4.0 - embora os métodos que aceitam um delegado fábrica não garantem a fábrica só será chamada uma vez por chave.
• mais uso poderia ter sido feito do padrão using/ lock- talvez permitindo que eles compartilhem uma sintaxe reutilizável (extensível?); você pode simular isso retornando IDisposablee usando using, mas poderia ter sido mais claro
• blocos iteradores: nenhuma maneira simples de verificar os argumentos antecipadamente (ao invés de preguiçosamente). Claro, você pode escrever dois métodos encadeados, mas isso é feio
• uma imutabilidade mais simples seria bom; C # 4.0 ajuda um pouco , mas não o suficiente
• não há suporte para "este parâmetro ref-type não pode ser nulo" - embora os contratos (em 4.0) ajudem de alguma forma. Mas sintaxe como Foo(SqlConnection! connection)(que injeta uma verificação de nulo / throw) seria bom (contraste com int?etc)
  • Atualização: Isso foi corrigido no C # 8.0 .
• falta de suporte de operadores e construtores não padrão com genéricos; C # 4.0 resolve isso um pouco com dynamic, ou você pode habilitá-lo assim
• a variável iteradora sendo declarada fora do while na foreachexpansão, o que significa que anon-methods / lambdas capturam a única variável, em vez de uma por iteração (doloroso com threading / async / etc)
  • Atualização: isso foi corrigido no C # 5.0 .

TextWriter é uma classe base de StreamWriter. wtf?

Isso sempre me confunde ao extremo.

Uma pequena petição de C # - construtores usam a sintaxe C ++ / Java de ter o construtor com o mesmo nome da classe.

New()ou ctor()teria sido muito melhor.

E, claro, ferramentas como o coderush tornam esse problema menor para renomear classes, mas de um POV de legibilidade, New () fornece grande clareza.

Eu não entendo que você não pode fazer

onde T: novo (U)

Portanto, você declara que o tipo genérico T tem um construtor não padrão.

editar:

Eu quero fazer isso:

public class A 
{
    public A(string text) 
    {

    }
}


public class Gen<T> where T : new(string text) 
{

}

Estou realmente surpreso por ser o primeiro a mencionar este:

Os conjuntos de dados do tipo ADO.NET não expõem colunas anuláveis ​​como propriedades de tipos anuláveis. Você deve ser capaz de escrever isto:

int? i = myRec.Field;
myRec.Field = null;

Em vez disso, você tem que escrever isso, o que é simplesmente estúpido:

int? i = (int?)myRec.IsFieldNull() ? (int?)null : myRec.Field;
myRec.SetFieldNull();

Isso era irritante no .NET 2.0 e é ainda mais irritante agora que você tem que usar jiggery-pokery como o acima em suas consultas LINQ legais.

Também é irritante que o Add<TableName>Rowmétodo gerado seja igualmente insensível à noção de tipos anuláveis. Ainda mais porque os TableAdaptermétodos gerados não são.

Não há muito no .NET que me faça sentir como se a equipe de desenvolvimento dissesse "Ok, rapazes, estamos perto o suficiente - envie!" Mas isso com certeza faz.

1. Não sou um grande fã das classes Stream, StringWriter, StringReader, TextReader, TextWriter ... apenas não é intuitivo o que é o quê.
2. IEnumerable.Reset lançando uma exceção para iteradores. Tenho alguns componentes de terceiros que sempre chamam a redefinição quando ligados aos dados e exigem que eu faça o cast para uma lista primeiro para usá-los.
3. O Xml Serializer deve ter elementos IDictionary serializados
4. Eu esqueci totalmente da API HttpWebRequest & FTP, que chatice ... (obrigado pelo comentário Nicholas para me lembrar disso :-)

Editar
5. Outro aborrecimento meu é como System.Reflection.BindingFlags, tem usos diferentes dependendo do método que você está usando. Em FindFields, por exemplo, o que CreateInstance ou SetField significa? Este é um caso em que eles sobrecarregaram o significado por trás dessa enumeração, o que é confuso.

Não sei se chegaria a dizer que é uma falha de design, mas seria muito bom se você pudesse inferir uma expressão lambda da mesma forma que você pode no VB:

VB:

Dim a = Function(x) x * (x - 1)

C #

Seria bom se pudesse fazer isso:

var a = x => x * (x - 1);

Em vez de ter que fazer isso:

Func<int, int> a = x => x * (x - 1);

Sei que não é muito mais, mas no Code Golf cada personagem conta, droga! Eles não levam isso em consideração ao projetar essas linguagens de programação? :)

1. A classe System.Object :

   • Equals e GetHashCode - nem todas as classes são comparáveis ​​ou hashable, devem ser movidas para uma interface. IEquatable ou IComparable (ou similar) vem à mente.

   • ToString - nem todas as classes podem ser convertidas em uma string, devem ser movidas para uma interface. IFormattable (ou similar) vem à mente.

2. A propriedade ICollection.SyncRoot :

   • Promove um design pobre, uma fechadura externa quase sempre é mais útil.

3. Os genéricos deveriam estar lá desde o início:

   • O namespace System.Collections contém muitas classes e interfaces mais ou menos obsoletas.

Uma das coisas que me irrita é o Predicate<T> != Func<T, bool>paradoxo. Ambos são delegados do tipo, T -> boolmas não são compatíveis com atribuições.

Algumas pessoas (ISVs) desejam que você possa compilá-lo para o código de máquina em tempo de construção e vinculá-lo, a fim de criar um executável nativo que não precise do tempo de execução dotNet.

Sabemos muito sobre as técnicas OO corretas . Decoupling, programação por contrato, evitando herança imprópria, uso apropriado de exceções, principal aberto / fechado, substituibilidade de Liskov e assim por diante. De qualquer forma, os frameworks .Net não empregam as melhores práticas.

Para mim, a maior falha no design do .Net é não se apoiar nos ombros de gigantes; promovendo paradigmas de programação menos do que ideais para as massas de programadores que usam seus frameworks .

Se a MS prestasse atenção a isso, o mundo da engenharia de software poderia ter dado grandes saltos em termos de qualidade, estabilidade e escalabilidade nesta década, mas, infelizmente, parece estar regredindo.

Não gosto da instrução switch C #.

Eu gostaria de algo assim

switch (a) {
  1    : do_something;
  2    : do_something_else;
  3,4  : do_something_different;
  else : do_something_weird; 
}

Portanto, não há mais interrupções (fácil de esquecer) e a possibilidade de separar valores diferentes por vírgulas.

Eventos em C #, em que você deve verificar explicitamente os ouvintes. Não era esse o objetivo dos eventos, transmitir para quem quer que estivesse lá? Mesmo se não houver nenhum?

O terrível (e quase invisível para a maioria das pessoas) O (N ^ 2) comportamento de iteradores aninhados / recursivos .

Estou bastante abatido que eles saibam sobre isso, sabem como consertar, mas não é visto como tendo prioridade suficiente para merecer inclusão.

Eu trabalho com estruturas semelhantes a árvores o tempo todo e tenho que corrigir o código de pessoas inteligentes quando, inadvertidamente, introduzem operações muito caras dessa maneira.

A beleza de "yield foreach" é que a sintaxe mais simples e fácil incentiva o código correto e de alto desempenho. Esse é o "poço do sucesso" que eu acho que eles deveriam aspirar antes de adicionar novos recursos para o sucesso de longo prazo da plataforma.

Algumas classes implementam interfaces, mas não implementam muitos dos métodos dessa interface, por exemplo, Array implementa IList, mas 4 de 9 métodos lançam NotSupportedException http://msdn.microsoft.com/en-us/library/system.array_members .aspx

Membros estáticos e tipos aninhados em interfaces.

Isso é particularmente útil quando um membro da interface tem um parâmetro de um tipo específico da interface ( por exemplo, an enum). Seria bom aninhar o tipo de enum no tipo de interface.

A natureza padrão terrivelmente perigosa dos eventos. O fato de você poder ligar para um evento e estar em um estado inconsistente devido à remoção de assinantes é simplesmente horrível. Veja os excelentes artigos de Jon Skeet e Eric Lippert para mais leituras sobre o assunto.

• null em toda parte.

• const lugar algum.

• APIs são inconsistentes, por exemplo, alterar um array retorna, voidmas anexar a um StringBufferretorna o mesmo mutável StringBuffer.

• Interfaces de coleção são incompatíveis com estruturas de dados imutáveis, por exemplo, Addin System.Collections.Generic.IList<_>não pode retornar um resultado.

• Nenhuma digitação estrutural, então você escreve em System.Windows.Media.Effects.SamplingMode.Bilinearvez de apenas Bilinear.

• IEnumeratorInterface mutável implementada por classes quando deveria ser imutável struct.

• Igualdade e comparação são uma confusão: você tem System.IComparablee Equalsmas então você também tem System.IComparable<_>, System.IEquatable, System.Collections.IComparer, System.Collections.IStructuralComparable, System.Collections.IStructuralEquatable, System.Collections.Generic.IComparere System.Collections.Generic.IEqualityComparer.

• As tuplas devem ser estruturas, mas as estruturas inibem desnecessariamente a eliminação da chamada final, portanto, um dos tipos de dados mais comuns e fundamentais será alocado desnecessariamente e destruirá o paralelismo escalável.

0 moonlighting como enum

peculiaridades de enum: http://blogs.msdn.com/abhinaba/archive/2007/01/09/more-peculiarites-of-enum.aspx

conforme ilustrado por este bom exemplo: http://plus.kaist.ac.kr/~shoh/postgresql/Npgsql/apidocs/Npgsql.NpgsqlParameterCollection.Add_overload_3.html

minha sugestão, faça bom uso do sinal "@":

ao invés de:

if ((myVar & MyEnumName.ColorRed)! = 0)

usa isto:

if ((myVar & MyEnumName.ColorRed)! = @ 0)

Para adicionar à longa lista de pontos positivos já feitos por outros:

• DateTime.Now == DateTime.Now na maioria, mas não em todos os casos.

• Stringque é imutável tem um monte de opções para construção e manipulação, mas StringBuilder(que é mutável) não tem.

• Monitor.Entere Monitor.Exitdeveriam ter sido métodos de instância, então em vez de criar um objeto específico para bloqueio, você poderia criar um novo a Monitore bloquear nele .

• Os destruidores nunca deveriam ter sido nomeados destruidores. A especificação ECMA os chama de finalizadores, o que é muito menos confuso para o pessoal do C ++, mas a especificação da linguagem ainda se refere a eles como destruidores.

A maneira como usamos as propriedades às vezes me irrita. Gosto de pensar neles como equivalentes aos métodos getFoo () e setFoo () do Java. Mas eles não são.

Se as Diretrizes de Uso de Propriedade afirmam que as propriedades devem poder ser definidas em qualquer ordem para que a serialização possa funcionar, então elas são inúteis para a validação de tempo de definição. Se você vem de um plano de fundo no qual deseja evitar que um objeto se permita jamais entrar em um estado inválido, então as propriedades não são a sua solução. Às vezes não consigo ver apenas como eles são melhores do que membros do público, já que estamos tão limitado em que tipos de coisas que estamos suposto que fazer em propriedades.

Para esse fim, eu sempre desejei (isso é principalmente pensar em voz alta aqui, eu apenas gostaria de poder fazer algo assim) poder estender a sintaxe de propriedade de alguma forma. Imagine algo assim:

private string password;

public string Password
{
    // Called when being set by a deserializer or a persistence
    // framework
    deserialize
    {
       // I could put some backward-compat hacks in here. Like
       // weak passwords are grandfathered in without blowing up
       this.password = value;
    }
    get
    {
       if (Thread.CurrentPrincipal.IsInRole("Administrator"))
       {
           return this.password;
       }
       else
       {
           throw new PermissionException();
       }
    }
    set
    {
       if (MeetsPasswordRequirements(value))
       {
           throw new BlahException();
       }
       this.password = value;
    }
    serialize
    {
        return this.password;
    }
}

Não tenho certeza se isso é útil ou como seria acessá-los. Mas eu só gostaria de poder fazer mais com propriedades e realmente tratá-las como métodos get e set.

Métodos de extensão são bons, mas são uma maneira feia de resolver problemas que poderiam ser resolvidos de forma mais limpa com mixins reais (olhe para o ruby ​​para ver do que estou falando), sobre o assunto de mixins. Uma maneira realmente boa de adicioná-los à linguagem seria permitir que os genéricos fossem usados ​​para herança. Isso permite que você estenda as classes existentes de uma boa maneira orientada a objetos:

public class MyMixin<T> : T
{
    // etc...
}

isso pode ser usado assim para estender uma string, por exemplo:

var newMixin = new MyMixin<string>();

É muito mais poderoso do que os métodos de extensão porque permite que você substitua os métodos, por exemplo, para envolvê-los, permitindo uma funcionalidade semelhante a AOP dentro da linguagem.

Desculpe pelo discurso retórico :-)

A Microsoft não corrigirá bugs óbvios na estrutura e não fornecerá ganchos para que os usuários finais possam corrigi-los.

Além disso, não há como aplicar patch binário aos executáveis ​​.NET em tempo de execução e nem especificar versões privadas de bibliotecas do .NET Framework sem aplicar patch binário às bibliotecas nativas (para interceptar a chamada de carregamento), e ILDASM não é redistribuível, portanto não posso automatizar o patch de qualquer maneira.

• Ser capaz de invocar um método de extensão em uma variável nula é discutível, por exemplo

  objeto a = nulo; a.MyExtMethod (); // isso é chamável, suponha que em algum lugar ele tenha definido MyExtMethod

  Pode ser útil, mas é ambíguo em tópicos de exceção de referência nula.

• Um nomeando 'falha'. 'C' de "configuração" em System.configuration.dll deve estar em maiúscula.

• Manipulação de exceção. A exceção deve ser capturada ou lançada à força como em Java, o compilador deve verificá-la no momento da compilação. Os usuários não devem confiar em comentários para informações de exceções na invocação de destino.

O método .Parameters.Add () no SqlCommand em V1 do framework foi horrivelmente projetado - uma das sobrecargas basicamente não funcionaria se você passasse um parâmetro com um valor (int) de 0 - isso os levou à criação o método .Parameters.AddWithValue () na classe SqlCommand.

1. Não há subconjuntos de ICollection<T>e IList<T>; no mínimo, uma interface de coleção covariant somente leitura IListSource<out T>(com um enumerador, indexador e Count) teria sido extremamente útil.
2. .NET não oferece suporte a delegados fracos . As soluções alternativas são, na melhor das hipóteses, desajeitadas e as soluções alternativas do lado do ouvinte são impossíveis na confiança parcial (é necessário ReflectionPermission).
3. A unificação de interface genérica é proibida mesmo quando faz sentido e não causa problemas.
4. Ao contrário do C ++, os tipos de retorno covariant não são permitidos no .NET
5. Não é possível comparar bit a bit dois tipos de valor para igualdade. Em uma estrutura de dados " persistente " funcional , eu estava escrevendo uma Transform(Sequence<T>, Func<T,T>)função que precisava determinar rapidamente se a função retorna o mesmo valor ou um valor diferente. Se a função não modificar a maioria / todos os seus argumentos, a sequência de saída pode compartilhar parte / toda a memória da sequência de entrada. Sem a capacidade de comparar bit a bit qualquer tipo de valor T, uma comparação muito mais lenta deve ser usada, o que prejudica o desempenho tremendamente.
6. .NET não parece ser capaz de oferecer suporte a interfaces ad-hoc (como as oferecidas em Go ou Rust) de maneira eficiente. Essas interfaces teriam permitido a você lançar List<T>para um hipotético IListSource<U>(onde T: U), mesmo que a classe não implemente explicitamente essa interface. Existem pelo menos três bibliotecas diferentes (escritas independentemente) para fornecer esta funcionalidade (com desvantagens de desempenho, é claro - se uma solução alternativa perfeita fosse possível, não seria justo chamá-la de uma falha no .NET).
7. Outros problemas de desempenho: IEnumerator requer duas chamadas de interface por iteração. Ponteiros de método simples (delegados abertos de tamanho IntPtr) ou delegados digitados por valor (IntPtr * 2) não são possíveis. Arrays de tamanho fixo (de tipo arbitrário T) não podem ser embutidos em classes. Não há WeakReference<T>(você pode escrever facilmente o seu, mas usará casts internamente).
8. O fato de que tipos de delegados idênticos são considerados incompatíveis (sem conversão implícita) tem sido um incômodo para mim em algumas ocasiões (por exemplo, Predicate<T>vs Func<T,bool>). Muitas vezes gostaria que pudéssemos ter tipagem estrutural para interfaces e delegados, para obter um acoplamento mais flexível entre os componentes, porque no .NET não é suficiente para classes em DLLs independentes implementarem a mesma interface - eles também devem compartilhar uma referência comum a um terceiro DLL que define a interface.
9. DBNull.Valueexiste mesmo que nulltivesse servido ao mesmo propósito igualmente bem.
10. C # não tem operador ?? =; você deve escrever variable = variable ?? value. Na verdade, existem alguns lugares em C # que carecem de simetria desnecessariamente. Por exemplo, você pode escrever if (x) y(); else z();(sem colchetes), mas não pode escrever try y(); finally z();.
11. Ao criar um thread, é impossível fazer com que o thread filho herde os valores locais do thread do thread pai. Não apenas o BCL não suporta isso, mas você não pode implementá-lo sozinho, a menos que crie todos os threads manualmente; mesmo se houver um evento de criação de thread, o .NET não pode dizer os "pais" ou "filhos" de um determinado thread.
12. O fato de haver dois atributos de comprimento diferentes para tipos de dados diferentes, "Comprimento" e "Contagem", é um pequeno incômodo.
13. Eu poderia continuar para sempre sobre o design pobre do WPF ... e o WCF (embora bastante útil para alguns cenários) também está cheio de falhas. Em geral, o inchaço, a falta de intuição e a documentação limitada de muitas das novas sub-bibliotecas do BCL me deixam relutante em usá-las. Muitas das coisas novas poderiam ser muito mais simples, menores, mais fáceis de usar e entender, mais fracamente acopladas, melhor documentadas, aplicáveis ​​a mais casos de uso, mais rápidas e / ou com tipos mais fortes.
14. Muitas vezes sou mordido pelo acoplamento desnecessário entre getters e setters de propriedade: em uma classe derivada ou interface derivada, você não pode simplesmente adicionar um setter quando a classe base ou interface base tem apenas um getter; se você substituir um getter, não terá permissão para definir um setter; e você não pode definir o setter como virtual, mas o getter como não virtual.

Uma coisa que me irritou no 1.x foi que, ao usar o System.Xml.XmlValidatingReader, o ValidationEventHandlerdo ValidationEventArgsnão expõe o subjacente XmlSchemaException(marcado como interno), que contém todas as informações úteis como linenumbere position. Em vez disso, espera-se que você analise isso a partir da propriedade da string Message ou use a reflexão para descobrir. Não é tão bom quando você deseja retornar um erro mais limpo para o usuário final.

Não gosto que você não possa usar os valores de um enum em outro enum, por exemplo:

    enum Colors { white, blue, green, red, black, yellow }

    enum SpecialColors { Colors.blue, Colors.red, Colors.Yellow } 

Variáveis ​​implicitamente digitadas foram implementadas de forma inadequada na IMO. Eu sei que você só deve usá-los ao trabalhar com expressões do Linq, mas é irritante que você não possa declará-los fora do escopo local.

Do MSDN:

• var só pode ser usado quando uma variável local é declarada e inicializada na mesma instrução; a variável não pode ser inicializada como nula, ou para um grupo de métodos ou uma função anônima.
• var não pode ser usado em campos no escopo da classe.
• Variáveis ​​declaradas usando var não podem ser usadas na expressão de inicialização. Em outras palavras, essa expressão é válida: int i = (i = 20); mas essa expressão produz um erro em tempo de compilação: var i = (i = 20);
• Várias variáveis ​​digitadas implicitamente não podem ser inicializadas na mesma instrução.
• Se um tipo chamado var estiver no escopo, a palavra-chave var será resolvida para esse nome de tipo e não será tratada como parte de uma declaração de variável local digitada implicitamente.

O motivo pelo qual acho que é uma implementação ruim é que eles a chamam de var, mas está muito longe de ser uma variante. É apenas uma sintaxe abreviada para não ter que digitar o nome completo da classe (exceto quando usado com Linq)