C# Qualidade no Código

Série: QUALIDADE NO CÓDIGO 2007

[email protected] Página 1

EXCEPTIONS – Você um dia terá uma! Introdução: Salve, salve DotNetianos!

Você já ouviu falar em Exception?

Exception representa uma condição excepcional, um comportamento

inesperado ou condição de erro, interrompendo o fluxo normal das

instruções durante a execução de um programa.

O .Net oferece um mecanismo robusto para tratamento de exceções.

Na realidade tratar exceções é o mesmo que tratar erros com classe,

elegância e sofisticação.

O .Net trata os erros como objetos que encapsulam informações

necessárias para resolvê-los. Esse mecanismo é conhecido como SEH

(Structured Exception Handling).

Esse poder provêm da biblioteca System.Exception.

Vejamos os membros do objeto Exception:

Propriedade Descritivo

HelpLink Retorna uma URL apontando para um documento HELP

com o descritivo do erro em detalhes

Message Descritivo do erro

Source Nome do objeto ou aplicação que gerou o erro

StackTrace Apresenta a seqüência de chamadas que dispararam

o erro

InnerException Apresenta exceções aninhadas



Estrutura Vejamos a estrutura básica para tratamento de exceções em C# using System; namespace MSDNBrasil { class MainClass { public static void Main(string[] args) { try { // Código a ser executado } catch (TipoExceção1 e) { // tratamento da exceção1 } catch (TipoExceção2 e) { // tratamento da exceção2 } catch (Exception e) // erro genérico { // tratamento genérico } finally { // Este bloco de código sempre será executado, havendo ou não exceção! } } } } Quando uma exceção for gerada, apenas um bloco catch é executado, desviando o fluxo para o bloco finally (se este existir). Digamos que uma exceção do tipo 1 é gerada, então apenas o bloco catch (TipoExceção2 e) é executado, além do finally. Gerando suas próprias exceções Você também poderá gerar suas próprias exceções utilizando o

comando throw.



Vejamos a sintaxe: // Gerando uma exceção simples Throw New Exception(“Erro! Idade inferior a 18 anos”) // Gerando uma exceção baseada numa classe Public class eIdadeInvalida: Exception {} ... try { ... } catch { Throw new eIdadeInvalida() } Exemplos 1 – Simples exceção

Em nosso primeiro exemplo forçaremos um erro de divisão por zero. using System; namespace MSDNBrasil { class MainClass { public static void Main(string[] args) { try { // Código int x = 5; int y = 0; int z = x/y; Console.WriteLine(z); // esta linha não será executada } catch (System.Exception e) { // Apresenta o erro Console.WriteLine(e.Message); } finally { // Este bloco de código sempre será executado, havendo ou não exceção! Console.WriteLine("Simples, não é?"); } } } }



A figura 1 ilustra o primeiro exemplo sendo executado.

Exemplo 2 – Criando exceção explícita

No segundo exemplo criaremos uma exceção explícita. using System; namespace MSDNBrasil { class MainClass { public static void Main(string[] args) { try { // Código int Hora = (System.DateTime.Now.Hour); if (Hora>13) { throw new Exception("Backup não poderá ser realizado após as 13 horas!"); } Console.WriteLine("Ok... Backup realizado"); // esta linha não será executada se horário > 13:59:59 } catch (System.Exception e) { // Apresenta o erro Console.WriteLine(e.Message); } finally { // Este bloco de código sempre será executado, havendo ou não exceção! Console.WriteLine("Simples, não é?"); } } } } A figura 2 ilustra nosso segundo exemplo em execução.



Exemplo 3 – Criando novas exceções

No terceiro exemplo criaremos nossas próprias exceções. using System; namespace MSDNBrasil { class MainClass { public class eInvalidTime: Exception {} public class eInvalidDay : Exception {} public static void Main(string[] args) { try { // Código int Hora = (System.DateTime.Now.Hour); int Dia = (System.DateTime.Now.Day); if (Dia ==8) { throw new eInvalidDay(); } if (Hora<22) { throw new eInvalidTime(); } Console.WriteLine("Ok... Backup realizado"); // esta linha não será executada se horário > 13:59:59 } catch (eInvalidTime) { // Apresenta o erro para o tipo eInvalidTime Console.WriteLine("------ erro: InvalidTime"); Console.WriteLine("O backup não poderá ser realizado antes das 22:00h "); } catch (eInvalidDay){ // Apresenta o erro para o tipo eInvalidDay Console.WriteLine("------ erro: InvalidDate"); Console.WriteLine("Execute manualmente o procedimento de backup"); } finally { // Este bloco de código sempre será executado, havendo ou não exceção! Console.WriteLine("Simples, não é?");



} } } } A figura 3 ilustra a aplicação sendo executada no dia 8, às 10:00hs.

Figura 3 – Exceções personalizadas

Conclusão Torne o seu código ainda mais protegido. Dê qualidade ao seu projeto.

Reduza os problemas ocasionados por erros de hardware e

intervenções de usuários. As exceptions estão aí para ajuda-lo!

Exception, você ainda vai ter uma!

Forte abraço e sucesso a todos!



BOAS PRÁTICAS EM C# Na maioria das discussões que participei acerca do assunto

“boas práticas ou qualidade em escrita de código fonte”,

percebi que se não interrompêssemos as manifestações mais

inflamadas o resultado continuaria muito distante de um

consenso. Em outras palavras, cada um tem uma posição muito

individual sobre a questão.

Realmente o assunto é polêmico na essência, pois o que é

qualidade para você?

Na intenção de apresentar minhas posições pessoais, escrevo nas

linhas seguintes alguns dos conceitos que a prática de 16 anos de

programação consolidaram em minha forma de escrever código

fonte.

Endentação A primeira questão sobre o assunto endentação que podemos citar é

sobre o número de espaços entre os níveis. Por exemplo, o Visual

Studio.NET 2003 sugere como default 4 espaços conforme podemos

comprovar na imagem abaixo.


Na época que os monitores e as placas de vídeo não eram tão

poderosos, eu particularmente gostava de utilizar dois espaços para a

endentação. No final dos anos 90 eu já tinha aderido a 3 espaços e esta

é a minha opinião até hoje.

A próxima questão pode ser o tamanho máximo de uma linha de

código fonte. Neste quesito defendo que se deve evitar ao máximo

escrever linhas com mais de 80 posições entre espaços e caracteres. A

idéia é facilitar a compreensão do código e se possível visualizar a linha

inteira em seu editor de código.

Alguns trechos de código podem ficar muito extensos e você deverá

encarar o dilema de quebrar a linha. Eu naturalmente não gosto de

quebrar linhas de código, entretanto em situações necessárias aplico os

seguintes princípios:

• Quebrar a linha após uma vírgula;

• Quebrar a linha após um operador;

• Alinhar a nova linha no inicio da expressão no mesmo nível da linha

anterior.




Exemplo:

longMethodCall(expr1, expr2, expr3,

expr4, expr5);

e

var = a * b / (c - g + f) +

4 * z;

Outra premissa importante é a utilização de espaços em branco para

endentação. Seja qual for sua opinião sobre esta questão, exponho a

minha mais veementemente: _ Não use espaços em branco para

endentação, use tabulação!

Motivos: Dos trilhões de motivos existentes, destaco a facilidade de

incrementar e decrementar blocos de código através de atalhos de

teclas do editor de código.

Comentários Das muitas funcionalidades fascinantes do Visual Studio.NET, a de

transformar comentários em documentação de código é realmente

impressionante. Em face disso, se você tem esta necessidade, utilize as

três barras “///” e seja feliz. Entretanto, para comentários que não

necessitam serem publicados, quero apresentar algumas sugestões.

Baseado na preocupação que muito provavelmente o comentário é

importante para você ou outra pessoa ser orientada sobre a

manutenção de um código fonte, chamo a atenção à forma de

destacar o comentário. Por exemplo, comentários com mais de uma

linha poderiam ser assim:

/* Line 1

Line 2

Line 3 */

Porém conforme os critérios que destaquei, sugiro que seja desta forma:

/* Line 1

* Line 2

* Line 3

*/



Fundamentalmente a questão é visual.

Para comentários de uma linha somente, tenho a seguinte opinião. Ou

o comentário deve uma espécie de marcador de loops ou não deve

ser aplicado. A questão é que como exposto em linhas anteriores, os

comentários devem chamar a atenção visando facilitar e direcionar a

manutenção. Somente justifica-se um comentário de uma linha quando

você necessita marcar dentro de um bloco de código o início de um

nível de endentação ou loop. Exemplo:

//Verifica se somente uma string foi entrada

if(args.Length==1)

Console.WriteLine(args[0]);

else

{

ArgumentOutOfRangeException ex;

ex = new ArgumentOutOfRangeException("Utilize somente uma

string");

throw(ex);

}

No exemplo acima utilizamos o comentário de uma linha com duas

barras “//” para explicar um bloco de código e marcar o seu nível de

endentação. Do trecho aonde este código exemplo foi retirado

existiam outras linhas de código antes e depois do bloco if / else.

Outra boa aplicação para comentários de uma linha é a explicação de

uma declaração. Por exemplo:

int levelStatus; // nível do status

int sizeStatus; // tamanho do status

DeclaraçõesSendo oportunista, declarar variáveis também deve apresentar uma

preocupação com a visibilidade. Por exemplo, eu não aconselho a

seguinte declaração:

int a, b;



Pode parecer exagero mas quando outro desenvolvedor for manusear

seu código fonte vai apreciar se encontrar a mesma declaração da

seguinte forma:

int a; // Valor de entrada 1

int b; // Valor de entrada 2

Para ser mais sincero e apresentar mais um conceito, tente sempre

inicializar suas variáveis no local aonde são declaradas. Sabemos que

nem sempre isto é possível, contudo bastante recomendável. Exemplo:

int a = 1; Valor de entrada 1

Permita-me um comentário adicional, não estou aconselhando nomear

uma variável inteira com "a", os exemplos anteriores visam explanar

outras questões

Nomes para componentes (notação húngara)Sobre este tópico, após muitas demoradas discussões com meu amigo

Mauro Sant’Anna, concordamos sobre os seguintes pontos:

• Não utilizar notação húngara. A notação é útil somente para

nomear componentes e, mesmo assim, quando existe a necessidade de

identificação facilitada do mesmo. Contudo se você não possui um

padrão para nomear componentes, de nada adiantará utilizar a

notação húngara.

• Coloque nomes da forma mais clara possível, visando facilitar a

compreensão da finalidade da variável. Em nomes compostos, faça

combinações entre caracteres maiúsculos e minúsculos.

Exemplo:

string nomeUsuario;

int tempoIntervaloPadrao;

Finalizo esta matéria com a sensação que podia escrever muito mais,

contudo com a restrição de tamanho imposta pelas regras

estabelecidas. Agregando um valor adicional, a seguir uma sugestão

de nomes de componentes conforme a notação húngara.

Nomes para componentes (notação húngara)


Windows Forms

Componente Prefixo Exemplo Form frm frmEntry Label lbl lblHelpMessage LinkLabel lnk lnkEmail Button btn btnExit TextBox txt txtLastName Menu mnu mnuFileOpen CheckBox chk chkReadOnly RadioButton rad radType GroupBox grp grpActions PictureBox pic picIcon Panel pnl pnlGroup DataGrid grd grdQueryResult ListBox lst lstPolicyCodes CheckedListBox clb clbOptions ComboBox cbo cboEnglish ListView lvw lvwHeadings TreeView tre treOrganization TabControl tbc tbcOptions DateTimePicker dtp dtpPublished MonthCalendar mcl mclPeriod HScrollBar hsb hsbMove




VScrollBar vsb vsbMove Timer tmr tmrAlarm Splitter spt sptDivision DomainUpDown upd updPages NumericUpDown nud nudPieces TrackBar trb trbIndex ProgressBar prg prgLoadFile RichTextBox rtf rtfReport ImageList ils ilsAllIcons HelpProvider hlp hlpOptions ToolTip tip tipIcons ContextMenu cmn cmnOpen ToolBar tlb tlbActions StatusBar sta staDateTime NotifyIcon nti ntiOpen OpenFileDialog ofd ofdImage SaveFileDialog sfd sfdImage FontDialog ftd ftdText ColorDialog cld cldText PrintDialog ptd ptdText PrintPreviewDialog ppd ppdText PrintPreviewControl ppc ppcText ErrorProvider err errOpen PrintDocument prn prnText PageSetup Dialog psd psdReport CrystalReportViewer rpt rptSales

Data

Componente Prefixo Exemplo DataSet dts dtsProducts OleDbDataAdapter oda odaClients OleDbConnection ocn ocnClients OleDbCommand ocm ocmConsult SqlDataAdapter sda sdaClients SqlConnection scn scnClients SqlCommand scm scmConsult DataView dtv dtvConsult

Documents

C# Qualidade no Código