
Recentemente alguns site e blogs vêm divulgando listas de dicas para se codificar em javascript, apresentando melhores práticas de desenvolvimento e muitas dicas bacanas. Pensei que este seria um bom tópico para se estender e compartilhar com vocês. Neste artigo, reúno as minhas top 10 dicas e boas práticas para codificação javascript. Espero que gostem.
O propósito do defer é avisar o script que está sendo requisitado externamente para esperar até que a página seja carregada ou o DOM esteja preparado. O mesmo pode ser realizado através de bons métodos não-obstrutivos via javascript, que usualmente inclui códigos que previnem a execução de scripts antes que o DOM seja carregado por completo.
A vantagem do defer ocorre quando utilizamos o Internet Explorer, tendo em vista que é único browser que suporta o atributo defer. Então, se você precisa de um rápido script que rode única e exclusivamente no Internet Explorer, e você não quer que ele execute antes que o DOM esteja preparado, então simplesmente adicione defer="defer" na sua tag <script> e ela irá rapidamente tratar o seu problema. Corrigir a transparência de arquivos PNG no IE6 é uma das possibilidades práticas do uso do defer.
(Edit: O atributo defer deve ser usado quando escondemos um script de outros browsers com o uso dos comentários condicionais - conditional comment - que afete somente os navegadores da Microsoft - de outra maneira o script vai rodar normalmente em outros browsers.)
Muitas vezes seus scripts vão residir em arquivos externos e chamados dentro da tag <script> dentro do <head> do documento, ou então antes do fechamento da tag </body>.
Mas este documento pode estar eventualmente sendo usado em um local que junto dele existem marcações HTML, como abaixo:
<div>
<p>
<script type="text/javascript">
var my_variable = 100;
if (my_variable < 50) {
// alguma coisa aqui...
}
</script>
</p>
</div>Você pode notar que no código acima, dentro do if, existe o símbolo < que representa "menos", que é parte da sintax, correto? Este símbolo causa um erro de validação. O validador interpreta ele como um início de uma marcação ou uma tag HTML que não foi fechada, a não ser que você encapsule o seu código com o CData, assim:
<div>
<p>
<script type="text/javascript">
//<![CDATA[
var my_variable = 100;
if (my_variable < 50) {
// alguma coisa aqui...
}
//]]>
</script>
</p>
</div>Muitas palavras são reservadas no javascript, então você deve evitá-las quando forem criar variáveis ou outros idenficadores. A lista completa de palavras-chaves do javascript segue abaixo:
break
case
catch
continue
default
delete
do
else
finally
for
function
if
in
instanceof
new
return
switch
this
throw
try
typeof
var
void
while
withQue estão também algumas palavras reservadas, que não estão necessariamente sendo usadas pela linguagem mas são reservadas para o uso futuro. São estas:
abstract
boolean
byte
char
class
const
debugger
double
enum
export
extends
final
float
goto
implements
import
int
interface
long
native
package
private
protected
public
short
static
super
synchronized
throws
transient
volatileNo javascript, tecnicamente, isso é perfeitamente legal:
var my_variable = "Esta é uma string";
my_variable = 50;Depois que a variável é inicialmente declarada como string na linha 1, na linha 2 o seu valor é mudado e o seu tipo também. Esta não é uma boa prática e deve ser evitada.
Para preveinir possíveis conflitos, em 99% dos casos, use o "var" no início quando estivermos declarando uma variável e seu valor. Isso faz com que a sua variável exista somente no escopo da função e não fora dela, ou seja, toda variável criada pelo var só poderá ser acessível dentro do escopo no qual ela foi declarada e não mais fora dele. Então, se acontecer de você utilizar duas variáveis com o mesmo valor em lugares diferentes do seu script, nenhum conflito ocorrerá.
Lembre-se do que vem a seguir: No código que segue temos duas variáveis que estão armazenando seus valores em 2 lugares diferentes na memória, e não um só, como alguns podem pensar. São duas variáveis completamente diferentes alocadas em lugares diferentes na memória:
var myVariable = "data";
var myvariable = "more data";Não faça isto:
if (example_variable == "cyan") {
// faça algo aqui...
} else if (example_variable == "magenta") {
// faça algo aqui...
} else if (example_variable == "yellow") {
// faça algo aqui...
} else if (example_variable == "black") {
// faça algo aqui...
} else {
// faça algo aqui...
}Faça isto:
switch (example_variable) {
case "cyan":
// faça algo aqui...
break;
case "magenta":
// faça algo aqui...
break;
case "yellow":
// faça algo aqui...
break;
case "black":
// faça algo aqui...
break;
default:
// faça algo aqui...
break;
}O segundo bloco de código faz exatamente a mesma coisa que o primeiro, mas o segundo é limpo, fácil de ler, fácil de dar manutenção e modificar.
Encapsulando todo o seu código no try-catch, você pode evitar que o usuário final nunca veja um feio erro de javascript exposto na tela. Assim:
try {
funcaoQueNaoExiste();
} catch (error) {
document.write("Um erro ocorreu.")
}No código acima, eu tentei chamar uma função que não existe, para forçar um erro. O navegador não vai exibir o típico erro "not an object" ou "object expected", mas ao invés disso, vai exibir um erro mais customizável que eu incluí dentro do meu "catch". Você pode também deixar o catch vazio para nada ser mostrado para o usuário, ou você pode criar uma função que seja chamada dentro do catch que faça o tratamento deste erro para propósitos de debug etc.
Mantenha na sua cabeça que isso pode esconder erros do desenvolvedor também, então uma boa documentação do código e comentários podem ser úteis neste ponto.
Em javascript, você pode comentar uma linha de código colocando um // no início da linha. Você também pode criar um comentário em bloco como mostra a seguir: /* [comentário aqui ] */. Algumas vezes você precisa incluir um comentário longo, um comentário de mais de uma linha. Um bom método para se utilizar que não tenha uma visual esmagador, mas é fácil de identificar o código é este a seguir:
/*
* Este é um comentário multi-linha...
* bla bla bla...
* bla bla bla...
* bla bla bla...
* bla bla bla...
*/E é isso!
*
Este artigo é uma adaptação e tradução do texto: 10 JavaScript Quick Tips and Best Practices
Idemax Adobe Flash Plataform Developer
Só acho que sobre o CDATA é irrelevante pois a melhor prática é estruturar tudo em um arquivo externo (.JS), e para melhorar, usar algum framework (mootools, jquery, etc...) que você possa estruturar seu código em forma de classes. Deixando tudo mais organizado, tipado e fácil de atualizar e manter.
Igor Escobar
Um dia você vai precisar dele, senão, você viveu pouco.
11closed Wdclosed
Concordo com o Idemax, também utilizo esta maneira.
Mas é sempre bom que tenha mais opções!
Gostei do seu artigo parabens
felipe huggler
Nao use Eval
Nao use new Function...Ex: var c = new Function
Nao use with
Nao use try catch dentro de loops for { try{}cathc }
Nao use variaves globais
Nao use setTimeout passando funcão setTimeOut(funcao(), )...use setTimeout(funcao, )
Peformance
**************************************
Usar HTML puro é bem mais rapido doque criar os objetos usando DOM
Ex: obj.innerHTML = "<table>" // usar
Ex: document.createElement("table") // naum usar
*******************************************************
/* Forward loop */
var i = 0;
while ( i < length ) {
i++;
}
/* Use Loop Reverso (mais rapdio) */
var i = length;
while (i--) {
/* nao precisa incrementar; */
}
Utilize concat para concatenar // "aos inves de a + b"
var a = 'boas práticas';
var b = 'Javascript';
document.write(a.concat(b));
Fernando Nishino
Do 3 ao 10 achei meio óbvio.
Agora o 1 e o 2 não cheguei a usar muito, não posso comentar sobre esses dois.
Thiago Retondar
Muitos dizem que o ideal é colocar o arquivo.js dentro de <head> - que é o que eu faço -, outros dizem que o ideal é no fim da página, antes de </body>. Mas qual é o certo? Ou os dois são certos?
2001 - iMasters FFPA Informática Ltda - Todos os direitos reservados.