|
Artigo Técnico: Qualidade de codificação e melhores práticas em .NET Framework (Parte 1)
Autor: Marcel Tiago Panissa - Colaborador MCP Brasil.com
19/04/2007 - Garantir a qualidade de um código de programação não é algo que possa ser acrescentado no final de um projeto. Ordinariamente nós desenvolvedores somos individualistas e definimos nossos próprios padrões e “vícios” de programação, entretanto problemas que são muito complexos ou descobertos tarde demais têm um grande custo para o ciclo de vida do produto e são invariavelmente difíceis de serem corrigidos. O artigo a seguir descreve alguns princípios e metodologias para aprimorar a qualidade de codificação e o trabalho em equipe em aplicações .NET Framework.
Práticas de Codificação
A razão principal para utilização de um conjunto consistente de práticas de codificação é a de padronizar a estrutura e o estilo da codificação para que outros programadores consigam ler e entender o código espontaneamente. A utilização de boas práticas de codificação faz com que os resultados do código fonte, sejam claros e intuitivos. Simples práticas como definição de nomes e comentários podem fazer uma enorme diferença no resultado final do projeto.
Definição de Nomes
Selecionar um nome apropriado para elementos em um código faz com que outros desenvolvedores se sintam confiantes e confortáveis em desenhar novas classes utilizando os padrões especificados.
Convenção de Escrita (uso de caixa alta ou caixa baixa)
A convenção de escrita se refere ao estilo de caixa utilizada para um determinado elemento. É importante lembrar que o .NET Framework suporta tanto linguagens case-sensitive como case-insensitive. Portanto, estabelecer esses padrões faz com que os desenvolvedores compreendam e consigam trabalhar com uma biblioteca sabendo exatamente com que tipo de identificador está visualizando.
Estilos de Caixa (Casing)
Regras para utilização de estilos de caixa
Quando um identificador consiste em múltiplas palavras, não se deve utilizar separadores como sublinhado (“_”) ou hífen (“-“) entre as palavras. Ao invés disso, é recomendado utilizar o estilo de caixa apropriado para o elemento.
A regra geral para utilização de estilos de caixa é a de utilizar o Pascal Casing para todos os membros, tipos e namespaces públicos de uma classe, desde que a palavra consista em mais de três letras. O estilo de caixa Camel Casing deverá ser utilizado somente para designar parâmetros de um método. O estilo de caixa alta somente será utilizando para variáveis do tipo constante. O quadro abaixo resume os tipos de identificadores e como devem ser aplicados os tipos de escrita:
Nota
O tipo de identificador “Interface” deve ser precedido com o prefixo “I” ao especificar o nome.
Regras para utilização de acrônimos
Um acrônimo é uma palavra que designa um termo ou aplicação. Por exemplo, “FBI” é o acrônimo de “Federal Bureau of Investigation”. A utilização de um acrônimo dentro de um identificador deve ser utilizada quando o termo é bem conhecido e compreendido por qualquer desenvolvedor. É importante ressaltar a diferença entre um acrônimo e uma abreviação, por exemplo, a palavra “ID” que é uma abreviação de “identificação”. Abreviações devem ser evitadas no desenho de uma classe.
Nota
As únicas abreviações que podem ser utilizadas em um código são as palavras ID e OK, sendo que em identificadores do tipo Pascal, devem aparecer como Id e Ok e identificadores do tipo Camel devem aparecer como id e ok.
A utilização de estilos de caixa em acrônimos depende do tamanho do acrônimo. Todos os acrônimos devem possuir pelo menos dois caracteres. Se um acrônimo possuir dois caracteres é considerado um acrônimo curto, se o acrônimo possuir três ou mais caracteres é considerado um acrônimo longo.
Ao adicionar um acrônimo curto (dois caracteres) dentro de um código, deve-se utilizar caixa alta para o identificador, exceto se a primeira palavra estiver utilizando o Camel Casing, ou seja, se o identificador for um parâmetro. Por exemplo, uma propriedade chamada “DBRate” utiliza o acrônimo “DB” e deve estar em caixa alta. Agora se a mesma palavra estiver como um parâmetro de um método, deve ser escrita como “dbRate”.
Ao adicionar um acrônimo longo, somente a primeira letra deve ser colocada em caixa alta, desde que a palavra não seja um parâmetro. Por exemplo, uma classe chamada “XmlWriter” utiliza o acrônimo “XML” e deve ser colocado caixa alta somente na primeira letra. Se a mesma palavra estiver como um parâmetro de um método, deve ser escrita como “xmlWriter”. O quadro abaixo especifica as utilizações de acrônimos de acordo com o tamanho de caracteres e de seu respectivo identificador:
Regras para utilização de palavras compostas e termos comuns
Palavras compostas ou termos comuns devem ser tratados como uma palavra simples. Por exemplo, a palavra composta “mula-sem-cabeça”, deve ser interpretada como “MulaSemCabeça” em identificadores públicos ou “mulaSemCabeça” em identificadores do tipo parâmetro. É importante ressaltar que a composição das palavras deve respeitar os padrões de estilos de caixa, como a retirada de hífens.
Idioma
Para criar um ambiente consistente de codificação é preciso definir um idioma padrão de desenvolvimento. Nesse artigo vamos utilizar o idioma padrão como inglês (recomendável, uma vez que qualquer desenvolvedor poderá compreender o código). Após definir o idioma, é essencial criar uma lista de sinônimos para os métodos mais utilizados dentro de uma classe. Veja exemplos dos sinônimos no quadro abaixo:
Escolha da palavra
Um problema recorrente entre desenvolvedores é a escolha de uma palavra que corresponda a uma classe ou método, de modo que a programação siga um modelo intuitivo e simples para compreensão.
O ideal é sempre escolher nomes fácies para leitura e que expliquem de fato a função do método implementado. O quadro abaixo mostra algumas situações comuns:
Através desses exemplos acima, é possível perceber que o simples fato de escrever corretamente uma propriedade, faz com que a leitura de um código se torne muito mais espontânea.
Não devem ser aplicadas algumas práticas, como a utilização de caracteres especiais e notação húngara. É importante evitar o uso de identificadores que conflitam com palavras reservadas (keywords) da linguagem de programação.
Palavras reservadas C#
abstract, event, new, struct, as, explicit, null, switch, base, extern, object, this, bool, FALSE, operator, throw, break, finally, out, TRUE, byte, fixed, override, try, case, float, params, typeof, catch, for, private, uint, char, foreach, protected, ulong, checked, goto, public, unchecked, class, if, readonly, unsafe, const, implicit, ref, ushort, continue, in, return, using, decimal, int, sbyte, virtual, default, interface, sealed, volatile, delegate, internal, short, void, do, is, sizeof, while, double, lock, stackalloc, else, long, static, enum, namespace, string, get, partial, set, value, where, yield
Palavras reservadas C++
__abstract 2, abstract, __alignof Operator, array, __asm, __assume, __based, bool, _box 2, break, case, catch, __cdecl, char, class, const, const_cast, continue, __declspec, default, __delegate 2, delegate, delete, deprecated 1, dllexport 1, dllimport 1, do, double, dynamic_cast, else, enum, enum class, enum struct, event, __event, __except, explicit, extern, FALSE, __fastcall, __finally, finally, float, for, for each, in, __forceinline, friend, friend_as, __gc 2, gcnew, generic, goto, __hook 3, __identifier, if, __if_exists, __if_not_exists, initonly, __inline, inline, int, __int8, __int16, __int32, __int64, __interface, interface class, interface struct,interior_ptr, __leave, literal, long, __m64, __m128, __m128d, __m128i, __multiple_inheritance, mutable, naked 1, namespace, new, new, __nogc 2, noinline 1, __noop, noreturn 1, nothrow 1, novtable 1, nullptr, operator, __pin 2, private, __property 2, property, property 1, protected, public, __raise, ref struct, ref class, register, reinterpret_cast, return, safecast, __sealed 2, sealed, selectany 1, short, signed, __single_inheritance, sizeof, static, static_cast, __stdcall, struct, __super, switch, template, this, thread 1, throw, TRUE, try, __try/__except, __try/__finally, __try_cast 2, typedef, typeid, typeid, typename, __unaligned, __unhook 3, union, unsigned, using declaration, using directive, uuid 1, __uuidof, value struct, value class, __value 2, virtual, __virtual_inheritance, void, volatile, __w64, __wchar_t, wchar_t, while
Palavras reservadas Visual Basic
AddHandler, AddressOf, Alias, And, AndAlso, As, Boolean, ByRef, Byte, ByVal, Call, Case, Catch, CBool, CByte, CChar, CDate, CDec, CDbl, Char, CInt, Class, CLng, CObj, Const, Continue, CSByte, CShort, CSng, CStr, CType, CUInt, CULng, CUShort, Date, Decimal, Declare, Default, Delegate, Dim, DirectCast, Do, Double, Each, Else, ElseIf, End, EndIf, Enum, Erase, Error, Event, Exit, FALSE, Finally, For, Friend, Function, Get, GetType, Global, GoSub, GoTo, Handles, If, Implements, Imports, In, Inherits, Integer, Interface, Is, IsNot, Let, Lib, Like, Long, Loop, Me, Mod, Module, MustInherit, MustOverride, MyBase, MyClass, Namespace, Narrowing, New, Next, Not, Nothing, NotInheritable, NotOverridable, Object, Of, On, Operator, Option, Optional, Or, OrElse, Overloads, Overridable, Overrides, ParamArray, Partial, Private, Property, Protected, Public, RaiseEvent, ReadOnly, ReDim, REM, RemoveHandler, Resume, Return, SByte, Select, Set, Shadows, Shared, Short, Single, Static, Step, Stop, String, Structure, Sub, SyncLock, Then, Throw, To, TRUE, Try, TryCast, TypeOf, Variant, Wend, UInteger, ULong, UShort, Using, When, While, Widening, With, WithEvents, WriteOnly, Xor, #Const, #Else, #ElseIf, #End, #If, -, &, &=, *, *=, /, /=, \, \=, ^, ^=, +, +=, =, -=
Nota
Notação húngara é uma convenção de nomes criada por Charles Simonyi da Microsoft, com o intuito de atribuir um prefixo para cada variável criada em um código fonte. Esse prefixo deveria conter informações sobre o tipo de dados da variável, por exemplo, ao criar uma variável Nome do tipo String, o programador atribuía o nome da variável como strNome. Como no .NET Framework as variáveis são bem “tipadas” esse tipo de implementação é desnecessária.
Nomes específicos de linguagens de programação
Procure utilizar nomes que retornem a funcionalidade de um método ao invés de utilizar nomes específicos de uma linguagem de programação para tipos de dados. Por exemplo, utilizar o nome “GetLength” é melhor do que utilizar o nome “GetInt”.
Se for necessário utilizar um nome especifico da linguagem de programação procure utilizar o nome genérico do .NET Framework como especificado na CLR (Common Language Runtime). Por exemplo, um método que converta um dado para Int16 deve ser nomeado como “ToInt16” e não como “ToShort”, uma vez que Short é um tipo de dados de uma linguagem de programação especifica (Visual Basic) para Int16. O quadro abaixo mostra os nomes dos tipos de linguagem de programação especificas:
No próximo artigo vamos continuar explorando as definições de nomes para recursos específicos do .NET Framework. Até lá!
|
|
Principal
