Qual é a coisa mais importante em um código? E por que é a elegância?

[Skyen 64]

Obs.: Eu sei que esse tutorial é quase uma trilogia, mas não desanime, tente ler até o final, você pode aprender muita coisa nova! Se você não quer ler tudo, pule a parte de escopo e identação, pois é a parte mais complexa. Recomendo voltar depois e tentar entender identação e escopo.

 

Você está jogando Tetris quando um desconhecido te chama e pede para arrumar um script dele que não está funcionando direito. Aparentemente, os players estão ficando irritados porque o servidor está respondendo "Hell, world!" para eles, quando deveria estar respondendo "Hello, world!".

 

Você diz "tudo bem", o cara te manda o script, e você se depara com isso:

 

_,__,___,____=string.char,print,type,"fu"
.."nction"if(___(__)==____)then __(_(0x48
,0x65,0x6c,0x6c,0x2c,0x20,0x77,0x6f,0x72,
0x6c,0x64,0x21))  --[[Hello, world!]] end

 

Se você sentiu um pingo de vontade de ler o código, exceto por curiosidade, seu nome é Mock.

 

O erro mais comum que eu vejo sendo cometido por iniciantes não é nada relacionado à sintaxe, lógica da programação ou consumo excessivo de fungos pluricelulares. É a elegância (Ou melhor dizendo, a falta dela). Não me interessa se seu código deixa o Tibia 4D com Intel® Tesselated 256x Clockwise Polygoned RealExtreme™ Greener Foliage e nunca deu um bug. Se ele não for no mínimo agradável de ler, eu vou jogar fora, e sentir pena da lixeira.

 

90% das vezes que eu digo para algum iniciante deixar o código mais bonito, eles me respondem que "só eu vou ler mesmo, cara, não vou ficar me preocupando com isso". Isso é a mesma coisa que limpar a bunda sempre com o mesmo papel porque você não é homossexual e não precisa da* * *****.

 

Nas outras 10% das vezes, a pessoa fica offline e nunca mais aparece.

 

Devaneios à parte, vamos ao que interessa:

 

Por que a característica mais importante de um código é a elegância, e como deixar seu código elegante?

Começando do princípio: Para escrever um código, o programador precisa ter na cabeça a abstração de uma solução para o problema em mente. Se você não entendeu, isso apenas significa que se você quer escrever um script que faça X coisa, você tem que ter na cabeça uma ideia para fazer a coisa X acontecer através de um código. Se você é distraído por algo, ou para de programar na metade do código, ou está com muito sono, essa ideia vai se perdendo e você tem que pensar nela novamente depois.

 

Veja o problema do "Hello, world!" acima. Imagine que aquele código é seu, e você achou que ele estivesse funcionando, mas agora percebeu o bug e quer consertar. Só que já faz tempo que você fez o script e não tem mais em mente a ideia que usou para escrever ele à muito tempo atrás. A ideia se perdeu, e o único modo de relembrar ou descobrir a ideia de um código é, bem, lendo ele...

 

Se você ainda tem a ideia em mente, ler um código como aquele ali em cima é muito fácil: parece óbvio para você o que ele faz, pois afinal, você acabou de escrevê-lo! Só que não é bem assim que funciona se você já não lembra de como fez o código, vai ser muito difícil ler um código grande todo mal-feito como aquele ali em cima, e o trabalho de arrumar o código é muito mais complexo.

 

Caso você estivesse na situação de ter que arrumar o código do "Hello, world!", qual código você iria preferir arrumar? O de cima ou este aqui:

 

print("Hell, world!")

 

O problema piora se você não sabe como arrumar o bug e precisa de ajuda de alguém. Se você enviar um código todo mal-feito para alguém te ajudar, é bem provável que a pessoa nem vá ler seu código, dar uma desculpa e se safar de ter que ver tamanha aberração (Aos que estão se perguntando: sim, eu faço isso).

 

Ou seja, enfie na cabeça de uma vez por todas que mesmo que seu código jamais vá ser lido por outra pessoa, é importante que você faça ele de forma elegante.

 

É muito chato ter que enfeitar o código depois que ficou pronto? Você está fazendo algo muito errado!

Se você faz o código todo para depois deixar bonitinho, fique sabendo que essa é uma péssima ideia. Você não tem que deixar bonito depois de pronto, e nem antes de começar, você tem que ir aplicando a elegância justamente enquanto escreve o código!

 

Não faz sentido escrever um código feio para depois enfeitar. É a mesma coisa que parir o Hitler e deixar ele mais bonitinho com maquiagem e lacinhos. Acostume-se à escrever um código naturalmente bonito.

 

 

A parte que realmente interessa: Como deixar seu código bonito!

Identação

A primeira coisa que me vem em mente quando alguém fala em código bonito é a identação. Identação é o espaço horizontal que separa as linhas de código da borda da esquerda. Veja um exemplo de código identado abaixo. Em azul é o espaço da identação, geralmente feito com a tecla tab:

 

 

Além de mais bonito, fica extremamente mais simples ler um código identado. Ela é tão importante que na linguagem Python a identação não somente é obrigatória, como também é parte da sintaxe.

 

Existem muitos iniciantes por aí que não sabem identar, mas adicionam espaços antes das linhas para copiar o código de outra pessoa e acabam fazendo tudo errado. Isso atrapalha tanto quanto um código não identado, se não piorar.

 

Escopo

Para aprender a identar corretamente, primeiro você deve entender o que é um escopo. A explicação abaixo não serve apenas para embelezar seu código, mas também é um conceito fundamental para programar, não apenas em Lua, mas em diversas outras linguagens de programação, então é importante que você leia mesmo se quiser fazer códigos feios (Afinal, a opção é sua, só não sei por que você chegou até aqui no tutorial se quer fazer um código feio).

 

Escopo tem tudo à ver com variáveis locais e globais.

 

A definição informal de escopo é: Até que ponto as variáveis locais podem ser alcançadas. Obviamente você não vai decorar isso, então vamos explicar de um jeito que você entenda:

 

Quando você declara uma variável dessa forma em Lua, ela é uma variável global:

 

x = 1

 

Significa que ela pode ser acessada de qualquer lugar no seu código! Emocionante, não é?

 

Não. Você não deveria estar fazendo isso à não ser em casos muito, muito especiais, e só quando você sabe o que está fazendo. Variáveis globais tem seus usos, mas são perigosas se você não usá-las corretamente. Isso acontece porque variáveis globais podem dar conflito com outras variáveis. E pior, em um lugar que não tem nada a ver com a paçoca.

 

Por exemplo, você tem dois scripts completamente diferentes: Um deles é uma alavanca que abre uma porta e o outro é uma pedra que teleporta. Completamente diferentes. Exceto por uma coisa: ambos possuem a variável "pos", e o inútil escritor desses scripts cometeu o grandíssimo erro de não usar variáveis locais quando necessário. Veja:

 

alavanca_que_abre_uma_porta.lua:

pos = {x=100, y=100, z=7}

 

pedra_que_teleporta.lua:

pos = {x=200, y=200, z=8}

 

Quando o Lua abre o primeiro script, ele registra a variável global "pos" com o valor 100x100x7. Quando o Lua abre o segundo script, ele registra novamente essa variável com o valor 200x200x8. O resultado é bem óbvio, existe apenas uma variável "pos" usada pelos dois scripts com o valor 200x200x8, que é válida para a pedra que teleporta, mas completamente inválida para a alavanca que abre uma porta!

 

Para criar uma variável local, basta adicionar a palavra "local" antes do nome da variável. Tornando a variável "pos" local, vão existir duas variáveis locais "pos", uma para cada script, e cada uma com seu valor:

 

alavanca_que_abre_uma_porta.lua:

local pos = {x=100, y=100, z=7}

 

pedra_que_teleporta.lua:

local pos = {x=200, y=200, z=8}

 

Problema resolvido. Agora mesmo que as variáveis possuam o mesmo nome, cada script tem a sua, e elas não irão conflitar, pois cada uma tem seu valor.

 

Variáveis globais tem seus usos. Por exemplo, caso você precise trocar informações entre dois scripts diferentes. Porém, se precisar usar variáveis globais, escolha um nome que você tem certeza absolutíssima de que não causará conflito com nenhuma outra variável.

 

Mas isso não é tudo o que há para falar sobre variáveis locais. Elas possuem uma propriedade muito interessante, veja:

 

if true then
local var = "Hello, world!"
end

print(var)

 

O que você acha que o print vai escrever? Se você disse "Hello, world!", você errou. E errou feio.

O print vai escrever "nil". Curioso, não?

 

Na verdade, é algo muito óbvio. A variável "var" é local, e foi criada dentro do "if". Isso significa que ela é local dentro do if, e que fora dele, ela não existe. Quando o "if" atinge seu "end", todas as variáveis locais dentro dele são destruídas. Em outras palavras, o print não consegue encontrar a variável "var", pois ela só existe dentro do "if"!

 

Agora vamos ver um caso diferente:

 

if true then
local var = "Hello, world!"

if true then
	print(var)
end
end

 

O que você acha que o print escreve? Você provavelmente acertou essa, agora. A resposta é "Hello, world!". A variável local existe, sim, apenas dentro do primeiro "if". Porém, o segundo if está dentro do primeiro, então a variável var continua existindo. Ela só será destruída quando o primeiro "if" atingir seu "end".

 

Vamos complicar as coisas um pouquinho.

 

local x = 10

if true then
local var = "Hello, world!"

if true then
	local var = "Goodbye, world!"

	print(var)
	print(x)
end

print(var)
end

 

Uma variável local "x", duas variáveis locais "var", três valores diferentes, três prints. O que você acha que cada um escreve?

A resposta é: o primeiro escreve "Goodbye, world!", o segundo escreve "10", e o terceiro escreve "Hello, world!".

 

Epa, mas pera aí, a segunda "var" não dá conflito com a primeira, reescrevendo o valor dela?

Não. Isso acontece porque a primeira "var" continua existindo no primeiro "if" quando a segunda é criada no segundo "if". Os prints vão escrever o valor da "var" mais próxima do escopo deles.

 

Escopo, como disse antes, é até onde as variáveis locais são alcançadas. Imagine os escopos como degrais de uma pirâmide. Um escopo mais alto pode alcançar todos os degrais mais baixos que ele na pirâmide, mas não consegue alcançar os mais altos. Se fôssemos dar números aos escopos do código acima:

1. Escopo global (Fora dos dois "if"s).
   
2. Dentro do primeiro "if".
   
3. Dentro do segundo "if".
   

 

E por que o segundo print escreveu o "x" do primeiro escopo? Porque é como se Lua fosse descendo os degraus dos escopos até achar o que procura. Se não achar, retorna "nil". Por isso, também, o primeiro print escreve a segunda "var", e não a primeira.

 

Vamos complicar mais uma vez:

 

if true then
local var = "Hello, world!"

if true then
	var = "Goodbye, world!"

	print(var)
end

print(var)
end

 

E agora, o que cada print escreve?

O primeiro escreve "Goodbye, world!", e o segundo... também!

 

Observe bem, a segunda "var" não tem a palavra "local" antes! Você deve estar pensando que a segunda "var" é global, mas esse não é o caso. Se eu colocar mais um print, fora dos dois "if"s, ele vai escrever "nil"!

 

Mas que magia negra está acontecendo aqui agora?

É bem simples. Quando a palavra "local" é usada, você está dizendo à Lua "crie uma variável local aqui!". Quando você não usa, você está dizendo "substitua o valor da variável no escopo mais próximo por este valor!", e então Lua vai procurar a variável "var" no escopo mais alto (mais próximo ao topo, onde o código está), e substituir seu valor. Se nessa descida da piramide Lua não encontrar a variável que você quer, então ela criará uma variável global!

 

Ou seja, naquele código acima, se não existisse o primeiro "var", o segundo "var" seria global!

 

A última coisa que você precisa saber sobre escopo é que todo todo "repeat", "while", "do", "for", "if", "elseif", "else" e "function" abre um novo escopo, e todo "end" e "until" (No caso do "repeat") fecha o escopo mais alto da "pirâmide", destruindo todas as suas variáveis locais.

 

Voltando à identação

Agora que você já sabe usar variávies locais em toda sua maestria... Okay, eu sei, talvez ainda esteja confuso demais e você não tenha entendido tudo, mas não se preocupe! Talvez demore um tempo para você assimilar o que é o escopo e variáveis locais, e como aproveitar isso no seu código, isso vem com a prática. Mas continue acompanhando, pois identação é uma coisa muito simples!

 

A vantagem imediata da identação é que você consegue enxergar exatamente quais são os escopos. Fica simples ver que tal print está dentro de tal "if", já que o print está com um nível a mais de identação.

 

Antes que você comece a sair por ai distribuindo espaços aos seus códigos, há algumas coisas a considerar sobre a identação.

 

A identação pode ser feita com "hard tabs", espaços ou "soft tabs". A identação com um hard tab é exatamente um caractere de tab. É quando você aperta a tecla tab do teclado (Fica em cima do "caps lock", representada por duas setinhas) e o seu editor adiciona um único caractere. A identação por espaços usa a tecla de espaço ao invés do tab para adicionar o espaçamento. É praticamente inviável, já que pra adicionar uma identação adequada você teria que apertar a tecla espaço umas 12 vezes. Os soft tabs são uma mistura dos dois estilos. Quando você aperta a tecla tab, ao invés de adicionar um único caractere de tab, o editor adiciona um determinado número de espaços. É como se você apertasse a tecla de espaço várias vezes.

 

Muitas pessoas preferem usar soft tabs, muitas outras preferem hard tabs. Isso é um debate que dá longas horas de discussão para programadores experientes. Cada um tem suas vantagens e desvantagens.

 

Vantagens do Hard Tab:

• Seu tamanho pode ser alterado editando as preferências do editor de texto.
  
• É mais fácil controlar o nível de identação, uma vez que é composto de um único caractere.
  

Desvantagens do Hard Tab:

• Alguns editores zoam o caractere de tab, tornando a identação totalmente errada, mesmo que tenha sido feita corretamente. Esse é o caso do OTScriptLive!, muito usado para programar para Open Tibia. Se você usa OTScriptLive!, considere trocar de editor. Existem muitas alternativas ótimas, como SciTE, Notepad++, gedit...
  

Vantagens do Soft Tab:

• Já que é composto de espaços, é garantido que o código seja exibido da mesma forma em todos os editores.
  
• Não tem o problema de editores que zoam a identação, como no Hard Tab.
  

Desvantagens do Soft Tab:

• Seu tamanho não é variável.
  
• O arquivo fica maior, já que cada caractere usado no hard tab corresponde a quatro ou oito caracteres do soft tab (dependendo do tamanho adotado).
  
• Por ser composto de espaços, é extremamente chato remover níveis de identação.
  

A escolha é sua. Se você usa OTScriptLive!, recomendo trocar agora mesmo de editor, pois você não terá suporte a soft tabs e os hard tabs são destroídos pelo programa, tornando a identação correta um desastre. Você terá que fazer a identação com espaços.

 

Eu, particularmente, prefiro hard tabs. É muito mais natural. A maioria dos projetos open source usam soft tabs para garantir que o código fique idêntico em todos os editores, e para um projeto aberto assim, com várias pessoas mexendo, até faz sentido. Mas na minha opinião, isso traz uma série de problemas.

 

Independente de qual for sua decisão, siga sempre esta regra: Nunca, jamais, misture caracteres de tab com espaços.

 

Chega disso, vamos logo aprender a identar!

A identação, diferente do que você deve estar pensando, é uma coisa ridiculamente simples.

 

Tudo se baseia em usar um espaçamento para separar os escopos. A cada escopo criado, adiciona-se um tab a mais à cada linha seguinte. A cada escopo fechado, remove-se um tab de cada linha seguinte. Veja:

 

 

Cada setinha representa um caractere de tab. Toda vez que um escopo novo é aberto (por um "function", "for" ou "if"), as próximas linhas recebem um tab a mais. Toda vez que um escopo é destruído (por um "end"), todas as próximas linhas, incluindo a linha do end, recebem um tab a menos.

 

Se seguirmos essa regra, dá pra perceber que no escopo global (nível 1), as linhas terão 0 tabs. Em um escopo de nível 2, terão 1 tab, e assim por diante.

 

Há um caso especial: "else" e "elseif". Eles funcionam como se abrissem um novo escopo, ou seja, as linhas seguintes recebem o tab adicional, porém a linha do "else" e "elseif" não. Veja:

 

 

O "segredo" da identação é sempre adicionar mais um tab depois de "repeat", "while", "do", "for", "if", "elseif", "else" e "function" e colocar um tab a menos depois de "end" e "until".

 

Outro ponto importante da identação é a de tabelas verticais. Quando você fizer uma tabela que se extende verticalmente, idente seus valores. Nunca coloque o caractere de abertura ({) e fechamento (}) em uma linha que contém um valor, e não idente a linha desses caracteres. Veja:

 

 

Isso é tudo sobre identação. Não deixe para identar depois que o código estiver pronto! Quando você pular uma linha, já adicione os tabs necessários e continue escrevendo. A maioria dos editores adicionam estes tabs automaticamente se você habilitar a opção, mas apesar de ser uma questão de gosto, não recomendo usar este recurso.

 

Se você chegou até aqui e acha que entendeu (A parte de identação ao menos, não vou te culpar se você não entendeu sobre escopo), então você agora sabe identar! Yay!

 

Nem tudo é identação...

Se você achou que identação é a unica coisa que torna um código elegante, se enganou. Porém, daqui pra frente, as coisas serão bem mais simples.

 

Código Frankstein não é legal.

Se você usa variáveis com nomes em português, pode ir parando com Lua agora mesmo e vá programar em G-Portugol. Apesar de ter sido criada no Brasil, a sintaxe de Lua é em inglês e, portanto, não misture inglês com português. Se você não sabe inglês, já passou da hora de começar a aprender.

 

Quem é esse pokémon?

Use nome de váriáveis auto-explicativos, e nunca abrevie, à não ser que a abreviação seja comumente usada, como "tmp" ao invés de "temporary". Ninguém é obrigado a ficar adivinhando o que aquela sua variável "cntplr1" ou "hahahalol" significa.

 

Como faz essa mágica?

Eu acho comentários muito idiotas. Diversos programadores vivem dizendo "explique cada linha de código com um comentário". Isso simplesmente não faz sentido, o código está bem ali. Como disse Linus Torvalds, "Talk is cheap, show me the code". Se o negócio foi bem escrito, qualquer programador que se preze vai entender... Ou não. Existem algumas gambiarras que você precisa comentar. Quando fizer algo que não é tão óbvio assim só de ler o código, comente. Isso é comum em números mágicos, por exemplo:

 

radius = radius + 0.5

 

Por que aquele " + 0.5" está ali? O que ele faz de especial? Isso não dá pra descobrir apenas lendo o código, então comente e explique suas magias negras.

 

Volte para a segunda série.

Isso é um caso sério. Muito sério. Aprendemos na segunda série a sempre usar espaço depois de vígula, mas parece que tem gente que ainda insiste em fazer errado. Custa tanto assim fazer isso:

doSetCreatureOutfit(cid, outfit, -1)

Ao invés disso:

doSetCreatureOutfit(cid,outfit,-1)

?

 

Sempre. Use. Espaços. Depois. Da. Vírgula.

Sim, eu já estou cansado disso.

 

Maria vai com as outras.

Se todo mundo usa o nome de variável "cid" para identificar o Creature ID de algo, siga a moda e use também. Fica confuso tentar entender um código que usa "banana" ao invés de "cid", que é o que todo mundo já está acostumado.

 

Não use parenteses em condicionais!

Os estadunidenses começaram com uma mania chata de colocar parenteses em condicionais, tipo isso:

 

if (x == 10) then

 

Parece que não entenderam muito bem que Lua é Lua, C++ é C++. Não faça isso, à não ser quando estritamente necessário pra evitar ambiguidade em uma condição muito grande. Faça do jeito que Lua foi feito para ser usado:

 

if x == 10 then

 

The KISS Principle.

KISS é uma sigla inglesa para a frase "Keep It Simple, Stupid!", que significa mais ou menos isso: "Faça as coisas da forma mais simples, seu estúpido!".

 

Nunca faça gambiarra quando não é necessário. Sempre faça as coisas da forma mais simples, pois é mais fácil de arrumar bugs e facilita a leitura.

 

Número de linhas não indica qualidade de código!

Esqueça essa história de que quanto menos linhas, melhor. Número de linhas nunca foi indicador de qualidade de código, então JAMAIS, e eu vou dizer denovo, JAMAIS coloque mais de uma coisa na mesma linha. É sério. Nunca faça algo assim:

 

if x <= 0 then return false end

 

Sempre separe cada comando em uma linha, assim:

 

if x <= 0 then
return false
end

 

Programe como se quem ler seu código fosse um serial killer com complexo de fofura.

Não preciso explicar, apenas faça isso.

 

Use vírgula no último elemento de uma tabela vertical.

Veja:

 

local messages = {
"123",
"456",
"789",
}

 

O último elemento, "789", possui uma vírgula no final, mesmo sendo o último elemento da tabela. Sempre faça isso em tabelas verticais, tanto para manter a consistência visual, quanto para evitar que você adicione outro elemento depois e esqueça de colocar a virgula, ocasionando um erro. Não se preocupe, Lua aceita essa sintaxe, mas apenas faça isso em tabelas verticais.

 

Linhas vazias são importantes também.

Deixe algumas linhas em branco para separar partes do código. Elas ajudam bastante na visibilidade.

 

E o mais importante de tudo: Siga um padrão.

Adote um padrão de estilo e siga ele! Se você usa espaço em um lugar, mas não usa em outro, pode ir parando com isso. Sempre mantenha seu código dentro de um padrão que te deixe confortável. Não misture as coisas. Se você fez de um jeito, faça sempre desse jeito.

 

Eis o meu padrão de estilo para a linguagem Lua. Você pode seguí-lo se quiser, ou seguir o seu próprio, mas o importante é que seu estilo tenha uma razão para cada coisa e que você se sinta confortável com ele, e use-o sempre, em todas as ocasiões, quebrando-o apenas em situações muito, muito especiais.

 

Skyen Hasus' Lua Coding Style Guide

Este é meu estilo de código para Lua. Todas as regras aqui foram pensadas antes de serem criadas, então ouso dizer que é um estilo consistente.

 

Use o syntactic sugar para declarar funções.

Faça assim:

function foo()

Ao invés de:

foo = function()

 

Não use espaços para separar o nome da função dos parênteses da lista de argumentos.

Faça assim:

function foo()

Ao invés de:

function foo ()

 

Não use espaços no início ou no final de parenteses, chaves ou colchetes.

Faça assim:

function foo(bar, baz)
x = {"a", "b"}
x[1]

Ao invés de:

function foo( bar, baz )
x = { "a", "b" }
x[ 1 ]

 

Use sempre um espaço antes e depois de operadores binários (dois valores: +, -, *, /, %, =, ==, <=, et cetera...).

Faça assim:

x = a + b * c

Ao invés de:

x=a+b*c

 

A exceção para a regra acima são tabelas de uma linha só.

Faça assim:

x = {x=100, y=100, z=7}

Ao invés de:

x = {x = 100, y = 100, z = 7}

 

Nunca use espaço depois de um operador unário (um só valor: único caso é o operador de negatividade, -).

Faça assim:

x = -a

Ao invés de:

x = - a

 

Use sempre aspas para strings de uma linha só e [[]] para string de múltiplas linhas.

Faça assim:

msg = "And he said: \"Hello, world!\"..."

Ao invés de:

msg = 'And he said: "Hello, world!"...'

 

Use a notação lower_underscore para nome de variáveis e funções. Todas as letras são minusculas e espaços são separados por underscore (_).

Faça assim:

function long_function_name()
long_variable_name = 1

Ao invés de:

function longFunctionName()
longVariableName = 1

 

Use a notação CamelCase para nome de classes. (Apenas quando usar orientação à objetos!)

Faça assim:

Class = {}

Ao invés de:

class = {}

 

Tabs tem tamanho de 8 caracteres!

Faça assim:

if true then
       this_tab_is_8_characters_wide = true
end

Ao invés de:

if true then
   this_tab_is_4_characters_wide = true
end

 

Não use a notação multilinha de comentários. Use a notação de única linha em todas as linhas.

Faça assim:

-- Hello
-- World

Ao invés de:

--[[
Hello
World
]]

 

Finalmente o fim.

Foi um "tutorial" bem longo, mas espero que ajude muita gente à escrever códigos mais legíveis. Se você tem alguma dúvida, ou quer ver se sua identação está correta, ou quer discutir uma regra de estilo, ou ficou confuso em alguma parte e precisa de uma explicação melhor, ou achou algum erro, ou precisa de alguma dica, poste aqui!

 

E não menospreze a beleza de um código, porque a beleza é o fator mais importante. Algo bem escrito é mais fácil de consertar e manter do que algo mal-escrito. Acostume-se a aplicar as suas regras de estilo conforme programa, e não depois que está tudo pronto.

 

E acima de tudo, use um bom editor de texto!

(Sério, parem de usar OTScriptLive!)

(E coloquem espaços depois de vírgulas!!)

 

Editado Janeiro 9, 2013 por Skyen

[Oneshot 732]

Nossa, na boa, Raposa. Que tutorial foda, meu velho.

 

Acho que as duas únicas coisas que ainda não sigo do modo Raposa de programar Lua, é o modo em como declaro nomes de funções e variáveis e o espaçamento que, não consigo evitar, dou entre variáveis em uma tabela.

 

Realmente, fica melhor assim?

 

{x=100, y=100, z=7}

 

O IPB tem um bug sério quanto identação, TAB não é reconhecido aqui, apenas espaços, e por isso quando você cola seus códigos aqui, eles acabam ficando sem identação.

 

Eu uso Notepad++ para programar, e depois de terminar um código, uso a opção TAB para Espaço dele, é bem útil pois contorna o "bug" do fórum

Editado Janeiro 9, 2013 por Oneshot

[Skyen 64]

Nossa, na boa, Raposa. Que tutorial foda, meu velho.

 

Acho que as duas únicas coisas que ainda não sigo do modo Raposa de programar Lua, é o modo em como declaro nomes de funções e variáveis e o espaçamento que, não consigo evitar, dou entre variáveis em uma tabela.

 

Realmente, fica melhor assim?

 

{x=100, y=100, z=7}

 

O IPB tem um bug sério quanto identação, TAB não é reconhecido aqui, apenas espaços, e por isso quando você cola seus códigos aqui, eles acabam ficando sem identação.

 

Eu uso Notepad++ para programar, e depois de terminar um código, uso a opção TAB para Espaço dele, é bem útil pois contorna o "bug" do fórum

 

Acho que arrumei quase tudo o que estava bugado. Realmente esse negócio de tab me encheu o saco. Outro bug dele é que o editor convertia algumas letras maiúsculas com acentos em minúsculas e adicionava um monte de espaços em lugares que não devia. Mas, enfim, acho que tá arrumado.

 

E quanto à tabela, eu passei muito tempo pensando nisso e decidi que assim fica mais legível porque tabelas de linha única contém poucos atributos, e o espaço adicional geralmente ajuda a quebrar uma outra regra que eu sigo mas não adicionei ali pra não complicar: Máximo de 80 caracteres na horizontal.

 

Mas claro, como eu disse, é questão de gosto. Você usa o que te deixar mais confortável.

Editado Janeiro 9, 2013 por Skyen

[Slicer 1070]

kkk realmente muito bom tutorial, bem argumentado e explicado ^^

ahh eu gosto do Live! ter as funçoes ali a mao ajuda bastante... mas esse problema do tab tb enxe muito o saco... eu uso o Scite aki pra abrir bloco de notas e arquivos .xml '--'

 

tive q fazer um trabalho no 1* semestre da facul sobre escopo... ¬¬ deu um trampo fudido fazer trab de 6 pag sobre isso e ainda apresentar kkk

[AlbertEinstein 9]

ahh eu gosto do Live! ter as funçoes ali a mao ajuda bastante

esse aki, é bem melhor que o live

OTM 1.5.3.rar

 

x = 1

 

Significa que ela pode ser acessada de qualquer lugar no seu código! Emocionante, não é?

 

Não. Você não deveria estar fazendo isso à não ser em casos muito, muito especiais, e só quando você sabe o que está fazendo. Variáveis globais tem seus usos, mas são perigosas se você não usá-las corretamente. Isso acontece porque variáveis globais podem dar conflito com outras variáveis. E pior, em um lugar que não tem nada a ver com a paçoca.

 

Por exemplo, você tem dois scripts completamente diferentes: Um deles é uma alavanca que abre uma porta e o outro é uma pedra que teleporta. Completamente diferentes. Exceto por uma coisa: ambos possuem a variável "pos", e o inútil escritor desses scripts cometeu o grandíssimo erro de não usar variáveis locais quando necessário. Veja:

 

alavanca_que_abre_uma_porta.lua:

pos = {x=100, y=100, z=7}

 

pedra_que_teleporta.lua:

pos = {x=200, y=200, z=8}

 

Quando o Lua abre o primeiro script, ele registra a variável global "pos" com o valor 100x100x7. Quando o Lua abre o segundo script, ele registra novamente essa variável com o valor 200x200x8. O resultado é bem óbvio, existe apenas uma variável "pos" usada pelos dois scripts com o valor 200x200x8, que é válida para a pedra que teleporta, mas completamente inválida para a alavanca que abre uma porta!

 

 

eu não sabia disso

 

 

ótimo tutorial, só acho que poucos o lerão inteiro

[Skymagnum 234]

Belo tutorial, eu sempre uso

 

{x = x, y = y, z = z}

 

vou começar a usar

 

{x=x, y=y, z=z}

 

e também vou trocar de programa, estou usando o OTScript Live! ainda, alguém me recomenda um bom?.

Editado Janeiro 9, 2013 por Skymagnum

[AlbertEinstein 9]

Belo tutorial, eu sempre uso

 

{x = x, y = y, z = z}

 

vou começar a usar

 

{x=x, y=y, z=z}

 

e também vou trocar de programa, estou usando o OTScript Live! ainda, alguém me recomenda um bom?.

botei em anexo o que eu uso no post acima

[iunix 41]

Eu aconselho o uso do Notepad++ ou Gedit.

[LuckOake 400]

Nossa, ótimo tutorial. Realmente, tá excelente.

 

Realmente, falta beleza na maioria dos códigos dos novatos hoje em dia, o povo simplesmente ignora a identação, não põe espaço depois da virgula, coloca nomes estranhos em variáveis, etc.

[caotic 393]

Sem comentarios.

Tutorial Aprovado

[LuckOake 400]

Caotic, publica esse tutorial no portal, tá merecendo muito.

[Skyen 64]

Dizem que se você perguntar à 5 programadores qual seu editor favorito, você vai ouvir 7 respostas diferentes. Aos que estão se perguntando qual editor usar:

 

De cara vou dizer qual eu uso, meu favorito: gedit.

Ele é pra Linux, porém funciona no Windows também (mas acho que o modo de tratamento de abas dele no Windows é meio ruinzinho) e no Mac. É de longe o melhor editor que eu já usei. Ele possui suporte à plugins, o que torna ele melhor ainda (Se não me engano tem inclusive um plugin auto-completador, igual ao do OTScriptLive!, pra mostrar as funções). A única desvantagem que eu vejo nele é que ele não possui block folding, um recurso que te permite esconder blocos de código (igual no SciTE), mas já estão implementando isso na nova versão e não é algo realmente necessário.

 

Mas claro, se você não vai com a cara do gedit, existem outras opções (Em minha ordem pessoal de preferência):

• gedit
  Meu favorito. Editor padrão do GNOME e seus derivados. Para Linux, mas funciona em Windows e Mac.
  
• SciTE
  Recomendo para quem está começando a aprender Lua, inclusive Lua não relacionado com Open Tibia. Funciona em Linux e Windows.
  
• Sublime Text 2
  Segundo melhor editor que eu já vi. Realmente muito bom. Funciona em Linux, Windows e Mac.
  
• Notepad++
  É um ótimo editor, mas não vou muito com a cara dele. Questão de gosto, use se preferir. Somente para Windows.
  
• Vim
  Outro editor muito bom, mas não recomendo para iniciantes, é uma ferramenta muito complexa. Para Linux, mas funciona em Windows e Mac.
  
• Emacs
  Mesma coisa que eu acho do Vim. Muito bom, mas muito complexo para iniciantes. Para Linux, mas funciona em Windows e Mac.
  
• OTScriptLive!
  Não recomendo. Possui muitos bugs, e a única real vantagem é o seu auto-completador. Somente para Windows.
  
• Kate
  Já usei algumas vezes, mas não gostei muito. é o editor padrão do KDE. é para Linux, mas não sei se funciona em Windows também.
  
• Komodo Edit
  Já usei uma vez, mas também não gostei. Funciona em Linux, Windows e Mac.
  

 

Se você está acessando uma máquina externa com Linux por SSH, recomendo usar "vi".

 

Se quer hospedar seu código na web, recomendo o site http://pastebin.com/.

 

Se estiver querendo editar código em grupo, recomendo o site http://sync.in/. A desvantagem dele é não possuir syntax highlight nem um compilador/interpretador embutido.

 

Se estiver querendo editar e rodar um código pela web, recomendo o site http://ideone.com/.

 

Se quiser descobrir outros editores de código bons, use o site http://alternativeto.net/. Esse site é um dos mais maravilhosos que existem. Você busca um programa que faça algo e ele mostra alternativas. Vamos supor que você esteja cansado de usar SciTE, por exemplo. Você busca por "SciTE" na barra de busca, e ele exibe programas que fazem a mesma coisa que o SciTE, mostrando em quais sistemas operacionais cada um funciona, quantas pessoas gostaram daquele programa, e et cetera. Você também pode filtrar os resultados para mostrar somente os programas que funcionam no seu sistema operacional, então também é muito bom para achar alternativas de software para Linux dos programas para Windows que não rodam em Linux.

 

Se você precisa de um repositório para armazenar seus códigos com controle de versão, recomendo o https://github.com/. Na minha opinião, a ferramenta git é bem mais simples do que a Subversion, e possui bem menos bugs. Se você preferir Subversion, recomendo o http://code.google.com/.

 

Acho que vale a pena você testar vários editores de código e ficar com aquele que você gosta mais. O que vale é a sua preferência pessoal.

 

Fiquem com essa tirinha do xkcd.

Editado Janeiro 10, 2013 por Skyen

[Oneshot 732]

Não é muito, mas estou destacando o tutorial na seção de Tutoriais. Porque trata de um tema essencial para novos programadores, que é a organização e identação dos códigos.

 

Espero que alguém também o publique no portal.

Editado Janeiro 10, 2013 por Oneshot

[MaXwEllDeN 89]

Na boa Raposa, ótimo tutorial. A galera hoje em dia não se preocupa com a identação e faz os códigos de qualquer jeito, na seção de dúvidas o cara encontra vários scripts com erros simples, que com uma noção de escopo e identação não ocorreriam. Por que você não trás aquelas aulas lá do outro fórum? Sem elas eu creio que não teria despertado em mim a paixão por programação. Espero que postem seu tutorial no Portal

[Haxy 13]

não me importo com o tutorial

 

entrei só pra dizer que to com saudades de vc skyen