Código legível é um assunto meio difícil pois sai da nossa racionalidade matemática e entra na parte mais humana, onde o que é bom para um não necessariamente é bom para outros.
Gostei muito de ler o livro Refactoring: Improving the Design of Existing Code (Martin Fowler, Kent Beck e outros). Há um capítulo que disserta sobre maus cheiros no código e acho que eles são um bom indicativo sobre a qualidade do código. Alguns maus cheiros que o livro cita são: Classes grandes, métodos grandes, números mágicos pelo código.
Há uma frase bem interessante que atribuem ao Donald Knuth mas posteriormente ele disse ser de autoria de outra pessoa que diz: We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Acho esta frase bem interessante e a interpreto como: "prefira legibilidade a pequenas otimizações", porém, isto também é só mais um fator de ilegibilidade.
Participando de projetos um pouco maiores, com mais de 3 ou 4 pessoas trabalhando, começo a perceber que além de otimizações prematuras e maus cheiros, há um outro fator que torna o código
sujo, ilegível ou fedido. O estilo de programação é um fator que influencia tanto empresas grandes como o Google, como projetos open source como o kernel do linux.
Todo programador tem um estilo próprio de produzir código e, quando estamos participando de um projeto grande, precisamos adotar o estilo do projeto. Apesar de adotarmos um estilo diferente, podemos tirar proveito de suas vantagens para melhorar nosso próprio estilo.
Atualmente eu tenho basicamente dois estilos diferentes: um que uso em um projeto na faculdade e outro que uso ao resolver problemas de maratona de programação. Já me deparei com pessoas/empresas que diziam que a maratona estragava a pessoa e a fazia escrever códigos difíceis de entender. Eu sou totalmente contra este tipo de idéia. Acho que na maratona é fundamental ter um estilo e produzir código limpo, caso contrário o resto do time não poderá ajudá-lo sem perder muito tempo. Claro que isto não se aplica a times russos/poloneses que nunca erram. =)
Em suma, acho que esses dois estilos que uso atualmente,se ajudam entre si e me dão a oportunidade de melhorar meu estilo de programação no geral. Na minha opinião, devemos sempre tentar melhorar nosso estilo e não estacionar quando uma prática ou outra nos convém.
Gostei muito de ler o livro Refactoring: Improving the Design of Existing Code (Martin Fowler, Kent Beck e outros). Há um capítulo que disserta sobre maus cheiros no código e acho que eles são um bom indicativo sobre a qualidade do código. Alguns maus cheiros que o livro cita são: Classes grandes, métodos grandes, números mágicos pelo código.
Há uma frase bem interessante que atribuem ao Donald Knuth mas posteriormente ele disse ser de autoria de outra pessoa que diz: We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Acho esta frase bem interessante e a interpreto como: "prefira legibilidade a pequenas otimizações", porém, isto também é só mais um fator de ilegibilidade.
Participando de projetos um pouco maiores, com mais de 3 ou 4 pessoas trabalhando, começo a perceber que além de otimizações prematuras e maus cheiros, há um outro fator que torna o código
sujo, ilegível ou fedido. O estilo de programação é um fator que influencia tanto empresas grandes como o Google, como projetos open source como o kernel do linux.
Todo programador tem um estilo próprio de produzir código e, quando estamos participando de um projeto grande, precisamos adotar o estilo do projeto. Apesar de adotarmos um estilo diferente, podemos tirar proveito de suas vantagens para melhorar nosso próprio estilo.
Atualmente eu tenho basicamente dois estilos diferentes: um que uso em um projeto na faculdade e outro que uso ao resolver problemas de maratona de programação. Já me deparei com pessoas/empresas que diziam que a maratona estragava a pessoa e a fazia escrever códigos difíceis de entender. Eu sou totalmente contra este tipo de idéia. Acho que na maratona é fundamental ter um estilo e produzir código limpo, caso contrário o resto do time não poderá ajudá-lo sem perder muito tempo. Claro que isto não se aplica a times russos/poloneses que nunca erram. =)
Em suma, acho que esses dois estilos que uso atualmente,se ajudam entre si e me dão a oportunidade de melhorar meu estilo de programação no geral. Na minha opinião, devemos sempre tentar melhorar nosso estilo e não estacionar quando uma prática ou outra nos convém.
Um bom livro que eu recomendaria é o Growing Object-Oriented Software, Guided by Tests (http://www.amazon.com/Growing-Object-Oriented-Software-Guided-Tests/dp/0321503627). Ele é de TDD e foca muito na legibilidade do código e sua estrutura para termos algo legível e manutenível.
ResponderExcluirAbs
Vou olhar. Valeu Aderbal.
ResponderExcluirEu aprendi a arte de escrever código legível com esses caras http://www0.us.ioccc.org/main.html
ResponderExcluir