[Artigo] Como Programar Melhor ?!

[FoXxD]

Zen e a Arte de Programar Melhor


Tenha Calma. Se você não conseguir de primeira não é motivo para jí ir desistindo e passando a bola para o pessoal do fórum ou lista de discussão. Se você não perseverar, o lado negro da força dominará você e a mediocridade eterna será a sua recompensa profissional. Programação exige, entre outras coisas, muita perseverança.

Tente Entender. Se a dúvida é sua, assuma a responsabilidade, tente entender a resposta que te foi dada exaustivamente antes de descartá-la. Porque? Bom, porque muitas vezes ela está certa e o seu conhecimento e/ou empenho é que não não foram suficientes. Faça o mesmo antes de aceitá-la

O Passo Maior que a Perna. Se você não se garante em alguma coisa é porque ainda falta para você chegar lá. Tente começar pelo começo. De que adianta você fazer um programa usando código que te foi passado e você não entender bulhufas de como ele funciona? O bom programador é aquele que tem uma boa base, que conhece e domina o básico da linguagem e cultiva uma boa lógica, o resto vem com o tempo e a necessidade.

Seja Humilde. A humildade é um fator crucial em qualquer profissão. Cultive-a, ela pode te ensinar muito, tanto no trabalho como na vida. Ninguém aqui precisa ser monge para cultivar a humildade, cultive-a pelo prazer de ser verdadeiro nas suas ações e honesto na sua profissão.

Seja Independente. Não fique esperando a ajuda de todos para realizar o que você quer. A tarefa tem que ser a sua principal motivação. Além do mais cada vez que alguém te entrega uma solução mastigada você deixa de aprender com o processo.

Nada é Complicado. Uma coisa complicada nada mais é do que o encadeamento de varias coisas simples. O erro é tentar resolver o problema inteiro com o estigma de acha-lo complicado na cabeça. Ao invés divida o problema em pedaços menores e mais simples e resolva-os ou divida de novo até ficar simples o suficiente. Feito isso o que sobrar já não será tão complicado. Note que isso não quer dizer que você ví resolver qualquer problema de agora em diante, mas já da uma perspectiva bem melhor. Tome este conselho como uma maneira de ver as coisas, nada mais.

Não Abuse. Sua dúvida é primariamente problema seu. Os colegas, colaboradores e participantes de fóruns e listas de discussão não estão aqui somente para ajuda-lo, portanto se você realmente preza a ajuda que recebe, contente-se com ela. Lembre-se que todos tem mais o que fazer do que ficar atendendo caprichos dos outros. Sua prova de apreciação é sempre bem vinda.

A César o que é de César. Dê crédito, se você usou código de alguém e esse código ajudou bastante o seu software mencione esta pessoa nos seus créditos afinal de contas ela trabalhou duro para que você não precisasse e nem está te cobrando. Depois, qual é a graça de dizer ter feito algo quando você não fez? Pura massagem de ego!

Bom Senso é Tudo! Sem bom senso você está perdido, pode considerar isso a pura verdade. Diante de uma situação complexa e aparentemente sem saída, pare, relaxe e use o seu bom senso, escute os seus neurônios. Lembre-se que mesmo depois de ter seguido este conselho e o problema continuar lí não quer dizer que ele é insolúvel.

Nada é Impossível. Embora algumas coisas são quase. Pense que tem gente fazendo aqueles jogos 3D e portanto se aquilo é possível sua tarefa também deve ser. O importante é perseverar e manter uma atitude positiva diante da tarefa, não encare a tarefa como inimiga e sim como uma amiga que não fala a sua língua.

Nunca Pare de Aprender. Se um dia você se cansar de aprender novas tecnologias em desenvolvimento, siga meu conselho: Mude de profissão. É exatamente o que eu vou fazer.

Tenha Curiosidade. Procure, pesquise e corra atrás. Isso ensina mais que muitos cursos por aí. A máquina é o computador e não você, portanto não se torne um autômato que apenas faz o necessário e apenas sabe o suficiente.

Tenha Criatividade. Muitas vezes é o que distingue o bom programador do medíocre. Programação não é somente uma técnica, é também uma arte. Sem criatividade você está a mercê da mesmice num mundo cada vez mais dinâmico e variado. Infelizmente criatividade não pode ser ensinada, tem que ser aprendida na prítica.

Faça Bem Feito. Seja detalhista e capriche em tudo até que isso fique automático em você, essa atitude lhe renderá um diferencial importante nesta nossa profissão tão concorrida.

Seja Simples. A simplicidade é mágica e as pessoas de hoje tendem a complicar, portanto mantenha-se simples. Se estiver com 3 possíveis soluções para um problema tente a mais simples, é geralmente a mais eficaz.

Não Tenha Pressa. O aprendizado é uma estrada longa e cheia de obstáculos, que começa no primeiro passo e termina quando você a abandona. Aprenda a separar pressa e deadline, de que adianta entregar no prazo se está mal feito. O velho ditado vale: "A pressa é inimiga da perfeição".


--------------------------------------------------------------------------------------

Como escrever programas melhores

Traduzido por Walter Staeblein. Autor Desconhecido.




Como em qualquer tipo de empreendimento o difícil está sempre nos detalhes. Um programa pode parecer ótimo no papel mas se não for implementado com extrema atenção aos detalhes, usando técnicas de programação sólidas e com uma pitada de arte ele, de certo, será um fracasso. Ele provavelmente vai cumprir a lista de tarefas, mas não vai ser atraente, intuitivo ou prítico.

A parte mais importante de se implementar um programa não é fazer as coisas funcionarem, é não deixa-las pifarem. Discute-se muito tratamento de erros, como captura-los, como manuseá-los, etc... Estas coisas se fixam no que fazer depois do leite derramado. Elas são importantes para o sucesso do seu programa mas não se comparam a prevenção de erros, esta sim deve ser enfatizada.

Se colocamos prevenção de erros na mesa, é sempre no pratinho do pão. Prevenção de erros deve ser o prato principal do projeto e não uma simples sobremesa. Este artigo foca em técnicas de prevenção de erros e outros assuntos ligados ao desenvolvimento de software.


: : Clareza : :


Cada função ou procedimento deve ter um, e somente um, propósito claro. este propósito deve ser comunicado no primeiro comentário. Assim como cada bloco comentado de código numa rotina deve ter só um claro propósito.

O mesmo se aplica a variáveis. Cada uma deve ter um só propósito. Variáveis multiuso devem ser reduzidas ao mínimo, e claramente identificadas como tal.

Seguindo esta regra geral a clareza do código vai ser melhorada e este vai ficar mais robusto e fícil de manter.



: : Escopo : :

Sempre considere o escopo. Suas variáveis são locais, modulares ou globais? Suas rotinas são públicas ou privadas?

Geralmente o escopo deve ser o mais restrito possível. Na dúvida, comece declarando a variável como local. Se ela for necessária a outras rotinas do formulário mude seu escopo para modular (válida somente no módulo ou formulário em que foi declarada). Por fim se for necessária em outros módulos faça-a Global. Não se esqueça de mudar seu nome para que este reflita sua nova abrangência.

Mais uma vez, faça todo o possível para manter as variáveis locais. Modulares ou globais só devem ser declaradas se absolutamente necessárias. Passando variáveis como parâmetros de funções ou procedimentos (Subs) e criando propriedades num módulo de classe são alternativas muito mais reciclável e fáceis de mudar quando necessário.

Quanto a funções, mantenha-as privadas a não ser que tenham que ser públicas. Isto diz respeito principalmente a funções em DLLs ou controles ActiveX. Não exponha nenhuma função ao usuário sem ter certeza absoluta que todo o código de prevenção de erros estí no lugar e funcionando. Não exponha ao usuário funções internas as quais ele não necessita.

Tente não usar constantes públicas desnecessárias. Embora sejam de grande valia elas fazem com que um módulo seja menos auto suficiente e reciclável.



: : Property Pages : :
Com VB, se você usa um controle complexo como um Grid que tem Property Pages, resista a tentação de marcar as propriedades do controle deste modo pois você se arrisca a perder todas se o controle for atualizado, se o .frx falhar ou ainda se algum problema não previsto acontecer. Na maioria das vezes o programador jí se esqueceu dos valores das propriedades inseridos deste jeito e vai levar algumas horas ou dias de tentativa e erro para remediar a situação.

Mais importante também é o fato de que outros programadores não vão saber que propriedades de um controle você mudou e porquê. Seu código vai ser bem mais fácil de entender e modificar se você marcar todas as propriedades em tempo de execução (em eventos e rotinas) com fartos comentários.



: : Nomes : :
Nunca use os nomes criados pelo VB para seus controles, estes nomes não seguem as convenções da própria Microsoft. Eles indicam o tipo de controle mas não a função do mesmo dentro do programa.

Por isso sempre dê nomes descritivos e objetivos imediatamente após a criação do controle. Um nome apropriado consiste de um prefixo, normalmente 3 letras em caixa baixa, para indicar o tipo de controle, seguido de uma descrição da sua função no todo.

Por exemplo, um novo TextBox chamado de Text1 pelo VB. Ele deve ter seu nome imediatamente mudado para algo como txtNomeUsuario. Isto indica que se trata de um textBox que recebe o nome do usuário.

Sempre use os prefixos padrão para que outros que venham a mexer no seu código entendam com mais facilidade. Abaixo está uma lista com alguns tipos padrão para controles do VB:


frm - Form
txt - TextBox
lbl - Label
cmd - CommandButton
lst - ListBox
cmb - ComboBox
chk - CheckBox
opt - OptionButton
img - ImageBox
pic - PictureBox
vsc - Vertical ScrollBar
hsc - Horizontal ScrollBar
tmr - Timer
wsk - Winsock



: : Arcana : :
Sempre use o mais simples, direto e legível código possível. As duas linhas abaixo fazem a mesma coisa:

1. If bArrumaFrente = True Then S = "Cima" else S = "Baixo"

2. S = IIF(bArrumaFrente, "Cima", "Baixo")

A linha 1 é muito mais legível do ponto de vista humano. A 2 é mais complicada e demora mais tempo para a maioria dos programadores entender. É verdade que a linha 2 é mais compacta e avançada mas clareza deve estar sempre em primeiro lugar. Em C++ e Pascal existem muito mais maneiras de se mostrar com esse tipo de código arcano do que em VB.



: : Comentários : :
Porquê me lixar em comentar meu código? Fui eu quem escreveu, daà não preciso de lembretes. De qualquer maneira um código fonte coeso é sempre auto explicativo e evidente. Comentar meu código seria dizer em voz alta que ele não é bom. Além disso, qualquer programador que reclamar que não consegue entender meu código por falta de comentários é um maricão que não sabe de nada. Eu não tenho tempo de comenta-lo, quem sabe depois de terminado eu separo um tempinho para isso.

Estas são algumas reações naturais mas bitoladas que alguns programadores tem sobre comentários. Comentários são parte essencial de um código coeso e reciclável. O que parece óbvio num dia fica totalmente obscuro em outro. Se o programa é um sucesso, outros programadores vão, eventualmente, continua-lo. Algumas partes do código não serão óbvias a eles, não interessa quanta experiência eles tenham.

O equilíbrio é o segredo. Alguns programadores não põe comentários, outros põe comentários inúteis ou óbvios, outros ainda põe comentários demais. estes últimos podem, as vezes, causar mais danos do que aqueles que nem comentam. Este tipo de código é cheio de comentários redundantes, decoração e linhas em branco que não acrescentam nada.

'===============================
'""""""""" COMENTÁRIO """"""""
'===============================

O bloco acima pode ser um neon para chamar a atenção é um comentário, mas ele atrapalha. Ele gasta muito espaço na tela e acaba por fazer o código mais difícil de ler. Comentários devem aparecer para comunicar informação que Não é óbvia. Eles não devem interferir com a legibilidade do código, mas devem ser fáceis de achar se o programador os procura. Eles não devem usar mais espaço que o necessário. Como regra geral, olhe para sua tela de código. Se você só vê comentários algo está errado, se você só vê código as chances são que você não está sabendo antecipar adequadamente o que outro programador (ou você mesmo) pode precisar saber no futuro.



: : Longo Prazo : :
Muitos programas tiveram de ser completamente dilacerados ou até escritos novamente quando passados a um novo cliente ou vendidos a uma companhia. O porque? O programador não pensou a longo prazo.

Quando programamos, a ênfase é basicamente em fazer o programa funcionar. Como se o EXE fosse a única coisa que conta. Assim pensamos em curto prazo. Nós assumimos que enquanto entendermos o código tudo bem.

É bem mais importante pensar a longo prazo. O EXE não importa muito realmente, mas o código sim. Não deve ser suficiente que entendamos o código, mas que outros também possam entende-lo. Nós entregaremos e eles o pegarão e o modificarão com facilidade.

Pensar a longo prazo significa fazer comentários que vão ajudar outros, mesmo que você não precise deles (os comentários). Significa usar convenções padrão para nomes mesmo que prefiramos nossa própria maneira de nomear componentes. Significa declarar tudo explicitamente mesmo quando você conhece os defaults. Significa usar código simples e facilmente legível mesmo sendo capaz dos mais variados truques e macetes. Significa evitar Property Pages. Significa escrever nosso código para os outros.



: : Moral da História : :
A moral da história aqui é que um programa que é legível mas não funciona direito é bem melhor do que um que funciona mas ninguém consegue entendê-lo. O primeiro pode ser consertado mas o segundo certamente terá que ser reescrito.

[M4CK]

cara texto muito bom msm ..

: : Moral da História : :
A moral da história aqui é que um programa que é legàvel mas não funciona direito é bem melhor do que um que funciona mas ninguém consegue entendê-lo. O primeiro pode ser consertado mas o segundo certamente terí que ser reescrito.

:arrow:

[B00t.bat]

De noite vo ler com atençao...

Muito obrigado! Eu tava qerendo começar o tentar a programar...

Vamos ve até aonde eu chego com essa idéia =D

Valews!!!

TeE! +

[blackwinner]

Cara, concordo com quase tudo que tem ai, menos com uma coisa..

: : Moral da História : :
A moral da história aqui é que um programa que é legàvel mas não funciona direito é bem melhor do que um que funciona mas ninguém consegue entendê-lo. O primeiro pode ser consertado mas o segundo certamente terí que ser reescrito.

Um programa "ilegàvel" na verdade é legàvel sim, porque ele segue SUA lógica então você consegue entende -lo.. então se a empresa quiser concertar o software por conta de um possàvel bug, e foi você que você fez o soft~ e ele estí "ilegàvel", eles só poderão chamar você para consertar.. matemíticamente falando-->



MDH = empresa_querendo_concertar_sftw + sftw_ilegàvel = você contratado novamente = monopólio \o/ = dinheiro_no_bolso

moral da história = MDH

Eu acho que prefiro o meu ponto de vista :roll: =]

[Douglas Almeida]

Muito bom o material, Obrigado por compartilhí-lo.

ressaltando que programar é a parte mais fícil do desenvolvimento de um software.

Abraço!

[marcilioqsj]

Texto muito proveitoso!
Vlw!

[Cartoondivine]

FoXxD, delícia de texto cara, depois de um ano q me coloquei a disposição de ler por completo e filtrar o material, rsrs.

Mas enfim, acho q mta gente precisa ler esse texto, tanto qm pretende programar ou quem já programa...cara, dentre várias frases de impácto, adorei quando o texto fala:

Sempre use o mais simples, direto e legível código possível.

Putzz, pura realidade, as vzs eu pego ai algum code em Perl e o cara me faz uma bagunça q eu tenho q depois colocar ordem na casa e não entendo como ele pode fazer algo assim.

Outra coisa q gostei mto foi sobre os comentários nos códigos, ta certo, comentários são importantes pra caramba em um script e talz, mas tm horas q vc pega lá 180 linhas de código e poderia reduzir facilmente para umas 60 pq contem coments inúteis, então esta certo o texto quando diz q temos q saber dosar isso.

Enfim, belo texto, passei agora alguns momentos lendo e corrigindo erros q aconteceram no texto quando o fórum deu uma bugada, mas é isso, não foi um tempo mal gasto, pelo contrário.

Abração! :mrgreen:

[FoXxD]

Quando encontrei este texto eu gostei muito.
Estava aprendendo a programar... não sabia lógica de programação ainda.
Hoje, me parece que valeu a pena ter lido.

Como eu.. ví que muitos aqui gostaram do texto.

Abraços,
FoXxD