Escrever errado… #atequando?
Nos comunicamos através de códigos e esses códigos são as línguas, que tornam possível interagirmos com outras pessoas. Primeiro, aprendemos a falar e aos poucos vão nos ensinando algumas regras. E existem regras básicas, por exemplo o pronome oblíquo tônico “mim”, que não deve ser usado na conjugação de um verbo, mim não leva, mim não faz, … Mas muitos cometem esse deslize. Depois aprendemos a escrever e várias outras regras que formam a gramática da língua. Com isso temos a possibilidade de espalhar nosso pensamento estando presente ou não. A escrita possibilita e-mails, slides em uma apresentação, comunicar procedimentos, ações ou proibições em placas de trânsito; artigos em jornais, revistas, livros, blogs, … Uma infinidade de possibilidades, até mesmo nos tornarmos imortais.
Uma frase muito comum dita por vários desenvolvedores de software em listas de discussão ou no cafezinho na empresa é: “Não preciso saber escrever, o meu negócio é escrever código”. Isso é uma verdade? Nós desenvolvedores não precisamos saber nos expressar na língua portuguesa escrita? Um desenvolvedor escreve e-mail? Escreve um documento no Word? Ou abre uma thread em alguma lista de discussão? É lógico que sim! Um desenvolvedor de software precisa muitas vezes saber se comunicar por escrito. E precisa fazer isso de maneira extremamente correta para se fazer entender e para isso deve fazer uso das regras gramaticais, ortográficas [tem mais alguma?]. Ou não se vai entender mesmo! Escrever errado só mostra o seguinte: Você já era incompetente no primário ou ficou preguiçosamente vagabundo depois de adulto.
Quem acha que não precisa escrever direito muitas vezes também não gosta de ler. Pergunta para alguém que disse que não precisa escrever direito qual o último livro que ela já leu. Pergunte qual o livro que ela está lendo ou qual livro na área de desenvolvimento ela leu ultimamente e que a ajudou ou que foi interessante. Você vai ficar sem resposta provavelmente. Ler é essencial e, para escrever bem é preciso ler também. A leitura no mínimo serve como a manutenção do nosso aprendizado da língua.
Se você acha que não precisa escrever português direito… como é o seu código?
A maior parte do tempo um desenvolvedor vai escrever, ou pelo menos deveria! Ele não vai escrever a maior parte do tempo e-mails, artigos, posts ou threads de discussão, ele vai escrever código em um língua que o compilador vá entender e depois transformar em uma língua que a máquina vai entender. As linguagens de programação de sua própria sintaxe, regras. Existem palavras reservadas, regras de sintaxe que, se não obedecidas, seu código simplesmente não vai funcionar. As vezes nem irá compilar! Para a sorte de muitos, erros básicos (o “dá pra mim fazer”), da linguagem de programação são pegos pelo compilador, algumas linguagens funcionam diferente.
Indo além, como é a legibilidade do seu código? Não basta só saber usar as palavras reservadas em uma ordem que funcione, é preciso também escrever bem o seu código. Chovendo no molhado, é preciso descrever bem o que você quer dizer com aquele código, o @vquaiato já blogou sobre o assuntou quando estava comentando o Clean Code (aliás: você já leu o livro? 
).
Quando estiver escrevendo um código assim você poderá aplicar Command and Query Separation! O Uncle Bob escreveu apenas uma página no livro, mas acho um assunto bem interessante e tenho procurado colocar isso no meu código. A ideia aplicada em funções é que elas façam alguma coisa ou respondam alguma coisa, nunca as duas ações juntas. Exemplo:
namespace CQS
{
class Program
{
static void Main(string[] args)
{
CalculoAumentoDeSalario calculo = new CalculoAumentoDeSalario();
decimal SalarioComAumento = calculo.CalculaAumentoERetornaSalario(10);
Console.WriteLine("Salário com aumento: {0}", SalarioComAumento);
Console.ReadKey();
}
}
public class CalculoAumentoDeSalario
{
private decimal Salario = 1000;
//...
public decimal CalculaAumentoERetornaSalario(decimal percentualAumento)
{
//...
Salario = Salario + (Salario * percentualAumento / 100);
//...
return Salario;
}
}
}
Repare no código acima que nem tudo o que o método CalculaAumentoERetornaValor vai fazer está explicito no seu nome, para quem lê só a chamada da função vai entender que irá ser calculado o aumento e retornado e não que já irá alterar o valor do salário. Se essa classe que estiver sendo persistida uma conferência de valor, já que para aumentar o cálculo real compreende vários impostos e realmente é preciso uma conferência; o sistema seria comprometido!
Fazendo um refactoring, melhorando nomes, aplicando CQS:]
namespace CQS
{
class Program
{
static void Main(string[] args)
{
Salario salarioFuncionario = new Salario();
salarioFuncionario.AplicaAumento(10);
Console.WriteLine("Salário com aumento: {0}", salarioFuncionario.Valor);
Console.ReadKey();
}
}
public class Salario
{
public decimal Valor { get; set; }
public Salario()
{
Valor = 1000;
}
//...
public void AplicaAumento(decimal percentualAumento)
{
//...
Valor = Valor + (Valor * percentualAumento / 100);
//...
}
}
}
O código ficou mais legível, os nomes refletem melhor o que as funções fazem. Esse é um código de exemplo, alguns nomes ficariam ainda melhores em um código funcional. A função agora realmente só tem uma única função. Faça o teste no seu código!
Obs.: Encontrando algum erro de português nesse post se atenha ao conhecimento, ou seja, faça o que eu digo e não faça o que eu faço. #Bazinga
UPDATE, links úteis:
