Vitor Rubio Developer - Dicas de programação

Define-se por  notação húngara   a prática de prefixar variáveis com letras que indiquem o seu tipo. Por exemplo i para inteiros, d para datas, f para floats.       As variáveis data de nascimento e nome em notação húngara seriam ddatanascimento e snome, no pior dos casos, ou dDataDeNascimento e sNome se o "programador" resolveu usar camelCase.       Como mencionei nos meus artigos anteriores, e como mencionado nos livros "Código Limpo" e qualquer livro sobre XP, essa prática caiu em desuso.       Ela foi útil um dia para identificar o tipo das variáveis, e de fato identificava. Hoje damos nomes significativos para as variáveis e deixamos que sua declaração e as facilidades da IDE identifiquem o seu tipo. Além disso hoje podemos mudar o tipo de uma variável mantendo o seu nome e o seu uso, coisa que no passado geraria alguma inconsistência semântica na hora de ler e dar manutenção no código.       Soma-se a isso o fato de no passado nã

     Os padrões apresentados aqui são fruto de uma pesquisa em 2 livros e 4 sites, experiências profissionais do autor, consenso do mercado e recomendações de práticas da Microsoft. Como qualquer convenção ou tecnologia, este não é 100% correto, não é uma verdade absoluta e não é uma bala de prata. São apenas guidelines para que todos nós escrevamos bom código, código limpo e livre de bad smells e que possamos entender e melhorar os códigos uns dos outros, evoluindo como equipe. Nesse texto eu quis expressar não somente regras de nomenclatura e codificação, mas também apresentar algumas boas práticas para um código mais coeso e flexível.      Esses são os padrões que adotamos na empresa onde trabalho e não há nenhum motivo especial para você e sua equipe adotarem este. Os padrões de codificação devem ser um consenso da equipe.      Estes foram elaborados com ajuda de outros padrões prontos de outras empresas, unindo o que eu achei de melhor nos padrões da Microsoft e nas práticas já

If you get Could not load type System.ServiceModel.Activation.HttpModule from assembly System.ServiceModel, Version=3.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089. error trying to access a webservice in .net framework 4.0 or 4.5 it is caused by a conflict between 3.0 and 4.0 version. Fortunately you can fix it in a per application basis. You have only to go to IIS Manager, select your application, double click in modules and delete ServiceModel version 3.0 module.  If you need version 3.0 again or delete 4.0 accidentally you can fix it adding the module again, using the strings below to register the asemblies. ServiceModel - System.ServiceModel.Activation.HttpModule, System.ServiceModel, Version=3.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089 ServiceModel-4.0 - System.ServiceModel.Activation.ServiceHttpModule, System.ServiceModel.Activation, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35 Enjoy :)

Como resolver o erro: Não foi possível carregar o tipo System.ServiceModel.Activation.HttpModule do assembly System.ServiceModel, Version=3.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089. Alguns recursos / módulos e assemblies do .net causam conflitos entre as versões. Esses conflitos são causados pelo IIS, que "Não sabe" qual a versão correta  do assembly carregar, mesmo se o application pool está configurado com a versão correta. Felizmente essas configurações podem ser corrigidas em cada application no IIS. Esse erro especificamente é causado por um conflito entre as versões 3.0 e 4.0 do assembly ServiceModel. Se sua aplicação é em .net 4.0 ou 4.5 e você obteve este erro ao tentar abrir um webservice vá ao IIS (Painel de controle / Ferramentas Administrativas / Gerenciador do Serviços de Informações da Internet (IIS) ), abra o seu site, de um duplo clique em módulos. Delete o módulo ServiceModel, deixando apenas o ServiceModel-4.0. Caso você

Em uma certa aplicação que eu fiz, um programa windows forms deveria fazer upload de um arquivo CSV para uma aplicação WEB para a importação do arquivo. O problema é que esse sistema funcionava em 8 línguas diferentes, então, obviamente, o sistema deveria suportar vários tipos de caracteres (e encodings) diferentes. Além disso o CSV era ou montado por um usuário, exportando do excel, ou exportado por um ERP. Seria impossível impor ao usuário que sempre gerasse um arquivo UTF-8, porque além de não ser obrigado a saber o que é isso, sistemas ERP legados dificilmente exportarão os arquivos nesse formato, e você, em uma empresa pequena, simplesmente não têm como impor que uma empresa como SAP ou Totvs altere seus sistemas para exportar arquivos em UTF-8. O site da web aceitava o arquivo como vinha, fazia uma conversão forçada para o formato padrão (ANSI ISO 8859-1) e importava o arquivo. Conversões forçadas são aquelas que você faz sem saber qual é o formato de origem do arquivo.

Hoje eu programo orientado a objetos. Pelo menos eu "acho" isso. Conheci muita gente que dizia que programava orientado a objetos mas na verdade programava de maneira procedural, orientado a evento ou RAD. Não que as outras metodologias sejam ruins, mas é que muitas vezes elas são a ferramenta errada para se resolver  o problema. Além disso muitos programadores misturam as metodologias combinando o pior das duas em vez de o melhor das duas. Já vi até programadores dizerem que programam orientado a objeto simplesmente porque a linguagem é orientada a objeto, ou pior ainda, porque a IDE tem "objetos" que você arrasta e solta em uma "form" e que você acessa funções (métodos) destes com seu nome e um ".". Meu amigo, isso é RAD e não POO. Embora RAD tenha o seu valor para prototipação e aplicações rápidas e sujas, não é um bom ambiente de desenvolvimento a longo prazo. É uma programação orientada a evento degenerada. Além disso, por mais que a l