Método com Muitos Parâmetros

Olá, Devs! No universo do C#, frequentemente debatemos sobre quantos parâmetros um método deve ter. Embora pareça um detalhe pequeno, essa decisão afeta diretamente a legibilidade, manutenção e testabilidade do nosso código.

1. Por que usar muitos parâmetros

  • Especificidade: Em algumas situações específicas, ter vários parâmetros é uma necessidade absoluta. Primeiramente, quando estamos lidando com funções que precisam de múltiplos dados de entrada para processar uma lógica complexa, a especificidade fornecida por vários parâmetros é insubstituível. Além disso, eles garantem que cada pedaço de informação necessário seja passado ao método, o que por sua vez facilita sua execução.
  • Flexibilidade: Inicialmente, outra razão para optar por múltiplos parâmetros é a versatilidade que eles trazem. Por exemplo, com diversos argumentos, um único método pode atender a múltiplos casos de uso, o que, consequentemente, torna o código mais reutilizável e modular.

2. Por que evitar muitos de parâmetros

  • Legibilidade: Primeiramente, você deve sempre priorizar manter o código claro e legível. Entretanto, quando você usa muitos parâmetros, os métodos podem se tornar confusos, o que por sua vez dificulta sua capacidade de compreender rapidamente o que um método faz e como ele opera.
  • Manutenção: Cada parâmetro adicional introduz complexidade. Por isso, alterar, adicionar ou remover um parâmetro pode ter efeitos cascata em várias partes do código, consequentemente, aumentando o risco de bugs.
  • Testabilidade: Mais parâmetros significam mais combinações a serem testadas. Isso pode complicar a escrita de testes abrangentes e tornar o processo de testes muito mais demorado.

💡 Solução Estratégica: Se encontrar-se regularmente projetando métodos com muitos parâmetros, reflita. Uma abordagem popular é encapsular dados relacionados em uma classe ou estrutura e passar essa entidade como um único parâmetro. Não só simplifica a assinatura do método, mas também torna o código mais organizado.

method parameters

No mundo da programação, você deve buscar equilíbrio. Embora você possa se beneficiar de múltiplos parâmetros em certos cenários, você deve conhecer as complicações que eles introduzem. Como sempre, você dança entre simplicidade e funcionalidade. Mantenha-se alerta e continue a codificar com sabedoria!

Até a próxima!!!

Comandos Git

git

Olá, Devs!!! Primeiramente, bem-vindos ao nosso guia sobre os Comandos Git. Caso esteja buscando dominar o controle de versão e estar totalmente atualizado, saiba que está no lugar certo. De fato, o Git não é apenas uma ferramenta – representa uma revolução na forma como gerenciamos e colaboramos em projetos de código. Neste post, pretendo abordar os comandos essenciais do Git, com o objetivo de ajudar você a navegar com confiança neste universo.

Afinal, sei que você tem interesse em mergulhar no mundo do GitHub e do Git, não é mesmo? Bem, você está no lugar certo. De fato, o Git é uma das ferramentas de controle de versão mais populares e, por boas razões. Ademais, para enriquecer ainda mais a experiência, temos o GitHub, uma plataforma que não apenas permite hospedar, mas também colaborar e compartilhar nosso código-fonte com o mundo. Então, que tal começarmos do início?

1. Configurando tudo

Primeiramente, antes de fazermos qualquer coisa, precisamos nos apresentar para o Git. Mas por quê? Simplesmente porque, cada vez que fazemos uma alteração, o Git quer saber quem somos. Então, diga ao Git o seu nome usando:

git config –global user.name “Seu Nome”

Ah, e não se esqueça do seu e-mail. Afinal, ele é importante, principalmente se você planeja colaborar em projetos públicos. Use:

git config –global user.email “seu@email.com”

2. Dando os primeiros passos

Ok, agora que nos apresentamos, o que fazemos a seguir? Se você estiver começando um novo projeto, você vai querer inicializar um repositório Git. Isso é bem simples, basta usar:

git init

Por outro lado, se você encontrou um projeto interessante no GitHub e quer uma cópia dele para trabalhar localmente, você vai precisar “cloná-lo”. E adivinhe só? É super fácil:

git clone URL_DO_REPOSITÓRIO

3. Lidando com alterações

Agora, aqui está a parte divertida. Depois de trabalhar um pouco, você notará que fez algumas alterações. E é aqui que a mágica acontece. Primeiro, sempre verifique o status do seu repositório. Acredite, isso se tornará um hábito!

git status

Se você modificou ou adicionou alguns arquivos, é hora de prepará-los para um “commit”. Mas o que é um commit? Pense nisso como uma fotografia de como as coisas estão no momento. Então, adicione seus arquivos:

git add NOME_DO_ARQUIVO

Ou, se você estiver se sentindo aventureiro e quiser adicionar todas as suas alterações:

git add .

Agora, faça um “commit” com uma mensagem significativa sobre o que você fez:

git commit -m “Mensagem do commit”

4. Navegando entre branchs

Talvez você já tenha ouvido falar sobre “branchs” ou ramos. Elas são vias paralelas que permitem testar novidades sem alterar o curso original do seu projeto. Para listar suas branchs:

git branch

E se você quiser tentar algo novo? Crie uma branch:

git branch NOME_DA_BRANCH

E então mude para ela:

git checkout NOME_DA_BRANCH

Ah, e quando estiver pronto para juntar essa branch de volta ao principal? Use:

git merge NOME_DA_BRANCH

5. Sincronizando com o mundo

Então, depois de fazer todo esse trabalho, você vai querer compartilhá-lo com o mundo, certo? Para trazer as últimas alterações do GitHub:

git pull origin BRANCH

E para mostrar ao mundo suas incríveis alterações:

git push origin BRANCH

6. Conectando com repositórios remotos

Depois de dominar os básicos, certamente você vai querer conectar seu repositório local a um remoto, com o intuito de dar a você o poder de colaborar com outros desenvolvedores. Nesse sentido, esse comando une seu espaço de trabalho local a um repositório online, estabelecendo um link essencial para o trabalho colaborativo.

git remote add NOME_REMOTO URL_DO_REPOSITÓRIO

Ah, e se você estiver curioso sobre quais repositórios remotos estão conectados ao seu local, o comando abaixo vai listar todos eles para você, tornando fácil ver e gerenciar suas conexões.

git remote -v

7. Explorando o histórico de fazendo ajustes

Agora, uma das maiores vantagens do Git é poder revisitar e entender o histórico do seu projeto e ter um registro detalhado de cada commit feito, permitindo que você explore as mudanças e entenda a evolução do seu projeto:

git log 

E se quiser ver as alterações específicas de cada arquivo?

git diff

8. Desfazendo e guardando mudanças

A vida é cheia de erros e no desenvolvimento, isso não é diferente. Se você fez uma mudança que não era o que queria e quer descartar as alterações feitas no arquivo especificado, trazendo de volta a versão do último commit então…

git checkout — NOME_DO_ARQUIVO

Talvez, você só queira desfazer a adição de um arquivo à área de staging. Nesse caso, o comando abaixo é seu aliado, removendo o arquivo da área de staging, mas mantendo suas alterações.

git reset HEAD NOME_DO_ARQUIVO

E para aqueles commits que, bem, não deveriam ter acontecido?

git revert HASH_DO_COMMIT

Eventualmente, você pode se encontrar envolvido em uma atividade, mas de repente, necessita alternar rapidamente para uma tarefa diferente, preservando suas alterações atuais. Neste contexto o comando abaixo surge como um recurso indispensável, permitindo que você armazene modificações temporariamente, resultando em um diretório limpo e pronto para receber novos trabalhos.

git stash

E quando estiver pronto para retomar e trazer tudo de volta?

git stash pop

Por último, para manter tudo limpo, organizado e remover todos aqueles arquivos não rastreados e pastas, deixando seu repositório em estado de brilho.

git clean

 

Cobrimos bastante coisa referente a Comandos Git heim?! E olhe, isso é apenas a ponta do iceberg. O Git é uma ferramenta poderosa e quanto mais você o usa, mais truques você aprenderá e se alguma vez se encontrar em apuros, saiba que quase sempre há uma maneira de corrigir as coisas.

 

Boa sorte na sua jornada Git e GitHub!!!

Operador de Coalescência: Como Usar ?? e ??=

O universo da programação em C# é amplo e fascinante. Nele, um dos operadores que talvez não seja tão mencionado quanto deveria, mas que é extremamente útil, é o operador de coalescência. Então, vamos mergulhar nesse tópico e entender como usar os operadores ?? e ??= de maneira eficiente.

Primeiramente, você já se deparou com situações onde é necessário verificar se uma variável é nula (ou null, como diríamos em C#) e, em caso afirmativo, atribuir um valor padrão a ela? Antigamente, isso exigia um bloco de código if-else. No entanto, graças ao operador de coalescência, esse processo se tornou mais elegante e conciso.

1. Utilidade principal

A utilidade principal do operador de coalescência é reduzir a quantidade de código necessária para verificar se um valor é null e fornecer um valor padrão se for.

2. Vamos entender

Vamos considerar o operador ?? inicialmente. Essencialmente, ele verifica se o valor à sua esquerda é null. Se for, ele retorna o valor à direita. Se não, ele simplesmente retorna o valor à esquerda. Por exemplo:

int? valorNulo = null;
int valorPadrao = 10;
int resultado = valorNulo ?? valorPadrao;

Neste caso, como valorNulo é, de fato, nulo, resultado receberá o valor de valorPadrao, que é 10. Contudo, se valorNulo tivesse algum valor, digamos, 5, então resultado seria 5. Isso elimina a necessidade de uma verificação explícita usando if-else.

Além disso, o operador ?? é incrivelmente versátil. Ele não se limita a tipos primitivos. Imagine que você tenha objetos ou até mesmo listas. O operador funciona da mesma maneira, garantindo que você sempre tenha um valor padrão caso a variável verificada seja nula.

Por outro lado, e se quiséssemos não apenas verificar se uma variável é nula, mas também atribuir um valor padrão a ela, caso seja? Bem, a partir do C# 8.0, temos o operador ??=, que combina a verificação e a atribuição em uma única operação.

string texto = null;
texto ??= “Texto padrão”;

Neste exemplo, como a string texto é inicialmente nula, o operador ??= irá atribuir “Texto padrão” a ela. No entanto, se texto já contivesse algum valor, ele permaneceria inalterado. Esse operador, então, simplifica nosso código, tornando-o mais limpo e legível.

3. E sobre a eficiência?

A boa notícia é que eles são tão eficientes quanto os blocos if-else tradicionais, mas com a vantagem de serem mais elegantes e concisos.

Além disso, é crucial mencionar que esses operadores de coalescência são compatíveis com outros operadores em C#. Por exemplo, é perfeitamente válido combinar o operador ?? com o operador ternário ?: para criar expressões ainda mais concisas.

4. Exemplo

operador coalescencia

5. Conclusão

A linguagem C# oferece uma série de ferramentas que facilitam a vida do desenvolvedor. Os operadores de coalescência ?? e ??= são apenas dois exemplos de como a linguagem evoluiu ao longo dos anos para tornar o código mais limpo, legível e eficiente. Assim, ao trabalhar com variáveis que podem ser nulas, lembre-se desses operadores. Eles certamente ajudarão a melhorar a qualidade do seu código e a tornar sua programação diária mais agradável. E como qualquer ferramenta, a prática leva à perfeição. Portanto, sempre que possível, tente incorporar esses operadores em seu fluxo de trabalho e veja a mágica acontecer!

 

Até a próxima!!!

HTTP Status Codes

,http status code

 

Olá, Devs!!!

Quando navegamos na web, frequentemente interagimos com diversos HTTP Status Codes, mesmo que indiretamente. Dessa forma, esses códigos atuam como pontes de comunicação entre servidores e usuários, informando o resultado de uma solicitação.

Além disso, dividimos os HTTP Status Codes em classes, baseando-se no primeiro dígito do código. Por exemplo, cada classe representa uma categoria de resposta. A seguir, listarei os status codes mais comuns e explicarei brevemente cada um:

1. Códigos de Resposta Informativos (1xx)

  • 100 – Continue: O servidor recebeu os headers da solicitação e o cliente deve continuar enviando o corpo da requisição.
  • 101 – Switching Protocols: O servidor concorda em alterar o protocolo conforme solicitado pelo cliente.
  • 102 – Processing (WebDAV): O servidor precisa de mais tempo para processar a solicitação, mas quer informar ao cliente que ele ainda está ativo.

2. Códigos de Resposta de Sucesso (2xx)

  • 200 – OK: Solicitação bem-sucedida. A resposta exata depende do método HTTP usado.
  • 201 – Created: A solicitação foi bem-sucedida e um recurso foi criado como resultado.
  • 202 – Accepted: O servidor aceitou a solicitação para processamento, mas ainda não a concluiu.
  • 203 – Non-Authoritative Information: A solicitação foi bem-sucedida, mas as informações retornadas podem ser de outra fonte.
  • 204 – No Content: A solicitação obteve sucesso, mas a resposta não contém conteúdo a enviar.
  • 205 – Reset Content: A solicitação foi bem-sucedida e o cliente deve resetar a visualização do documento.
  • 206 – Partial Content: O servidor está enviando apenas uma parte dos recursos devido a um cabeçalho de intervalo enviado pelo cliente.
  • 207 – Multi-Status: Resposta que pode conter múltiplos códigos de status para múltiplas operações independentes.
  • 208 – Already Reported (WebDAV): Utilizado para evitar que um cliente receba informações duplicadas.
  • 226 – IM Used: O servidor transformou ou manipulou a resposta a uma solicitação GET para o recurso a partir da representação original.

3. Códigos de Redirecionamentos (3xx)

  • 300 – Multiple Choices: Existem várias opções que um agente de usuário pode seguir.
  • 301 – Moved Permanently: Uma nova URL agora possui o recurso solicitado, que foi movido permanentemente.
  • 302 – Found: Diz ao cliente para procurar (navegar) outro URL. O recurso foi temporariamente movido, mas será realocado de volta no futuro.
  • 303 – See Other: O servidor está redirecionando o agente do usuário para um recurso diferente. A resposta pode ser encontrada em outra URL.
  • 304 – Not Modified: O recurso permanece sem modificações, e o cliente deve utilizar a versão em cache.
  • 305 – Use Proxy: O recurso solicitado está disponível apenas por meio de um proxy, cujo endereço é fornecido na resposta. Por motivos de segurança, muitos clientes HTTP (como Mozilla Firefox e Internet Explorer ) não obedecem a este código de status.
  • 307 – Temporary Redirect: Outra URL recebeu temporariamente o recurso, mas a mesma solicitação original deve acessá-lo.
  • 308 – Permanent Redirect: Similar ao 301, mas indica que não se deve alterar o método e o corpo da solicitação.

4. Códigos de Erro do Cliente (4xx)

  • 400 – Bad Request: A solicitação está formatada incorretamente ou o servidor não pôde entendê-la.
  • 401 – Unauthorized: O cliente precisa se autenticar para obter a resposta.
  • 402 – Payment Required: Reservado para uso futuro.
  • 403 – Forbidden: O servidor entendeu a solicitação, mas se recusa a autorizá-la. O cliente não tem direitos de acesso ao recurso.
  • 404 – Not Found: O recurso solicitado não pôde ser encontrado no servidor.
  • 405 – Method Not Allowed: O recurso solicitado não suporta o método de solicitação usado.
  • 406 – Not Acceptable: O servidor não pode produzir uma resposta que corresponda aos critérios dados na solicitação.
  • 407 – Proxy Authentication Required: Semelhante ao 401, mas o cliente precisa se autenticar para usar um proxy.
  • 408 – Request Timeout: O servidor não pôde esperar a solicitação do cliente.
  • 409 – Conflict: Um conflito com o estado atual do recurso de destino impediu a conclusão da solicitação.
  • 410 – Gone: O recurso de destino não está mais disponível no servidor de origem. O recurso foi removido permanentemente.
  • 411 – Length Required: O servidor exige que o cliente especifique o tamanho da solicitação.
  • 412 – Precondition Failed: Os cabeçalhos da solicitação não atenderam às condições dadas.
  • 413 – Payload Too Large: O servidor se recusa a processar a solicitação porque é maior do que o servidor pode ou é capaz de processar.
  • 414 – URI Too Long: A URI da solicitação é muito longa.
  • 415 – Unsupported Media Type: O formato de mídia dos dados da solicitação é incompatível com o servidor.
  • 416 – Range Not Satisfiable: O intervalo especificado na solicitação não pode ser satisfeito.
  • 417 – Expectation Failed: Pelo menos um dos servidores de entrada não atendeu à expectativa fornecida no campo de Expect header da solicitação.

5. Códigos de Erro do Servidor (5xx)

  • 500 – Internal Server Error: O servidor encontrou um erro e não pode concluir a solicitação.
  • 501 – Not Implemented: O servidor não reconhece o método de solicitação ou não tem capacidade de atender a solicitação.
  • 502 – Bad Gateway: Indica que o servidor, enquanto atuava como gateway ou proxy, recebeu uma resposta inválida do servidor Upstream.
  • 503 – Service Unavailable: O servidor não está pronto para lidar com a solicitação.
  • 504 – Gateway Timeout: O servidor estava agindo como um gateway ou proxy e não recebeu uma resposta a tempo.
  • 505 – HTTP Version Not Supported: O servidor não suporta a versão do protocolo HTTP usada na solicitação.

 

Em resumo, consideramos os HTTP Status Codes como ferramentas cruciais na era digital. Primeiramente, eles orientam e informam, além de facilitar a comunicação entre servidores e usuários. Isso resulta em uma navegação mais fluída e eficaz. Ao entendermos esses códigos, não só melhoramos nossa experiência na web, como também tornamos a resolução de problemas menos desafiadora.

 

Até mais!!!

Domine o Controle de Versão em APIs .Net

Olá, Devs! Vamos entender controle de versão no .Net?

Em um mundo dominado por sistemas interconectados e aplicações que constantemente comunicam entre si, a gestão e evolução das interfaces de programação de aplicações (APIs) é crucial, especialmente quando se refere à API do .Net. Em ambientes de desenvolvimento modernos, o controle de versão desempenha um papel essencial, garantindo que as modificações feitas na API não comprometam as aplicações existentes que a utilizam.

 

1. Importância do controle de versão

Os desenvolvedores geralmente evoluem uma API primeiramente porque querem introduzir novas funcionalidades ou por outro lado, melhorar sua performance. No entanto, se eles não gerenciarem as alterações corretamente, incompatibilidades podem surgir e consequentemente prejudicar sistemas em produção. Dessa forma, no contexto da API do .Net, precisamos de um mecanismo eficiente de controle de versão.

2. Métodos tradicionais e seus desafios

Tradicionalmente, desenvolvedores implementam o controle de versão em APIs através do versionamento por URL ou usando cabeçalhos HTTP. No primeiro método, eles especificam a versão diretamente na URL da API, como em: api/v1/recurso. No segundo, eles indicam a versão em um cabeçalho HTTP, como Accept-Version: v1.0.

Porém, desenvolvedores enfrentam desafios frequentemente. Quando eles incorporam a versão da API à URL, mudanças na estrutura da API podem resultar em URLs desorganizadas. Já o uso de cabeçalhos pode confundir desenvolvedores menos experientes.

3. Soluções que o .Net oferece

Na API do .Net, os desenvolvedores encontram mecanismos refinados para controlar as versões. O .Net introduziu uma biblioteca específica, a Microsoft.AspNetCore.Mvc.Versioning, para simplificar esse processo.

Ao usar essa biblioteca, os desenvolvedores podem especificar a versão da API através de um parâmetro de consulta, um cabeçalho personalizado ou diretamente no caminho da URL. Por exemplo, eles podem fazer uma solicitação assim: api/recurso?api-version=2.0.

Essa abordagem oferece vantagens notáveis. Primeiramente, ela estabelece um padrão uniforme, tornando o versionamento transparente e consistente. Além disso, com essa biblioteca, diferentes versões da API podem coexistir no mesmo endereço, facilitando uma transição suave entre elas.

4. Vamos ver um exemplo?

Considere o desenvolvimento de uma API que gerencia informações de estudantes. Na primeira versão, tem-se um método para obter o nome do estudante. Com o tempo, surge a necessidade de expandir essa funcionalidade, adicionando um método para obter a média de notas do estudante.

Sem o controle adequado de versão, essa nova funcionalidade poderia comprometer sistemas que dependem da versão anterior da API. No entanto, com o uso da biblioteca Microsoft.AspNetCore.Mvc.Versioning, é possível manter ambas as versões funcionando simultaneamente.

Como faço?

Primeiramente, você terá que adicionar a biblioteca Microsoft.AspNetCore.Mvc.Versioning ao projeto. Isso pode ser feito via NuGet Package Manager ou via linha de comando:

Instalação do pacote

Depois de adicionada, configure o serviço:

Configuração do serviço

Aqui, configuramos a API para ter uma versão padrão de 1.0. Se nenhuma versão for especificada na solicitação, ela assumirá 1.0 como padrão. A opção ReportApiVersions informará aos clientes quais versões estão disponíveis.

Crie a Controller de estudantes

  • Para versão 1 da API:

Versão 1.0

No exemplo acima, uma requisição GET para /api/students/1/name?api-version=1.0 retornará “Estudante 1: João Silva”.

  • Para versão 2 da API:

Versão 2.0

Agora, uma requisição GET para /api/students/1/averageGrade?api-version=2.0 retornará “Estudante 1: Média 8.5”.

 

Posso fazer de outras formas?

Sim, você pode decorar a Controller com várias versões de API usando a anotação  [ApiVersion] várias vezes. Isso significa que a controller (ou a ação, dependendo de onde você coloca a anotação) pode atender a múltiplas versões da API.

Se você quiser que o método GetStudentName esteja disponível em ambas as versões “1.0” e “2.0”, você pode fazer o seguinte:

Versões 1.0 e 2.0

Neste exemplo, o método GetStudentName estará disponível para ambas api-version=1.0 e api-version=2.0 .

Se você quiser ser ainda mais granular e especificar versões em nível de ação (em vez da controller), você pode fazer isso também. Por exemplo, você pode ter um método na controller que é específico para uma versão e outro método para outra versão:

Versão para ação

Neste cenário, o comportamento de GetStudentName pode variar dependendo da versão da API solicitada pelo cliente.


Existe também, a anotação [MapToApiVersion] que é usada para indicar explicitamente que uma ação específica em uma controller deve responder apenas a uma determinada versão da API, mesmo se o controlador em si estiver decorado para atender a várias versões.

Vamos ver como isso se aplica no contexto do nosso exemplo anterior:

MapToApiVersion

Neste exemplo, a ação GetVersionSpecificInfo só responderá às solicitações que especificam api-version=2.0,  graças à anotação [MapToApiVersion(“2.0”)]. No  entanto, o método GetStudentName ainda está disponível para ambas as versões “1.0” e “2.0”, já que ele não possui uma anotação MapToApiVersion e a controller em si suporta ambas as versões.

A anotação [MapToApiVersion] fornece uma granularidade adicional, permitindo que os desenvolvedores definam comportamentos específicos para versões diferentes dentro da mesma controller.

5. Conclusão

O uso do versionamento, inicialmente, permite a coexistência dessas duas versões da API no mesmo endereço. Dessa forma, sistemas legados continuem a funcionar normalmente, enquanto novos sistemas ou sistemas atualizados podem optar por utilizar a versão mais recente da API.

Isso ilustra o poder e a flexibilidade do controle de versão na API do .NET, permitindo que os desenvolvedores evoluam suas APIs sem medo de quebrar sistemas existentes.

 

Legal né?!

Atributos Especiais de Informações

Olá, Devs! Primeiramente, quero dizer que hoje vou compartilhar uma dica daquelas e trata-se dos atributos especiais do C#!!!

Pois bem, você sabia que no C# temos alguns atributos especiais que são poderosos quando queremos obter informações sobre quem chamou determinado método? Isso mesmo! Estou falando dos atributos CallerMemberName, CallerFilePath e CallerLineNumber.

Além disso, eles são muito úteis para cenários de rastreamento, depuração e geração de logs.

1. Então, vamos lá! Vem comigo que eu te explico:

– CallerMemberName
Primeiramente, sabe quando você quer saber o nome daquele método que chamou o seu? Pois é, esse atributo te dá essa resposta!

– CallerFilePath
Por outro lado, esse aqui é para os detalhistas! Ele te diz o caminho exato, a localização precisa do arquivo de origem que fez a chamada.

– CallerLineNumber
Agora, imagine se eu te dissesse que há um jeito de saber a linha específica no arquivo onde o chamador fez aquela ligação para o método? É isso que esse atributo faz!

O exemplo abaixo mostra isso, ou seja, o nome do chamador, o path do arquivo e o número da linha sendo gerados, pois passamos como parâmetros do método TraceMessage os atributos CallerMemberName, CallerFilePath e CallerLineNumber.

Atributos Especiais

2. Seguindo em frente, vamos decifrar o código juntos?

1. Temos dois métodos: DoProcessing e TraceMessage.

2. O primeiro, DoProcessing, liga para o TraceMessage só para dizer: “An error happened“.

3. O TraceMessage é o nosso detetive. Via parâmetros ele está preparado não só para ouvir a mensagem, mas também para pegar três informações muito importantes que são: CallerMemberName, CallerFilePath e CallerLineNumber que pega o nome do método ou propriedade chamador, obtém o caminho completo do arquivo de origem do chamador e o número da linha do ponto onde o método foi chamado respectivamente.

E sabe o melhor? O C# faz isso automaticamente pra gente!

4. Finalmente, TraceMessage conta tudo o que descobriu usando o bom e velho Console.WriteLine.

Agora, um segredo entre nós: Não precisa se preocupar em fornecer esses detalhes ao chamar o método. É mágico! O próprio compilador cuida disso pra você. E fique tranquilo quanto à performance, porque isso acontece no momento da compilação, não quando seu código está rodando.

Portanto, meu conselho? Use e abuse desses atributos, especialmente quando estiver registrando informações. Eles te ajudam a saber exatamente de onde veio aquela mensagem ou erro, sem ter que fazer malabarismo pra descobrir.

 

E aí, o que acharam? Estão prontos para mergulhar ainda mais fundo no universo do C#?