c# - boas praticas de programação
DESCRIPTION
asdasdTRANSCRIPT
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çãoA 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.Exemplos:
longMethodCall(expr1, expr2, expr3, expr4, expr5);
evar = 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áriosDas 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 entradaif(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 statusint 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 1int 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.
Nomear VariáveisSobre 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.
Exemplos: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
Fabio Camara, MCP, MCSA, MCAD Charter, MCDBA e MCSD.NET – É Diretor da Architettura Soluções em Tecnologia. Escreveu os livros “Projetos com Windows DNA e .NET”, “Dominando o Visual Studio.NET com C#” e “Orientação a Objeto com .NET” dentre outros, editados pela Visual Books Editora. Pode ser contatado pela home page C# Br (http://www.csharpbr.com.br).