Página Inicial > Arquitetura, Intermediário, Melhores práticas > Lista de boas práticas de codificação

Lista de boas práticas de codificação


A idéia deste blog é que seja em português.

Este post, excepcionalmente, vai em inglês mesmo, simplesmente pq o conteúdo original está assim.

É que o conteúdo abaixo é uma compilação de boas práticas que eu fiz há um tempo, tirado de várias fontes: o livro Code Complete, o StackOverflow, e uma ou outra coisinha da minha experiência mesmo.

É o tipo da coisa que uma empresa do software pode dar um ctrl+chups e estabelecer como “conjunto de diretrizes” para os programadores, ou então usar como checklist pra atividades de revisão de código.

Segue abaixo parte do conteúdo.
Veja o bicho inteiro aqui.

Enjoy the free lunch :-)

[ ]’s
O Lâmpada

Best practices for software coding.

Good coding practices help avoiding having a bad design.
There are some important characteristics of a good design that we should strive to achieve:

  • Flexibility – It is easy to change code because it is possible to alter behaviour of a single part of the system, without affecting too many other parts of the system.
  • Robustness – When you make a change, no unexpected parts of the system break.
  • Mobility – It is easy to reuse in another application because it can be easily disentangled from the current application.
  • Readability – It is easy to modify code that is easy to understand.

Coding in General

01 – Self documenting code
Improves: readability

“Any fool can write code that a computer can understand.Good programmers write code that humans can understand.”
— Martin Fowler, Refactoring: Improving the Design of Existing Code

Rather than trying to document how you perform a complex algorithm, try to make the algorithm easier to read by introducing more identifiers. Also, always try to make sure that you are using identifiers that makes the purpose very straightforward. This helps in the future in case the algorithm changes but someone forgets to change the documentation.

Here´s an example that should not be followed:

//Please don't do this
for ( i = 1; i <= num; i++ )
{
meetsCriteria[ i ] = True;
}
for ( i = 2; i <= num / 2; i++ )
{
j = i + i;
while ( j <= num )
{
meetsCriteria[ j ] = False;
j = j + i;
}
}
for ( i = 1; i <= num; i++ )
{
if ( meetsCriteria[ i ] )
{
System.out.println ( i + " meets criteria." );
}
}

Now, what do you think this routine does? It’s unnecessarily cryptic. It’s poorly documented not because it lacks comments, but because it lacks good programming style. The variable names are uninformative, and the layout is crude. Indentation also does not reflect the flow of code. Here’s the same code improved.
Just improving the programming style makes its meaning much clearer

//Yes, do it like this
for ( primeCandidate = 1; primeCandidate <= num; primeCandidate++ ) {
	isPrime[ primeCandidate ] = True;
}
for ( int factor = 2; factor < ( num / 2 ); factor++ ) {
	int factorableNumber = factor + factor;
	while ( factorableNumber <= num ) {
		isPrime[ factorableNumber ] = False;
		factorableNumber = factorableNumber + factor;
	}
}
for ( primeCandidate = 1; primeCandidate <= num; primeCandidate++ ) {
	if ( isPrime[ primeCandidate ] ) {
		System.out.println( primeCandidate + " is prime." );
	}
}

The difference between the two code fragments has nothing to with comments. Neither fragment has any. The second one is much more readable, however, and approaches the Holy Grail of legibility: self-documenting code. Such code relies on good programming style to carry the greater part of the documentation burden.
In code well written like this one, comments are often unneccessary.

(etc etc etc)
Clique no link acima (no começo do post) pra ver o documento inteiro.

About these ads
  1. ercarval
    01/04/2012 às 08:33

    Olá Tony … muito bom o post … o doc está mais chique ainda …

  2. 17/04/2012 às 22:28

    Valeu Eduardo! :-)

  3. Chris
    07/07/2012 às 16:12

    Great example. Thanks for sharing. This is something I try to promote as well.

    One objection I’ve come across was from a colleague whose first language is not English. Although he is an accomplished progrmmer, he complained that he was slower to scan down my code when he had to read the longer words.

    Another consideration for me in code maintenance :)

  1. No trackbacks yet.

Deixe uma resposta

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s

Seguir

Obtenha todo post novo entregue na sua caixa de entrada.

Junte-se a 353 outros seguidores

%d blogueiros gostam disto: