O comentário (na programação web) é algo desnecessário ao funcionamento do site. Ele serve apenas para indicar algo a quem está lendo o código fonte ou trabalhando no back-end (por exemplo, em scripts de PHP ou JavaScript). O usuário final não vai ver esses comentários no site, então a utilidade deles é exclusivamente ao programador / web designer.

Um código comentado salva muito tempo quando você for editar algo num site e precisa saber o que você está editando. Por exemplo, um site pode conter várias DIVs dentro de outras DIVs. E pra saber onde que fecha um e abre outro? Código indentado pode ajudar e alguns softwares até indicam qual é a DIV sendo fechada – mas e quando você está usando o bloco de notas só para fazer algumas alterações mínimas?

Outro exemplo seria o uso de comentários nos arquivos CSS; fica mais fácil de encontrar as IDs e classes usadas em determinadas áreas de um site (cabeçalho, barra lateral, menu, etc). Lembre-se que “organização = produtividade”.

Código comentado não facilita apenas a sua vida, mas a de um possível futuro programador ou web designer que precise alterar algo no site.

Se você não usa código comentado, comece a usar! Você talvez não note a diferença na sua produtividade de início, mas veja daqui a um mês quando tiver que editar aquele código novamente.

Você usa códigos comentados nos seus sites? Se não, por quê? Comente!

Aproveite e siga o Design Blog no Twitter! Assim você fica por dentro das novidades no mundo do design, com links super interessantes.

Artigos relacionados

• A internet do futuro tem lugar para web designers?
• Mega sorteio Design Blog e Adobe!
• Design Blog Podcast – Episódio 04

Por que dividir?

Um lado acredita que é interessante dividir arquivos CSS. Assim, fica mais fácil depois de encontrar e editar determinadas partes de um site, ainda mais quando há mais de uma pessoa envolvida na manutenção do mesmo. A divisão é feita de acordo com o gosto do desenvolvedor: um arquivo os comandos de reset, em outro fica o layout, no terceiro a tipografia, e por aí vai.

Outro ponto a favor é poder manter folhas exclusivas de alguma seção inutilizadas quando não necessárias. No WordPress, por exemplo, o estilo dos comentários não precisa ser utilizado até que seja aberto uma página de post (os comentários em blogs não aparecem na página inicial).

No entanto, o lado negativo é o número de server requests (pedidos de servidor) que aumenta com mais arquivos. Isto pode representar um problema em sites com altíssimo número de acessos, fazendo com que o servidor tenha que efetuar múltiplos processos de uma só vez. Claro que isto representa um problema para sites gigantes, com mais de 100 mil acessos únicos por dia. Blogs como este, que tem em torno de 3.000 visitas únicas diárias não sofrem muito com este problema.

Por que não dividir?

Nem sempre dividir o CSS facilita encontrar algo específico. Quando a necessidade de um “find and replace” (procurar por algum valor determinado e substituir por outro toda vez que aparece no arquivo), um arquivo só pode diminuir o tempo da tarefa.

Sem contar que, quando há necessidade de comprimir um arquivo CSS para diminuir o tamanho dele e aumentar a velocidade de download, um arquivo só é mais recomendado – já que múltiplos arquivos significariam múltiplos server requests e por consequência, aumento do consumo de transferência.

Então, qual usar? Separado ou junto?

Vai de cada caso. O site tem uma média de acessos alta? O CSS terá de ser compresso? Todo o código é usado o tempo todo? (ex: não tem páginas diferenciadas, em termos de layout, no restante do site). Neste caso, sugiro usar uma folha de CSS apenas.

Já se existem muitas páginas internas com diferenciação de layout (como aqui no Design Blog, cujo layout muda de cor dependente da categoria de cada artigo), ou haverá múltiplas pessoas tendo que fazer a manutenção do código CSS, o ideal é dividir o CSS metodicamente.

E você, leitor, qual prefere? CSS dividido ou em um arquivo só?

Inspiração

Aproveite e siga o Design Blog no Twitter! Assim você fica por dentro das novidades no mundo do design, com links super interessantes.

Artigos relacionados

• Mantendo seu código organizado
• O que fazer antes de virar freelancer?
• jQuery: o básico que todo designer precisa saber – parte I

Aproveite e siga o Design Blog no Twitter! Assim você fica por dentro das novidades no mundo do design, com links super interessantes.

Artigos relacionados

• Inspiração de segunda – parte 1
• Código comentado salva vidas!
• Inspiração de segunda – parte 5

Aproveite e siga o Design Blog no Twitter! Assim você fica por dentro das novidades no mundo do design, com links super interessantes.

Artigos relacionados

• Inspiração de segunda – parte 2
• Código comentado salva vidas!
• Inspiração de segunda – parte 5

Usar child selectors

Chega de definir regras descentes infinitas para cancelar outras regras. Com CSS2, seletores-filho (ou child selectors) poderemos especificar regras de CSS válidas apenas a filhos diretos, e não descendentes em geral.

Ter uso total de PNGs de 24 bits

Chega de usar imagens adicionais apenas para dar um efeito de sombra, brilho ou semi-transparência. Finalmente vamos poder usar PNGs para dar mais vida aos nossos sites sabendo que isso funcionará em todos os navegadores.

Usar seletores de atributo

Chega de ter que definir classes para inputs – como input class=”text”… – quando podemos inserir isso com seletores de atributo do CSS2 como input[type="text"].

Usar uma gama maior de propriedades de display

Vamos finalmente poder usar coisas como display:inline-block em vez de float:left. Ou seja, chega de float dentro de float dentro de float ad infinitum. E nada mais de usar overflow:hidden para fazer com que blocos se ajustem direito (embora devo lembrar que só conseguimos utilizar isso depois de sair o Firefox 3).

Usar min-width e max-width

Embora a implementação do IE6 de width é bem similar a correta implementação de min-width ainda não chega a ser a mesma coisa e ainda não serve para o propósito correto; além do mais, ele nem reconhece max-width. Com o fim do IE6 pode surgir uma nova renascença em block-layout design, com uma maior flexibilidade que designer estão querendo a anos.

Jogar fora 90% dos hacks de CSS (e 90% das razões pelas quais utilizá-las)

Chega de se preocupar com caracteres repetitivos estranhos, blocos misteriosamente invisíveis ou margens duplas frustrantes. Com o fim do IE6, chega também o fim da necessidade de diagnosticar e curar uma gama tão grande de bugs de rendering.

Adicionar abreviações que todos possam ver

Embora, pessoalmente, eu use apenas o elemento abbr e nunca o acronym ainda fico chateado quando lembro que usuários de IE6 não podem ver a caixinha e fico ainda mais chateado quando a ocasião estranha aparece de eu ter que usar um script para isso (e não consigo achá-lo)

Poder confiar no z-index de novo

Chega de ficar ponderando e batendo a cabeça tentando descobrir por que o layer X está em cima do layer Y quando deveria estar abaixo, tentando adivinhar o que fizemos de errado apenas para lembrar que – duh – não fizemos nada de errado: é um problema do IE6.

Economizar tempo e dinheiro

Menos tempo criando hacks significa menos tempo de desenvolvimento e um custo menor.

Nos divertir de novo

Desenvolver código CSS vai se tornar o trabalho prazeiroso que já foi algum dia. Isto é, até que nossas expectativas sejam elevadas novamente e o IE7 se torne nosso novo inimigo.

Fonte: Sitepoint (traduzido e adaptado por Canha)

Aproveite e siga o Design Blog no Twitter! Assim você fica por dentro das novidades no mundo do design, com links super interessantes.

Artigos relacionados

• Código comentado salva vidas!
• Firefox cancelando uso de prefixos próprios
• O que clientes esperam que web designers saibam

A maioria de nós programa a nossa maneira, devido a alguns vícios de longa data. E isso gera problemas na hora de trabalhar em equipe. Então aí vai umas dicas que você pode implementar desde já nas suas tarefas de programação.

E por que começar agora, mesmo trabalhando sozinho? Para se acostumar. Faz bem.

Indente seu código

Quando você usa o TAB para espaçar seu código, a leitura dele fica mais fácil. Se uma DIV está dentro de outra, faça ele visualmente parecer que está contida lá dentro.

Defina padrões

Na grande maioria das vezes, tudo que vai ficar dentro da tag head vai ser igual a muitas outras páginas de projetos diferentes. Mantenha sempre uma ordem específica neles para facilitar na hora de mudar algo.

Comente seu código

As vezes tento procurar por determinada area do código e não acho. Comentários do tipo “bloco de anúncios vai aqui” ajuda horrores, ainda mais se um leigo quiser mudar algo.

Use nomes óbvios em classes

Evite nomes do tipo “bloco1″ quando for criar uma DIV. “Bloco1″ não significa nada, exceto que é um bloco com um número. Uma DIV com nome “conteudo_principal” já remete a algo mais óbvio.

Comente, não remova

Não é incomum você remover um pedaço de código que pode trazer problemas que você não note de primeira, ainda mais se não foi você que escreveu-o. Deixe aquilo comentado e preferencialmente com uma explicação de porque quis remove-lo.

Separe em pastas

Essa dica é simples: separe os arquivos comuns em pastas. Eu sempre crio uma pasta img para todas as imagens, css para as folhas de estilo, lib para javascript e psd para os arquivos fonte (como as imagens em Photoshop). Facilita a procura por um determinado arquivo.

Nomes padrões para arquivos

Afim de manter um padrâo e facilitar a vida de todo mundo, tente sempre manter um padrão para os nomes de arquivos. Por exemplo, o arquivo CSS padrão pode ser sempre main.css. Evite usar “main” em um projeto, “principal” em outro e “estilo” num terceiro. O mesmo vale para sub-nomes, ou categorias. Eu sempre uso form_proc.php para um script que só irá processar informações de um formulario, db_proc.php para processar um pedido ao banco de dados, etc.

Faça a limpa final

Antes de entregar o site finalizado, faça uma limpa nele; tire os comentários desnecessários, o excesso de espaços em branco (exceto a indentação), insira os nomes dos autores como meta-tag, assm como a data de última alteração e confira se está tudo bonitinho. Faça também os testes básicos (que deveriam ter sido feitos no decorrer do projeto, mas não custa nada tentar de novo).

Essas foram minhas dicas. Não são baseadas em nenhuma convenção ou semelhante. O aconselhável é que você defina seus próprios sempre baseado em linhas lógicas. Assim, quando qualquer um que entenda de programação bater o olho no que você fez, entenderá rapidamente como foi feito.

E você? O que mais faz para manter seu código limpo e de fácil entendimento?

Aproveite e siga o Design Blog no Twitter! Assim você fica por dentro das novidades no mundo do design, com links super interessantes.

Artigos relacionados

• jQuery: o básico que todo designer precisa saber – parte I
• Código comentado salva vidas!
• Design Blog Podcast – Episódio 03