boas práticas de programação em genexus - português

08/09/12 Boas práticas de programação em Genexus - Português

1/6wiki.gxtechnical.com/commwiki/servlet/hwiki?Boas+práticas+de+programação+em+Genexus++-+P…

Boas práticas de progra…

Talk Properties History Backlinks Forward links Views

User: anonymous Log in RegisterHome Categories Statistics New Pages Recent Pages To be defined pages User's Groups

Recents:

Boas práticas de programação em Genexus - Português

Versão Original em Espanhol

As boas práticas de programação em Genexus servem para melhorar a compreensão e clareza do código, além depermitir unificar critérios entre vários programadores das empresas.

As boas práticas de programação em Genexus inicia-se baseando que o código é a melhor documentação que umsistema deva ter, por isto também é a melhor ferramenta que um programador tem para compartilhar seu trabalhoaos demais programadores.

Ao Utilizar boas práticas de programação em Genexus o código da Kb obtém um valor agregado já que possui:

Fácil integração e reutilização;Fácil compreensão por parte do programador;Unificação de critérios;Eliminação de zonas obscuras(ocultas) no código;Fácil comunicação entre os programadores;Clareza e código escrito corretamente;Diminuição significativa na manutenção do Software;

As boas práticas de programação em Genexus estão compostas por regras e recomendações:

Regras

01) Ao nomear atributos deve-se utilizar a nomenclatura GIK(GeneXus Incremental Knowledge Base) ;

02) Os atributos deverão ter descrição e Help(ajuda);

Nome: CliCod Descrição: Código do Cliente Help: Identificador do Cliente no sistema.

03) As tabelas devem ter nomes que representem a realidade e não um nome herdado pela transação quea cria.

Transação: Cli2SisPro Tabela: Clientes

04) As variáveis que façam referencia a um atributo devem ser baseadas no mesmo(basead on atribute) eter o mesmo nome do atributo, se a lógica assim permitir.

Atributo: CliCod - C(20) - Código do Cliente Variable: &CliCod - C(20) - Código do Cliente

05) Relatório de Especificação

Considera-se um boa prática que o Analista / Programador Genexus revisem com atenção o relatório deespecificação já que este é a principal ferramenta que permite identificar erros no código.

Definição de Regras

Em ocasiões que não se define um padrão para escrever as regras, fica um código muito "complexo" , difícil deentender o comportamento desejado para um atributo em particular.

Exemplo(ERRADO, Sem padrão):

Parm(in:EmpCod, in:&Usuario, in:&CliCod, in:&Mode);

Page

Publish

Export

Permalink

Printable Version

Share

0

TweetTweet 0

Categories

none

Group

none

Search Go

Artic le

ShareShare



noaccept(CiuCod);

&CliSaldoAux = udp(PcalcSaldo, EmpCod, &CliCod, CliSaldo);

error('Mensaje') If Null(&Usuario);

allownulls(EmpCod, LocCod ) ;

Call(PActInfo, EmpCod, CliCod) if <cond>;

error('Mensaje') IF CliDir = nullvalue(CliDir ) and after(CliDir) ;

prompt(Wclientes, EmpCod, CliCod);

default(CliFchCrea, Now() ) ;

noaccept(EmpCod);

Call(PInfoUsr, EmpCod,&Usuario) if <cond>;

nocheck(EmpCod, LocCod);

msg('Saldo menor que cero') if CliSaldo < 0;

Refcall(Wclientes, EmpCod, CliCod);

Call(Pprocedure, EmpCod, CliCod) if <cond>;

default(CliArea, 'A' ) ;

06) Ao observarmos o código acima , nos damos conta que para buscar algo temos que recorrer até o final dasregras, já que nos mostra nenhum critério a seguir. Existem muitas maneiras de definir as regras para que sejamfáceis de entender, pois vamos estabelecer um critério como boas práticas de programação.

Sugestão / Exemplo Correto:

parm( parm1, parm2, ...);

// INSTANCIAR REGISTROS (PARÂMETRO)

// DEFAULTsdefault(CliFchCrea, Now() ) ;

// NOACCEPTsnoaccept(EmpCod);

// ATRIBUIÇÕESCliEdad = Age(CliFchNac);

// INTEGRIDADE REFERENCIALallownulls(EmpCod, LocCod ) ;nocheck(EmpCod, LocCod);

// VALIDAÇÃO DE CAMPOSerror("Nombre de cliente incorrecto.") if null(CliNom);

// VALIDAÇÃO DE REGISTROSerror("La fecha de vencimiento no puede ser menor a la del documento.") if DocFchVenc < DocFch;

// PROMPTsprompt(WClientes, CliCod);

// CALL / AÇÕESCall(PInfoUsr, EmpCod,&Usuario) if <cond>;

Recomendações

07) A descrição dos objetos da KB devem ser claramente explicativos independentes do nome do mesmo;

Nome: ModCliFinanceiro Descripción: Modificacão dos Clientes do Financeiro

08) Utilizar nomes mnemônicos para as variáveis que não correspondam a nenhum atributo do sistema.

Se atribuir a uma variável a existência de um cliente Forma correta: ExisteCliente Forma Incorreta: Flag



09) Utilizar nomes mnenônicos para os objetos da KB

TrabalharComClientes

10) No cabeçalho dos programas(Procs) de deve ter um quadro de comentários com uma pequena descriçãodo propósito do mesmo e dado úteis.

/* Autor..........: Cristhián Gómez ([email protected]) Data de criação: 26-06-2004 Parâmetros in..: Parâmetros out.: Alterado em ...: 27-06-2004 Comentários....: Troca o Status dos clientes logo após a confirmação e liberação pelo Financeiro. */

11) Colocar uma linha em branco entre as definições dos eventos e as subrotinas para separar os memos edeixar mais compreensível os programas.

12) Dentro dos eventos se deve começar a escrver os códigos após ter feito a identação(tabulação)corretamente, isto facilita a visualização do código.

// Forma incorreta: Event 'NuevoCli' If &CliCod = &Cliente //Codigo Endif EndEvent

// Forma Correta: Event 'NuevoCli' If &CliCod = &Cliente //Codigo Endif EndEvent

13) Para que os ForEach fiquem mais claros e fáceis de identificar dentro dos eventos ou no código em geral,recomenda-se que escrevam da seguinte maneira:

// Forma Incorreta(sem identação): Event 'NuevoCli' For Each where CliCod = &CliCod //Còdigo EndFor EndEvent

// Forma correta(com identação): Event 'NuevoCli' For Each where CliCod = &CliCod //Còdigo EndFor EndEvent

14) Não utilizar filtros em vários locais(Parâmetro, source e condição) ao mesmo tempo dentro de umaprocedure, utilize apenas em um local "Cláusula Where" de um For each.

15) Para que os filtros dos ForEach fiquem mais claros, recomenda-se ter um where para cada condição enão utilizar (AND);

//Forma incorreta: For Each where CliCod = &CliCod and CliStatus = &CliStatus and CliTipo = &CliTipo



//Còdigo EndFor

// Forma correta(Um Where para cada condição): For Each where CliCod = &CliCod where CliStatus = &CliStatus where CliTipo = &CliTipo

//Código EndFor

/* Comentario de Demetrio Toledo. Geralmente acostumo identificar sempre a tabela base de onde vou trabalhar com o For Each utilizando a sentençaDefined By, no seguinte formato.

FOR EACH Clicod, CliStatus // GX: CLIENTES Where CliCod = &CliCod Where CliStatus = &CliStatus Where CliTipo = &CliTipo Defined By CliEstReg //Codigo ENDFOR

/* Comentario de Adilson Costa. Aproveitando o comentário anterior onde é identificada a tabela base, além de informar o nome da tabela,identifico também a sua descrição. Utilizo também a mesma informação no fechamento do For Each para facilitar quando estamos utilizando For Eachaninhados.

For Each Order Clicod, CliStatus // Clientes -> Tabela de Clientes Where CliCod = &CliCod Where CliStatus = &CliStatus Where CliTipo = &CliTipo

//Codigo

EndFor // Clientes -> Tabela de Clientes

16) Colocar espaço depois de cada (,) nas regras, call , udp, etc. para que todos os programas fiquem maisfáceis de entender.

// Forma incorreta: parm(&CliCod,&UsuCod,&Tipo); call(MiObjeto,CliCod,UsuCod,&Tipo)

// Forma correta: parm(&CliCod, &UsuCod, &Tipo); call(MiObjeto, CliCod, UsuCod, &Tipo)

17) Evite abreviar excesivamente

Os nomes das variáveis, subrotinas, objetos, etc, devem ser o mais claro possíveis já que se alguém externotrabalhar com o código, além de entender o código em geral, deverá estar descifrando os nomes de cada variáveis, etc.

Exemplo: Se quiser atribuir a uma variável o cliente por fornecedor

//Forma Incorreta: &CPForn

//Forma correta: &ClientePorFornecedor

18) Clareza no código

A clareza no código também se considera uma boa prática de programação, em muitos casos por costume dosprogramadores abusam do uso do "if" esquecendo que existe o comando "Do Case". Em muitos casos isto se deve as primeiras versões do Genexus que não suportavam estecomando e de costume não trocaram / modificaram a escrita do código.

19) Os atributos devem estar baseados em Domínios(Domains)

Deve-se definir todos os atributos sempre que possível , sejam baseados em algum Domínio, sendo fácil adaptar-se a alterações de tipos ou larguras.



20) Utilização de Patterns, quando possível.

Recomenda-se que toda aplicação web utilize Patterns, os Patterns(padrões) nos oferecem uma ferramenta idealpara criar aplicações web. Facilitam a migração do ambiente wina web e nos oferecem uma forma prática desolucionar problemas que antes demorávamos muito tempo.

21) Evitar constantes no código

Usar os Enumeradores ao invés de constantes no código. Desta maneira se trocar a constante não é necessáriotrocar em todos os objetos que ela é utilizada.

&Type = "CR" // Errado

&Type = BalanceType.Credit // Correto

22) Manutenção das Kb's

A natureza da maioria dos projetos nos leva a crer que estamos fazendo alterações constantes no conhecimentoinicial que temos armazenados em nossas Kbs. As solicitações de alteração dos clientes disparam um monte deações que em diversas ocasiões modificam grande parte da nossa lógica inicial de negócios.

Isto faz com que existam KB's que tenham muitos objetos, atributos e tabelas que não se utilizam ou quedeixaram de se utilizar por alguma alteração ou reconstrução do código. O que possibilitará que na KB existaobjetos duplicados e desnecessários e a medida que uma KB cresce , cresce também os tempos de produção.

Existem tarefas que sem nos darmos conta poderemos otimizar nossas kb, realizando a manutenção doconhecimento existente em uma kb. Fazendo uma boa manutenção podemos baixar os tempos de:

Build All

Copy Model

Update Model

Generate Help

Publicación de Información con GXPublic

Respaldos

Seria bom em certas ocasiões tomarmos um tempo livre para apagar todos os objetos, atributos, domínios,butipois e tabelas que não utilizarmos. Isto diminuirá os tempos de produção e ajudará bastante que nossas KB'stenhm o conhecimento que necessita para responder as nossas necessidades.

Uma das coisas que faz com que uma KB cresça é ter modelos sem utilizar. Como recomendação seria bom eliminartodos os modelos que não se utilizem em uma KB.

23) Encapsular código mediante o uso de atributos fórmula

Um aspecto muito relevante na hora de dar manutenção no software é ter as definições dos vários tipos decálculos que se realizam sobre os dados em um local centralizado. Para isto recomendamos ter incorporado estescálculos como atributos FÓRMULA. Neste formato nos asseguramos que quando se troca o cálculo que se querrealizar para obter uma determinada informação, se troca o atributo fórmula e isto é válido para todo o sistema.

Por último uma nomenclatura proposta para os casos em que a definição de um ATT(atributo) fórmula estábaseado em um procedimento. "Exemplo: CliSdoRes = udp(P...)" o nome do procedimento deve ser igual ao nomedo atributo.

No exemplo anterior ficaria "CliSdoRes = udp(PCliSdoRes...)", outra opção é colocar antes do nome daproc(procedure) o sufixo "frm", no exemplo citado anteriormente ficaria "CliSdoRes = udp(PfrmCliSdoRes).



Created: 05/09/08 03:54 PM by rcoproc Last update: 05/10/08 08:11 AM by rcoproc

Powered by GXwiki 4.0 Beta1 (generated with GeneXus X Evolution 2) [email protected]

boas práticas de programação em genexus - português

Documents