Programação em PL/SQL: Guia de Etiqueta
Para escrever um bom código não só em PL/SQL, mas em qualquer outra linguagem existente, não basta apenas ter uma boa lógica. Organização, Comentários e Boas Práticas de programação são necessários para se conseguir não somente uma rotina inteligente, mas também clara e simples o suficiente para que possa sofrer manutenções futuras também por outros profissionais.
Nesse artigo abordarei alguns aspectos práticos para se conseguir esse resultado, além de argumentos que comprovem cada um desses pontos e justifiquem suas utilizações. Não pretendo me aprofundar tecnicamente, mas sim indicar o caminho a ser seguido por aqueles que se interessam em produzir bons códigos ou que estão iniciando agora a sua caminhada profissional.
Já adianto que como todos os meus artigos são baseados em boa parte na experiência que tenho como desenvolvedor, muitos podem não concordar com o que será escrito aqui. Se você for um dos que discordam, peço que comente para que possamos exercer a boa arte da discussão construtiva.
Bom código, Bom Desenvolvedor ?
Uma quase verdade. Um código limpo, claro e bem comentado demonstram habilidades de programação, mas já conheci desenvolvedores excelentes no quesito lógica que escreviam códigos como se apenas eles precisassem entendê-los. Verdadeiros papiros com escritas em aramaico.
Se o desenvolvedor puder incorporar esses dois aspectos, pode se considerar um profissional completo e com um bom futuro profissional onde quer que passe.
Sou adepto e defensor da boa programação. Já comentei isso no meu artigo Microcosmo da TI, onde cito que os código produzidos pelo desenvolvedor fazem parte do seu legado profissional.
Agora chega de divagar e vamos passar a parte prática, começando pelo próximo tópico que com certeza dará o que falar.
Comentários no código
Existe coisa pior do que abrir uma Package, Procedure, Function ou Trigger e ter que decifrar o código para saber o propósito dela ? Não será incomum saber que documentação muitas vezes não é uma opção. Em muitos casos ela simplesmente não existe.
Comentários devem demonstrar o funcionamento básico de um código e dar pistas sobre seu propósito e funcionalidade.
Inicialmente temos o chamado PL/SQL Header:
-- ***************************************************************
-- Description: Describe the purpose of the object. If necessary,
-- describe the design of the object at a very high level.
--
-- Input Parameters:
--
-- Output Parameters:
--
-- Error Conditions Raised:
--
-- Author: <your name>
--
-- Revision History
-- Date Author Reason for Change
-- --------------------------------------------------------------
-- 03 JAN 2007 J.Schmoe Created.
-- *******************************************************Existem vários modelos, mas o mais importante são as informações neles contidas. Eles não substituem documentações ou sistemas de versionamento, mas atuam como apoio aos programadores que irão iniciar um trabalho no código em questão.
Comentários simples também podem ser utilizados para deixar clara a função de partes do código, como no exemplo abaixo:
IF (vUserStatus = ‘A’) THEN
PKG_USER_INFO.USER_ACTIVATE(vUserCode);
ELSE
PKG_USER_INFO.USER_DEACTIVATE(vUserCode);
END IF;No exemplo acima com um código bem normatizado parece simples entender o que ocorre. Mas sem ler o contexto geral do código, como saber exatamente que tipo de usuário ele se refere ? Usuário de sistema ? Usuário do serviço ?
-- A - Ativa ou I - Inativa usuário do plano de acordo com a regra 209 ANS
IF (vUserStatus = ‘A’) THEN
PKG_USER_INFO.USER_ACTIVATE(vUserCode);
ELSE
PKG_USER_INFO.USER_DEACTIVATE(vUserCode);
END IF;Em apenas uma linha temos o domínio dos valores, o tipo de usuário a que se refere e a regra utilizada. A idéia é sempre ser o mais objetivo possível, evitando as obviedades de programação e se concentrando na regra.
Agora imagine esse mesmo código sem um comentário ou normatização:
IF (v_status = ‘A’) THEN
BEGIN
UPDATE USER_PLAN_ANS
SET status = ‘AT’;
WHERE user = v_codigo;
END;
ELSE
BEGIN
UPDATE USER_PLAN_ANS
SET status = ‘IN’;
WHERE user = v_codigo;
END;
END IF;Por incrível que pareça, o código acima é baseado em fatos reais.
Não vou entrar no mérito de lógica de programação nesse ponto, mas espero que os exemplos acima possam ter mostrado o quanto a combinação entre comentários e uma boa programação podem ser positivas para o programador e para o projeto.
Código e Variáveis
Se procurar na internet pelas palavras chaves PL/SQL+Best Practices, é possível encontrar diversos guias de padronização de código e variáveis. Algumas diferem das outras, mas todas tem o objetivo de organizar o código para que ele fique objetivo e organizado.
Abaixo os links para diversos documentos e links sobre padronização:
- Donald Burleson – Burleson Consulting
- Steven Feuerstein – Quest
- Bill Coulam
- Roger Troller – Trivadis
São materiais imperdíveis e que recomendo como leitura obrigatória. Escrito por profissionais do mais alto gabarito e reconhecidos na comunidade.
Você pode escolher seguir um deles, um conceito de cada autor ou até mesmo montar o seu padrão, desde que corresponda aos requisitos mínimos de organização. Algumas empresas também possuem seu próprio padrão de código e solicitam muitas vezes que ele seja seguido.
Abaixo um exemplo minimalista de organização de código:
--***************************************************************
-- Função para retornar a idade
--
-- Input Parameters: pDataNascimento DATE
--
-- Output Parameters: NUMBER
--
-- Error Conditions Raised:
--
-- Author:Sergio Willians
--
-- Revision History
-- Date Author Reason for Change
-- -------------------------------------------------------------
-- 19 FEV 2013 Sergio Willians Criado
--***************************************************************
CREATE OR REPLACE FUNCTION func_calcula_idade(pDataNascimento DATE) RETURN NUMBER IS
vIdade NUMBER;
BEGIN
-- Calcula o número de Anos
vIdade := TRUNC(MONTHS_BETWEEN(SYSDATE,pDataNascimento) / 12);
RETURN(vIdade);
END;Em uma função tão simples, parece desperdício colocar tanta informação, mas quando falamos de Packages complexas com centenas ou milhares de linhas de código, esse tipo de informação se torna preciosa e economiza horas de trabalho.
Se você quiser exemplos de como não montar um código PL/SQL, sugiro acessar o GLUFKE.net através do link abaixo:
http://glufke.net/oracle/viewforum.php?f=24&sid=d66b11a402623b0eda3f5745e4e025b7
Esse excelente fórum sobre tecnologia Oracle, possui uma seção só com ‘aberrações‘ vindas dos mais profundos cantos escuros da alma de um desenvolvedor. Se um dia existir um manual de como não se programar, ele será baseado nos casos encontrados lá.
Otimização de SQL
“Tuning é coisa de DBA”. Perdi a conta de quantas vezes já ouvi essa frase. Sabemos que os DBAs possuem ferramentas que dão informações cruciais para o tuning ou mesmo reescrevem a query automaticamente. Só que esses fatos não eximem o desenvolvedor de aplicar ao menos boas práticas na construção de pesquisas SQL.
Detalhes como uso de bind variables, alias, substituir NOT EXIST por sub-queries ou outer joins, não misturar datatypes, são práticas simples que julgo de conhecimento e implementação obrigatórios. Todo bom desenvolvedor tem o dever de aplicar essas práticas.
Como exemplo, recorro mais uma vez a Don Burleson e seu excelente site. O link abaixo explica de maneira simples essas aplicações:
http://www.dba-oracle.com/art_sql_tune.htm
Conclusão
O Desenvolvedor não é um conversor ou tradutor de especificações apenas. É preciso conhecimento e competência para se construir um código inteligente e claro. A boa codificação pode ser considerada um estado da arte.
Espero que com esse artigo, tenha conseguido mostrar o caminho para se alcançar um nível de proeficiência adequado ao esforço para se alcançar esta excelência.
Se você tiver uma opinião contrária, ou mesmo algo a acrescentar, peço que comente este artigo.
Abraço