Eu estava trabalhando recentemente com um DateTimeobjeto e escrevi algo assim:

DateTime dt = DateTime.Now;
dt.AddDays(1);
return dt; // still today's date! WTF?

A documentação do intellisense AddDays()diz que ele adiciona um dia à data, o que não acontece - na verdade, ele retorna uma data com um dia adicionado, então você deve escrevê-lo como:

DateTime dt = DateTime.Now;
dt = dt.AddDays(1);
return dt; // tomorrow's date

Este já havia me mordido várias vezes antes, então pensei que seria útil catalogar as piores pegadinhas de C #.

private int myVar;
public int MyVar
{
    get { return MyVar; }
}

Blammo. Seu aplicativo falha sem rastreamento de pilha. Acontece o tempo todo.

(Observe maiúsculas em MyVarvez de minúsculas myVarno getter.)

Type.GetType

O que eu já vi morder muitas pessoas é Type.GetType(string). Eles se perguntam por que isso funciona para tipos em sua própria montagem, e alguns tipos gostam System.String, mas não System.Windows.Forms.Form. A resposta é que ele aparece apenas na montagem atual e dentro mscorlib.

Métodos anônimos

O C # 2.0 introduziu métodos anônimos, levando a situações desagradáveis ​​como esta:

using System;
using System.Threading;

class Test
{
    static void Main()
    {
        for (int i=0; i < 10; i++)
        {
            ThreadStart ts = delegate { Console.WriteLine(i); };
            new Thread(ts).Start();
        }
    }
}

O que isso imprimirá? Bem, depende inteiramente da programação. Ele imprimirá 10 números, mas provavelmente não imprimirá 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, que é o que você pode esperar. O problema é que é a ivariável que foi capturada, não o seu valor no momento da criação do delegado. Isso pode ser resolvido facilmente com uma variável local extra com o escopo correto:

using System;
using System.Threading;

class Test
{
    static void Main()
    {
        for (int i=0; i < 10; i++)
        {
            int copy = i;
            ThreadStart ts = delegate { Console.WriteLine(copy); };
            new Thread(ts).Start();
        }
    }
}

Execução adiada de blocos de iterador

Esse "teste de unidade do pobre homem" não passa - por que não?

using System;
using System.Collections.Generic;
using System.Diagnostics;

class Test
{
    static IEnumerable<char> CapitalLetters(string input)
    {
        if (input == null)
        {
            throw new ArgumentNullException(input);
        }
        foreach (char c in input)
        {
            yield return char.ToUpper(c);
        }
    }

    static void Main()
    {
        // Test that null input is handled correctly
        try
        {
            CapitalLetters(null);
            Console.WriteLine("An exception should have been thrown!");
        }
        catch (ArgumentNullException)
        {
            // Expected
        }
    }
}

A resposta é que o código dentro da fonte do CapitalLetters código não é executado até que o MoveNext()método do iterador seja chamado pela primeira vez.

Tenho outras curiosidades na minha página de quebra-cabeças .

Lançar exceções novamente

Uma pegadinha que atrai muitos novos desenvolvedores é a semântica de exceção de re-lançamento.

Muito tempo vejo código como o seguinte

catch(Exception e) 
{
   // Do stuff 
   throw e; 
}

O problema é que ele limpa o rastreamento da pilha e dificulta muito o diagnóstico, pois não é possível rastrear a origem da exceção.

O código correto é a instrução throw sem argumentos:

catch(Exception)
{
    throw;
}

Ou agrupando a exceção em outra e usando a exceção interna para obter o rastreamento da pilha original:

catch(Exception e) 
{
   // Do stuff 
   throw new MySpecialException(e); 
}

A janela de inspeção da Heisenberg

Isso pode te incomodar muito se você estiver fazendo coisas sob demanda, como esta:

private MyClass _myObj;
public MyClass MyObj {
  get {
    if (_myObj == null)
      _myObj = CreateMyObj(); // some other code to create my object
    return _myObj;
  }
}

Agora, digamos que você tenha algum código em outro lugar usando isso:

// blah
// blah
MyObj.DoStuff(); // Line 3
// blah

Agora você deseja depurar seu CreateMyObj()método. Então você coloca um ponto de interrupção na Linha 3 acima, com a intenção de entrar no código. Apenas para uma boa medida, você também coloca um ponto de interrupção na linha acima _myObj = CreateMyObj();, e até um ponto de interrupção dentroCreateMyObj() si.

O código atinge seu ponto de interrupção na Linha 3. Você entra no código. Você espera inserir o código condicional, porque _myObjobviamente é nulo, certo? Uh ... então ... por que pulou a condição e foi direto parareturn _myObj ?! Você passa o mouse sobre _myObj ... e, de fato, ele tem um valor! Como isso aconteceu?!

A resposta é que seu IDE fez com que ele obtivesse um valor, porque você tem uma janela de observação aberta - especialmente a janela de observação "Autos", que exibe os valores de todas as variáveis ​​/ propriedades relevantes para a linha de execução atual ou anterior. Quando você atingiu seu ponto de interrupção na Linha 3, a janela de inspeção decidiu que você estaria interessado em saber o valor de MyObj- portanto, nos bastidores, ignorando qualquer um de seus pontos de interrupção , ele calculou o valor MyObjpara você - incluindo a chamada para CreateMyObj()isso define o valor de _myObj!

É por isso que eu chamo isso de Janela de inspeção Heisenberg - você não pode observar o valor sem afetá-lo ... :)

PEGUEI VOCÊS!

Editar - Eu sinto que o comentário de @ ChristianHayter merece inclusão na resposta principal, porque parece uma solução alternativa eficaz para esse problema. Então, sempre que você tiver uma propriedade preguiçosa ...

Decore sua propriedade com [DebuggerBrowsable (DebuggerBrowsableState.Never)] ou [DebuggerDisplay ("<loading on demand>")]. - Christian Hayter

Aqui está outra vez que me pega:

static void PrintHowLong(DateTime a, DateTime b)
{
    TimeSpan span = a - b;
    Console.WriteLine(span.Seconds);        // WRONG!
    Console.WriteLine(span.TotalSeconds);   // RIGHT!
}

TimeSpan.Seconds é a parte dos segundos do período (2 minutos e 0 segundos tem um valor de segundos 0).

TimeSpan.TotalSeconds é o período inteiro medido em segundos (2 minutos tem um valor total de segundos de 120).

Falta de memória porque você não desvinculou eventos.

Isso até chamou a atenção de alguns desenvolvedores seniores.

Imagine um formulário WPF com muitas coisas e, em algum lugar, você se inscreve em um evento. Se você não cancelar a inscrição, o formulário inteiro será mantido na memória após ser fechado e retirado de referência.

Acredito que o problema que vi foi a criação de um DispatchTimer no formulário WPF e a assinatura do evento Tick, se você não fizer um - = no cronômetro, seu formulário vazará memória!

Neste exemplo, seu código de desmontagem deve ter

timer.Tick -= TimerTickEventHandler;

Essa é especialmente complicada desde que você criou a instância do DispatchTimer dentro do formulário WPF, então você pensaria que seria uma referência interna tratada pelo processo de Coleta de Lixo ... infelizmente o DispatchTimer usa uma lista interna estática de assinaturas e serviços solicitações no encadeamento da interface do usuário, portanto, a referência é 'de propriedade' da classe estática.

Talvez não seja realmente um problema, porque o comportamento está escrito claramente no MSDN, mas quebrou meu pescoço uma vez porque eu achei bastante contra-intuitivo:

Image image = System.Drawing.Image.FromFile("nice.pic");

Esse cara deixa o "nice.pic"arquivo bloqueado até que a imagem seja descartada. Na época, eu achei que seria bom carregar ícones rapidamente e não percebi (no começo) que acabei com dezenas de arquivos abertos e bloqueados! A imagem mantém o controle de onde ele carregou o arquivo ...

Como resolver isso? Eu pensei que um forro faria o trabalho. Eu esperava um parâmetro extra para FromFile(), mas não tinha, então escrevi isso ...

using (Stream fs = new FileStream("nice.pic", FileMode.Open, FileAccess.Read))
{
    image = System.Drawing.Image.FromStream(fs);
}

Se você contar o ASP.NET, eu diria que o ciclo de vida dos formulários da web é um grande problema para mim. Passei inúmeras horas depurando códigos de formulários da web mal escritos, apenas porque muitos desenvolvedores realmente não entendem quando usar qual manipulador de eventos (inclusive eu, infelizmente).

sobrecarregado == operadores e contêineres não tipados (listas de matrizes, conjuntos de dados etc.):

string my = "my ";
Debug.Assert(my+"string" == "my string"); //true

var a = new ArrayList();
a.Add(my+"string");
a.Add("my string");

// uses ==(object) instead of ==(string)
Debug.Assert(a[1] == "my string"); // true, due to interning magic
Debug.Assert(a[0] == "my string"); // false

Soluções?

• sempre use string.Equals(a, b)quando estiver comparando tipos de string

• usando genéricos como List<string>para garantir que ambos os operandos sejam cadeias.

[Serializable]
class Hello
{
    readonly object accountsLock = new object();
}

//Do stuff to deserialize Hello with BinaryFormatter
//and now... accountsLock == null ;)

Moral da história: inicializadores de campo não são executados ao desserializar um objeto

DateTime.ToString ("dd / MM / aaaa") ; Na verdade, isso nem sempre fornece dd / MM / aaaa, mas leva em consideração as configurações regionais e substitui o separador de datas, dependendo de onde você estiver. Então você pode ter dd-MM-aaaa ou algo parecido.

A maneira correta de fazer isso é usar DateTime.ToString ("dd '/' MM '/' aaaa");

DateTime.ToString ("r") deve converter para RFC1123, que usa GMT. GMT está dentro de uma fração de segundo do UTC e, no entanto, o especificador de formato "r" não se converte em UTC , mesmo que o DateTime em questão seja especificado como Local.

Isso resulta na seguinte pegada (varia de acordo com a distância da hora local em relação ao UTC):

DateTime.Parse("Tue, 06 Sep 2011 16:35:12 GMT").ToString("r")
>              "Tue, 06 Sep 2011 17:35:12 GMT"

Ops!

Vi este postado outro dia, e acho que é bastante obscuro e doloroso para quem não sabe

int x = 0;
x = x++;
return x;

Como isso retornará 0 e não 1, como a maioria esperaria

Estou um pouco atrasado para esta festa, mas tenho duas dicas que me morderam recentemente:

Resolução DateTime

A propriedade Ticks mede o tempo em 10 milionésimos de segundo (blocos de 100 nanossegundos), no entanto a resolução não é de 100 nanossegundos, é cerca de 15ms.

Este código:

long now = DateTime.Now.Ticks;
for (int i = 0; i < 10; i++)
{
    System.Threading.Thread.Sleep(1);
    Console.WriteLine(DateTime.Now.Ticks - now);
}

fornecerá uma saída de (por exemplo):

0
0
0
0
0
0
0
156254
156254
156254

Da mesma forma, se você olhar DateTime.Now.Millisecond, obterá valores em blocos arredondados de 15.625ms: 15, 31, 46, etc.

Esse comportamento específico varia de sistema para sistema , mas há outras dicas relacionadas à resolução nesta API de data / hora.

Path.Combine

Uma ótima maneira de combinar caminhos de arquivos, mas nem sempre se comporta da maneira que você esperaria.

Se o segundo parâmetro começar com um \caractere, ele não fornecerá um caminho completo:

Este código:

string prefix1 = "C:\\MyFolder\\MySubFolder";
string prefix2 = "C:\\MyFolder\\MySubFolder\\";
string suffix1 = "log\\";
string suffix2 = "\\log\\";

Console.WriteLine(Path.Combine(prefix1, suffix1));
Console.WriteLine(Path.Combine(prefix1, suffix2));
Console.WriteLine(Path.Combine(prefix2, suffix1));
Console.WriteLine(Path.Combine(prefix2, suffix2));

Dá a você esta saída:

C:\MyFolder\MySubFolder\log\
\log\
C:\MyFolder\MySubFolder\log\
\log\

Quando você inicia um processo (usando System.Diagnostics) que grava no console, mas nunca lê o fluxo Console.Out, após uma certa quantidade de saída, seu aplicativo parece travar.

Nenhum atalho de operador no Linq-To-Sql

Veja aqui .

Em resumo, dentro da cláusula condicional de uma consulta Linq-to-Sql, você não pode usar atalhos condicionais como ||e &&para evitar exceções de referência nula; O Linq-to-Sql avalia os dois lados do operador OR ou AND, mesmo que a primeira condição evite a necessidade de avaliar a segunda condição!

Usando parâmetros padrão com métodos virtuais

abstract class Base
{
    public virtual void foo(string s = "base") { Console.WriteLine("base " + s); }
}

class Derived : Base
{
    public override void foo(string s = "derived") { Console.WriteLine("derived " + s); }
}

...

Base b = new Derived();
b.foo();

Saída:
base derivada

Objetos de valor em coleções mutáveis

struct Point { ... }
List<Point> mypoints = ...;

mypoints[i].x = 10;

não tem efeito.

mypoints[i]retorna uma cópia de um Pointobjeto de valor. Felizmente, o C # permite modificar um campo da cópia. Silenciosamente, não fazendo nada.

Atualização: isso parece estar corrigido no C # 3.0:

Cannot modify the return value of 'System.Collections.Generic.List<Foo>.this[int]' because it is not a variable

Talvez não seja o pior, mas algumas partes da estrutura .net usam graus enquanto outras usam radianos (e a documentação que aparece no Intellisense nunca informa qual, você precisa visitar o MSDN para descobrir)

Tudo isso poderia ter sido evitado com uma Angleaula ...

Para programadores C / C ++, a transição para C # é natural. No entanto, o maior problema que eu já encontrei pessoalmente (e vi com outros fazendo a mesma transição) não é entender completamente a diferença entre classes e estruturas em C #.

Em C ++, classes e estruturas são idênticas; eles diferem apenas na visibilidade padrão, onde as classes são padronizadas para visibilidade privada e as estruturas padrão para visibilidade pública. Em C ++, essa definição de classe

    class A
    {
    public:
        int i;
    };

é funcionalmente equivalente a esta definição de estrutura.

    struct A
    {
        int i;
    };

No C #, no entanto, classes são tipos de referência, enquanto estruturas são tipos de valor. Isso faz uma GRANDE diferença em (1) decidir quando usar um sobre o outro, (2) testar a igualdade de objetos, (3) desempenho (por exemplo, boxe / unboxing), etc.

Há todos os tipos de informações na web relacionadas às diferenças entre os dois (por exemplo, aqui ). Eu encorajaria qualquer pessoa que fizesse a transição para o C # a ter pelo menos um conhecimento prático das diferenças e suas implicações.

Coleta de lixo e Dispose (). Embora você não precise fazer nada para liberar memória , ainda precisa liberar recursos via Dispose (). É uma coisa imensamente fácil de esquecer quando você está usando o WinForms ou rastreando objetos de qualquer maneira.

Implementar matrizes IList

Mas não o implemente. Quando você liga para Adicionar, ele diz que não funciona. Então, por que uma classe implementa uma interface quando não pode suportá-la?

Compila, mas não funciona:

IList<int> myList = new int[] { 1, 2, 4 };
myList.Add(5);

Temos muito esse problema, porque o serializador (WCF) transforma todas as ILists em matrizes e obtemos erros de tempo de execução.

o foreach loops o escopo das variáveis!

var l = new List<Func<string>>();
var strings = new[] { "Lorem" , "ipsum", "dolor", "sit", "amet" };
foreach (var s in strings)
{
    l.Add(() => s);
}

foreach (var a in l)
    Console.WriteLine(a());

imprime cinco "amet", enquanto o exemplo a seguir funciona bem

var l = new List<Func<string>>();
var strings = new[] { "Lorem" , "ipsum", "dolor", "sit", "amet" };
foreach (var s in strings)
{
    var t = s;
    l.Add(() => t);
}

foreach (var a in l)
    Console.WriteLine(a());

O MS SQL Server não pode manipular datas antes de 1753. Significativamente, isso está fora de sincronia com a DateTime.MinDateconstante .NET , que é 1/1/1. Então, se você tentar salvar um estado de espírito, uma data incorreta (como aconteceu recentemente em uma importação de dados) ou simplesmente a data de nascimento de William, o Conquistador, você estará em apuros. Não há solução interna para isso; se é provável que você precise trabalhar com datas anteriores a 1753, precisará escrever sua própria solução alternativa.

O desagradável Linq Caching Gotcha

Veja minha pergunta que levou a essa descoberta e o blogueiro que descobriu o problema.

Em resumo, o DataContext mantém um cache de todos os objetos Linq para Sql que você já carregou. Se alguém fizer alguma alteração em um registro carregado anteriormente, você não poderá obter os dados mais recentes, mesmo se recarregar explicitamente o registro!

Isso ocorre devido a uma propriedade chamada ObjectTrackingEnabledno DataContext, que por padrão é verdadeira. Se você definir essa propriedade como false, o registro será carregado novamente toda vez ... MAS ... você não poderá manter nenhuma alteração nesse registro com SubmitChanges ().

PEGUEI VOCÊS!

O contrato no Stream.Read é algo que eu já vi provocar muitas pessoas:

// Read 8 bytes and turn them into a ulong
byte[] data = new byte[8];
stream.Read(data, 0, 8); // <-- WRONG!
ulong data = BitConverter.ToUInt64(data);

A razão pela qual isso está errado é que Stream.Readlerá no máximo o número especificado de bytes, mas é totalmente gratuito para ler apenas 1 byte, mesmo que outros 7 bytes estejam disponíveis antes do final do fluxo.

Não ajuda que isso seja tão parecido com Stream.Write, que é garantido que todos os bytes foram gravados se retornar sem exceção. Também não ajuda que o código acima funcione quase o tempo todo . E é claro que não ajuda que não exista um método conveniente e pronto para ler exatamente N bytes corretamente.

Portanto, para tapar o buraco e aumentar a conscientização disso, aqui está um exemplo de uma maneira correta de fazer isso:

    /// <summary>
    /// Attempts to fill the buffer with the specified number of bytes from the
    /// stream. If there are fewer bytes left in the stream than requested then
    /// all available bytes will be read into the buffer.
    /// </summary>
    /// <param name="stream">Stream to read from.</param>
    /// <param name="buffer">Buffer to write the bytes to.</param>
    /// <param name="offset">Offset at which to write the first byte read from
    ///                      the stream.</param>
    /// <param name="length">Number of bytes to read from the stream.</param>
    /// <returns>Number of bytes read from the stream into buffer. This may be
    ///          less than requested, but only if the stream ended before the
    ///          required number of bytes were read.</returns>
    public static int FillBuffer(this Stream stream,
                                 byte[] buffer, int offset, int length)
    {
        int totalRead = 0;
        while (length > 0)
        {
            var read = stream.Read(buffer, offset, length);
            if (read == 0)
                return totalRead;
            offset += read;
            length -= read;
            totalRead += read;
        }
        return totalRead;
    }

    /// <summary>
    /// Attempts to read the specified number of bytes from the stream. If
    /// there are fewer bytes left before the end of the stream, a shorter
    /// (possibly empty) array is returned.
    /// </summary>
    /// <param name="stream">Stream to read from.</param>
    /// <param name="length">Number of bytes to read from the stream.</param>
    public static byte[] Read(this Stream stream, int length)
    {
        byte[] buf = new byte[length];
        int read = stream.FillBuffer(buf, 0, length);
        if (read < length)
            Array.Resize(ref buf, read);
        return buf;
    }

Eventos

Eu nunca entendi por que os eventos são um recurso de linguagem. Eles são complicados de usar: você precisa verificar se há nulo antes de ligar, você precisa cancelar o registro (você mesmo), não consegue descobrir quem está registrado (por exemplo: eu me registrei?). Por que um evento não é apenas uma aula na biblioteca? Basicamente um especialista List<delegate>?

Hoje eu consertei um bug que escapava por muito tempo. O bug estava em uma classe genérica usada no cenário multithread e um campo int estático foi usado para fornecer sincronização sem bloqueio usando o Interlocked. O bug foi causado porque cada instanciação da classe genérica para um tipo tem sua própria estática. Portanto, cada encadeamento tem seu próprio campo estático e não foi usado um bloqueio como pretendido.

class SomeGeneric<T>
{
    public static int i = 0;
}

class Test
{
    public static void main(string[] args)
    {
        SomeGeneric<int>.i = 5;
        SomeGeneric<string>.i = 10;
        Console.WriteLine(SomeGeneric<int>.i);
        Console.WriteLine(SomeGeneric<string>.i);
        Console.WriteLine(SomeGeneric<int>.i);
    }
}

Imprime 5 10 5

Enumeráveis ​​podem ser avaliados mais de uma vez

Ele vai te morder quando você tem um enumerável preguiçosamente enumerado e você o itera duas vezes e obtém resultados diferentes. (ou você obtém os mesmos resultados, mas é executado duas vezes desnecessariamente)

Por exemplo, enquanto escrevia um determinado teste, eu precisava de alguns arquivos temporários para testar a lógica:

var files = Enumerable.Range(0, 5)
    .Select(i => Path.GetTempFileName());

foreach (var file in files)
    File.WriteAllText(file, "HELLO WORLD!");

/* ... many lines of codes later ... */

foreach (var file in files)
    File.Delete(file);

Imagine minha surpresa quando File.Delete(file)joga FileNotFound!!

O que está acontecendo aqui é que o filesenumerável foi iterado duas vezes (os resultados da primeira iteração simplesmente não são lembrados) e em cada nova iteração você estava chamando novamente Path.GetTempFilename()para obter um conjunto diferente de nomes de arquivos temporários.

A solução é, obviamente, enumerar ansiosamente o valor usando ToArray()ou ToList():

var files = Enumerable.Range(0, 5)
    .Select(i => Path.GetTempFileName())
    .ToArray();

Isso é ainda mais assustador quando você está fazendo algo multiencadeado, como:

foreach (var file in files)
    content = content + File.ReadAllText(file);

e você descobre que content.Lengthainda é 0 depois de todas as gravações !! Você então começa a checar rigorosamente se não tem uma condição de corrida quando ... depois de uma hora desperdiçada ... você descobriu que é apenas aquela coisinha que você esqueceu ...

Achei um estranho que me deixou preso na depuração por um tempo:

Você pode incrementar nulo para um int nulo sem gerar uma exceção e o valor permanece nulo.

int? i = null;
i++; // I would have expected an exception but runs fine and stays as null

TextInfo textInfo = Thread.CurrentThread.CurrentCulture.TextInfo;

textInfo.ToTitleCase("hello world!"); //Returns "Hello World!"
textInfo.ToTitleCase("hElLo WoRld!"); //Returns "Hello World!"
textInfo.ToTitleCase("Hello World!"); //Returns "Hello World!"
textInfo.ToTitleCase("HELLO WORLD!"); //Returns "HELLO WORLD!"

Sim, esse comportamento está documentado, mas isso certamente não o torna correto.