Estrutura de código robusta?

Question

Eu odeio escrever código que torna meu software mais sólido. Isso é algo que a estrutura deveria ter feito! Então, alguém está ciente de um utilitário "aprimoramento" de código que solidifica o código?

Se eu tivesse que criar algo assim, funcionaria da seguinte maneira: quando você está compilando seu código com uma bandeira de depuração, ele adicionaria automaticamente o código "solidificante" para cada método:

Distorcer o código com um try-capath e colocar um debug.assert (true) na captura (para que as exceções sejam capturadas em sua origem).

Registre a entrada de cada método, imprimindo valores de argumentos "ToString ()", para que eu possa rastrear o que está acontecendo.

Verifique cada argumento para NULL.

Use uma estrutura "IsValid" para verificar o próprio objeto e cada argumento, onde IsValid () é a maneira do objeto de declarar que suas expectativas são verdadeiras (por exemplo, se eu sou uma tabelafcontententry, espero sempre estar em um livro que é Isvalid () e apontar para uma página que é IsValid ().

Então por que não?

Answer 1

Se você quiser registrar chamadas do método, você pode usar uma estrutura AOP como PostSharp. Coisas como o método de imposição pré/pós-condicionas seriam melhor alcançadas usando mecanismos de design por contrato como o novo Contratos de código Biblioteca que será enviada com .NET4.0. Certamente não faz sentido verificar os argumentos nulos, pois esse pode ser um valor válido, dependendo do método. Injetar Debug.Asserts no código pode ser problemático, pois você pode não querer/poder lidar com exceções na função de origem. Eu acho que seria impraticável se não impossível criar uma estrutura genérica para esse tipo de coisa, pois os requisitos diferirão tanto entre os projetos.

Editar: Para esclarecer meu comentário sobre a adição de afirmações de depuração aos métodos - leio sua proposta para converter um corpo de método em algo assim:

public void SomeMethod(args)
{
    try
    {
        //original method body
    }
    catch(Exception ex)
    {
        Debug.Assert(false);
        throw;
    }
}

O problema é que afirma indicar coisas que nunca devem ser falsas - então esse construto significa que o método nunca pode lançar o que não é verdadeiro em geral. O problema é agora que, se o método lançar, a afirmação falhará mesmo se o método de chamada lidar com a exceção adequadamente. Do seu comentário, parece que você está fazendo algo assim:

public void SomeMethod(object arg)
{
    Debug.Assert(arg != null);
    if(arg == null) throw new ArgumentNullException("arg");

    //rest of method
}

Essa é uma prática útil, e acredito que a biblioteca de contratos de código apóia a verificação pré -condição do 'legado' (Exceções de lançamento) em sua análise estática.

Answer 2

É bom ver meu livro sendo conectado! O grande problema para mim é que acho que a geração de código deve estar "além" do código do desenvolvedor-idealmente, o código gerado não seria misturado com o código do desenvolvedor. Gostaria de saber se há alguma maneira de adicionar esse código 'Solidfying' como uma classe parcial ou como um proxy que estabeleceria entre a classe e o cliente que o chamava? Obviamente, é certamente possível gerar o código e inseri -lo no código do desenvolvedor, mas você deseja criar algum tipo de convenção para que, quando o desenvolvedor fizesse uma alteração e regenera o código "vendido", a ferramenta possa excluir o antigo Code e gerar novo código com base na versão mais recente do código do desenvolvedor.

Answer 3

Eu adoraria algo que não perde sua pilha quando você passa algo para um tópico de trabalhador. Eu nem conheço uma solução alternativa para isso (C#). Seria ótimo saber a pilha do tópico pai até o ponto em que o tópico do trabalhador foi criado.

Em geral, acho que muitas das coisas realmente úteis precisariam ser incorporadas em um idioma e não podem realmente ser alcançadas de maneira limpa apenas por uma biblioteca ou estrutura. Lembro -me do ensino médio que eles ensinaram a escrever sempre em condições pré/pós nos comentários para uma função, mas o que eu realmente gostaria de ver é escrever condições pré/post que são verificadas, se possível, no momento da compilação, se não tempo de execução. Eles seriam sinalizados de alguma maneira, de modo que um editor possa mostrá -los ou ocultá -los opcionalmente para que não atrapalhe o código real.

Answer 4

Duvido que haja algo assim e se, com certeza não é tão utilizável. Depende de suas definições de regras, pessoas diferentes pensam que são diferentes necessidades e estruturas ... as coisas que você descreveu podem ser alcançadas por metaprogramação ou algum sistema macro. Em Java, existem alguns projetos que podem ajudar a implementar essa abordagem de anotações USIGN, não sabem se há algum equivalente no universo C#. A funcionalidade iSValid (), no entanto, parece muito parecida com o design por idéia do contrato, talvez haja algumas estruturas para isso.