Existem muitos tipos de design, como o de produto, o de interiores ou ainda o de interfaces, mas se existe uma característica que muitos deles têm em comum é a tentativa de tornar a vida do usuário mais fácil. Falar de Design do Código no sentido do aprimoramento visual de um código de programação ou de marcação pode soar tanto como loucura, como a vulgaridade de alguém que aprecia esteticamente algo que deveria ser puramente funcional.
Todavia, programar infelizmente ainda é uma skill para poucos, mas ainda assim, há de se pensar no conforto que um ser humano virá a ter ao ler determinado código, pois a atividade de desenvolvimento se torna cada vez mais social, por assim dizer, o que significa que aquilo de alguma forma terá de ser entendido por outros.
Nesse aspecto, o design gráfico tem muito a auxiliar, no sentido de tornar o código fonte limpo e fácil de se entender, elevando a compreensão e acabando assim por melhorar a funcionalidade. Algo aparentemente paradoxal, pois como poderia algo estético levar a uma melhoria de funcionalidade? Bem, responder a esta questão renderia um outro texto. Aos curiosos, sugiro que leiam O Design Emocional, de Donald Norman. E aos que se interessaram pelo conceito, explico melhor neste artigo.
Design do código nas linguagens de programação
Trabalhar de certas formas facilita a produção de um código claro e de fácil manutenção. Desde que não se encare como religião, é sempre bacana buscar estes approaches[1] . Estes não vem diretamente do design, mas convém serem citados:
- Variáveis claras: procure usar variáveis claras e não abreviadas. Já se foi o tempo do MinhaStr_decontrole2 em vez de algo mais legível e humano, como minha_string_de_controle;
- Não se repita (Don’t repeat yourself): prática já conhecida pela sigla DRY, significa evitar o máximo possível a repetição de código, o que muitas vezes pode ser dificultoso, pois geralmente envolve maior conhecimento da língua na qual se está programando, além de técnicas (que podem ser cada vez mais aprimoradas);
- Arquivos grandes são distrativos: claro, todo desenvolvedor já teve aquele projeto super complexo, de prazo curto, que acabou culminando naqueles códigos de 3 mil linhas num único arquivo. E, certamente, nesses momentos, acaba-se dependendo fortemente do recurso de busca por palavra do editor que se usa. Toda linguagem que se preza tem alguma forma de se incluir arquivos externos (require, include). Faça uso, usando de seu bom senso;
- Design do código nas linguagens de marcação: neste terreno, o design brilha de verdade. Há muito a ser melhorado e facilitado nestas linguagens. Mas para tanto, se torna necessária a adição de uma nova camada de processo entre o usuário e o código final em si, ora referida por renderização, ora por compilação. Enquanto muitos desenvolvedores advogam contra esta nova camada, eu particularmente acredito que, ainda que com esse custo (seja da implementação do processo ou de servidor), os benefícios são enormes. O único desafio real deste novo aspecto que emerge dentro do desenvolvimento de front-end é o treinamento dos profissionais envolvidos no projeto, pois estas novas linguagens, apesar de infinitamente mais simples, são desconhecidas em sua maioria.
HTML
<html>
<head>
<title>Meu site de exemplo em HTML5</title>
</head>
<body>
<h1> Bem vindo ao meu site </h1>
</body>
</html>[/html]
O HTML possui uma redundância inerente pela obrigatoriedade de se repetir quase todas as tags duas vezes. É curioso, pois seu ancestral, o GML, criado por três funcionários da IBM nos anos 60 não possuia esta mesma característica. Além disso, apesar de ser uma boa prática a indentação consistente de suas tags, esta frequentemente acaba sendo largada de mão por grande parte dos desenvolvedores. Nesse sentido, o HAML (Haiku Markup Language) surge:
[html]!!!
%html
%head
%title Meu site de exemplo em HTML5
%body
%h1[/html]
Bem vindo ao meu site
As três exclamações iniciais simbolizam o doctype, que será configurado separadamente no sistema. Já as tags, todas obrigatoriamente devem começar com %. Note que elas não precisam ser fechadas, pois o sistema considera a identação como algo estrito nesse caso, interrompendo a renderização do documento caso a indentação esteja inconsistente. Isso pode, na teoria, parecer um defeito, mas na verdade é uma das maiores vantagens, já que assim torna-se obrigatório respeitar a indentação, o por sua vez acaba-se internalizando como regra no desenvolvimento do aplicativo. Note que a quantidade de linhas cai quase que pela metade.
O conteúdo de texto das tags pode ser descrito tanto na mesma linha, quanto embaixo, porém nunca misturando ambos.
Mas por que não remover a porcentagem (%) antes das tags? Pensando nisso, foi criado o Slim, que segue os mesmos preceitos do HAML:
[html]doctype html
html
head
title Meu site de exemplo em HTML5
body
h1[/html]
| Bem vindo ao meu site
Como pode ver, o Slim considera a primeira palavra de cada linha sendo uma tag a menos que comece com um pipe (|). Além disso, ele dá a possibilidade de se usar livremente tags de HTML puro e flexibilidade na quantidade de caracteres de indentação. Ou seja, se você é um cara esquisito e gosta de indentar com dois espaços em vez de um tab, como seres humanos normais e saudáveis, sinta-se à vontade (e perdoe a minha completa arrogância)!
Ok, mas se tratando de textos em si, considere que tenhamos algo como o texto abaixo:
Título: Pangramas
1. Zebras caolhas de Java querem mandar fax para moça gigante de New York.
2. Mas o juiz faz com que whisky de malte baixe logo preço de venda.
Em HTML, seria algo como:
<h1>Título: Pangramas</h1> <ol> <li>Zebras <strong>caolhas</strong> de Java querem mandar fax para moça gigante de<em>New York</em>.</li> <li><p>Mas o <em>juiz</em> faz com que <em>whisky</em> de malte baixe logo preço de venda<p></li> </ol>
Essa intrusão das tags de HTML no meio texto o tornam chato e desumano de ler. Para tal, foi criado o Markdown:
# Título: Pangramas
1. **Zebras caolhas** de Java querem mandar fax para moça gigante de *New York*.
2. Mas o **juiz** faz com que *whisky* de malte baixe logo preço de venda.
Baseado na formatação de emails de texto plano, o Markdown interpreta # como título (## seria h2, ### seria h3 e assim sucessivamente), palavras entre * ou _ como ênfase e entre ** ou __ como strong (itálico e negrito, respectivamente, de acordo com o senso comum da web). Essa sintaxe pode ser misturada com as previamente citadas, tornando assim o HTML algo muito mais compreensível e até mesmo editável por leigos.
Existem outras linguagens que estenderam mais ainda o Markdown, adicionando, por exemplo, tabelas:
Célula 1 | Célula 2 | Célula 3 | ———|———-|———-| Célula 4 | Célula 5 | Célula 6 |
Como é possível ver, este já é mais complexo e envolve bastante formatação, mas dependendo do projeto, também se encaixam (já utilizei uma vez num projeto que necessitava a inserção de tabelas nutricionais).
Existe também o Wiki Markup, que não entrarei em detalhes, mas como o nome diz, é usado primariamente em Wikis.
CSS
Reflita sobre o código à seguir:
[css]article {
color: #02a420;
font: 16px/1.4 Helvetica;
}
article a {
color: #02a420;
}
article a:hover {
color: #ff8855;
}
article a.button {
background-color: #02a420;
background-image: -webkit-gradient(linear, left top, left bottom, color-stop(0%,#02a420), color-stop(100%, #ff4422));
background-image: -webkit-linear-gradient(#02a420, #ff4422);
background-image: linear-gradient(#02a420, #ff4422);
}
/* Para dispositivos mobile */
@media (min-width: 767px) {
article {
color: #02a420;
font: 12px/1.4 Helvetica;
}
}[/css]
Um tanto quanto cansativo de ser lido e entendido, certo? É de fazer qualquer um pensar duas vezes antes de abandonar os editores WYSIWYG (What You See Is What You Get – editores visuais). Não é por menos, o código é altamente distrativo, redundante e cheio de minúcias feitas para serem lidas por um computador.
Bom, mas como podemos melhorá-lo? Para começar, se pudesse aninhar os seletores, como numa linguagem de programação onde por exemplo um if pode conter outros ifs subsequentes. Nesse conceito, entra o SASS (Syntactically Awesome Stylesheets), introduzindo também os mixins que são basicamente funções que tornam o código altamente DRY.
Estes por sua vez, deram a chance para que outros desenvolvedores criassem bibliotecas de mixins, nas quais você pode simplesmente dar um include no começo do CSS. Por fim, o SASS possibilita o uso de variáveis ainda agregando operações matemáticas. É possível até mesmo somar cores ou torná-las mais claras ou ainda transparentes com o uso de funções específicas. Com tudo isso, nosso código CSS poderia ficar assim:
[css]
// importando a biblioteca bourbon
@import "bourbon"
// nossa paleta de cores
$preto: #02a420;
$vermelho: #ff4422;
// mixin que gera a media query
=mobile {
@media (min-width: 767px) {
@content
}
}
article {
color: $preto;
font: 16px/1.4 Helvetica;
a {
color: $preto;
&:hover {
color: lighten($vermelho, 20%);
&.button {
// função incluída pelo bourbon, gera os prefixos de navegador
+background-image(linear-gradient($preto, %vermelho));
}
}
+mobile {
color: $preto;
font: 12px/1.4 Helvetica;
}
}[/css]
Note que, com isso, foi possível introduzir a media query dentro do seletor em vez de fora, o que facilita enormemente a criação de sites responsivos. Ao ser compilado, o CSS terá a media query colocada no final do documento, completamente nos padrões da W3C.
E já que é pra simplificar, reduzindo o nível de distração:
[css]
// importando a biblioteca bourbon
@import "bourbon"
// nossa paleta de cores
$preto: #02a420
$vermelho: #ff4422
// declarando a media query
=mobile
@media (min-width: 767px)
@content
article
color: $preto
font: 16px/1.4 Helvetica
a
color: $preto
&:hover
color: lighten($vermelho, 20%)
// a função lighten() gera um vermelho mais claro
&.button
+background-image(linear-gradient($preto, %vermelho))
+mobile
color: $preto
font: 12px/1.4 Helvetica
[/css]
Essa seria a sintaxe pura do SASS, que se baseia inteiramente na indentação, assim como HAML e o Slim, previamente citados. Muitos desenvolvedores utilizam o SASS, mas na sintaxe SCSS, que é a que ainda preserva as chaves e os pontos-e-vírgulas. Outros são mais radicais e usam o Stylus, que possui mais flexibilidade ainda, como por exemplo mixins transparentes, ou seja, que não possui nenhum tipo de caractere inicial, fazendo-se passar por atributos de CSS completamente normais.
Conclusões gerais
Outra vantagem de se usar esses template handlers – uma camada na sua aplicação que vai traduzir o código de uma linguagem pra outra que o navegador consiga ler – é o fato de que em muitos casos eles emitirão erros que vão lhe impedir de gerar código-fonte inválido. Além disso, dependendo do seu setup, eles podem encodar caracteres em UTF-8, gerar compressão automática de todo código, inclusive de um mesmo arquivo se necessário, reduzindo o número de requisições e o tempo do download.
De 0 a 10, o quanto você recomendaria este artigo para um amigo?