"Será que essa função está realmente boa?"

Essa dúvida ocorre ocasionalmente na mente de todo programador, exceto talvez os que já perderam completamente o juízo... rsrsrs

A verdade é que muitos consideram que programar é arte. Sendo assim, como qualquer disciplina em estado-de-arte, a programação desafiaria as técnicas e padronizações, não existindo um critério único para definir qualidade. Quem pode dizer, por exemplo, se um quadro de van Gogh é melhor ou pior que um de Matisse? São pintores diferentes, com estilos diferentes. Não há melhor nem pior nesse caso, apenas o gosto pessoal de quem aprecia.

Acredito, porém, que a coisa não é bem assim. Há naturalmente questões de estilo a considerar, mas existem SIM critérios bem definidos para avaliar um bom programa de computador e para comparar qualidade entre programas. Um bom exemplo disso está nos programas Perl que incluí no primeiro artigo dessa série (Programação (I) - Planejamento e Otimização). Não há como negar que a última versão é mais eficiente que as duas primeiras, sendo que o estilo de ambas é similar.

Dito isso, vamos tentar então conhecer esses critérios!

[1] Comentário enviado por bjaraujo em 05/05/2008 - 14:04h:

parabéns, cara; acho que ainda tenho sequelas pela exposição ao BASIC. ahuahuaha

[2] Comentário enviado por stremer em 05/05/2008 - 19:03h:

excelente. O dificil é mesmo conhecendo tudo isto conseguir implementar nos prazos malucos que os gerentes de TI e pessoal do marketing impõe (rs)

[3] Comentário enviado por rafastv em 05/05/2008 - 19:17h:

De leitura agradável e rápida, parabéns!

[4] Comentário enviado por kabalido em 05/05/2008 - 21:53h:

Parabéns cara! Continue assim, os seus artigos são muito bons.
Valeu!!

[5] Comentário enviado por edlonewolf em 06/05/2008 - 08:51h:

stremer,

Tem de fazer ouvido de mercador para os caras que ficam pressionando para acelerar o trabalho. Se você foge dos esquemas bem definidos, acaba perdendo mais tempo no final.

Abraço e oobrigado a todos!

[6] Comentário enviado por douglascrp em 06/05/2008 - 09:04h:

excelente artigo... assim como o primeiro artigo, depois que se começa a ler, é impossível parar até terminar...

parabéns

[7] Comentário enviado por leowalker em 06/05/2008 - 15:18h:

muito bom, estou esperando o proximo para dar continuidade...

Abraço e parabens.

[8] Comentário enviado por vodooo em 07/05/2008 - 09:57h:

Cara, parabéns, realmente de leitura muito agradável!

Abraços

[9] Comentário enviado por edlonewolf em 07/05/2008 - 19:12h:

O próximo artigo já está no forno... deve estar pronto para ser postado no início da semana que vem. Aí é só esperar a fila andar. Mais uma vez obrigado pelos comentários e pelo apoio de todos.

[10] Comentário enviado por rl27 em 09/05/2008 - 11:14h:

Parabéns pela série de artigos. Muito boa mesmo!

Estou ansioso pela continuação. Com certeza ainda darei minhas contribuições à comunidade.

Valeu!

[11] Comentário enviado por joaomc em 09/05/2008 - 13:53h:

O princípio da caixa preta é bonito na teoria, mas na prática a coisa não é bem assim. Muitas vezes você *precisa* saber o que há por trás daquele método que está chamando, para, por exemplo, saber os efeitos colaterais, se o método é thread-safe, etc.

Mas estou só sendo chato, o artigo ficou bom, parabéns :)

[12] Comentário enviado por edlonewolf em 09/05/2008 - 19:43h:

joaomc,

Concordo em parte. Mas saber se um método é thread-safe não viola necessariamente o princípio da caixa-preta. O que viola é escrever código que dependa do algoritmo usado por essa ou aquela função. Isso é uma violação grave, que cria dependência. A questão de ser ou não thread-safe é mais relacionada com o conhecimento dos requisitos do módulo. Vamos discutir isso quando formos falar em análise de requisitos.


rl27,

Obrigado pelo comentário. E tenho certeza que em breve estarei também lendo seus artigos aqui. Basta estudar e estar com a mente aberta para aprender.


Ed

[13] Comentário enviado por marcio_paim em 14/02/2012 - 22:14h:

Excelente série de artigos.