Hehehhe, uma bela dissertação de como saber escrever um codigo fonte.... Congratulations!
PS.: por experiencia propria, Peter esta coberto de razao. 2009/9/1 Peter P. Lupo <[email protected]> > Gente, eu não soube de nenhuma discussão a este respeito na monitoria mas > deixar o código em inglês me parece ser irrelevante. Inclusive aconselho que > vcs se acostumem a programar em inglês. Muitos códigos que vcs vão ver (a > maioria) será em inglês, alguns projetos onde vcs vão trabalhar (mesmo em > empresas brasileiras) serão em inglês por questões de uniformidade (a API > está em inglês, assim como algumas regras de padrão de nomenclatura que vcs > vão ver) e é muito possível que vcs venham a trabalhar fora do país ou em > empresas estrangeiras ou em empresas prestando serviço para empresas > estrangeiras ou com equipes mistas, com pessoas de diferentes nacionalidades > (pra quem acha que é muito raro, eu mesmo já vivi algumas destas > experiências). > Isto se não resolverem contribuir pra algum projeto open source. > > Quanto a comentários, é MUITO importante que seu código seja compreensível, > não só por quem vai corrigir, mas por vc mesmo no futuro ou por pessoas que > trabalham com vc ou trabalharão no projeto que vc desenvolveu um dia. > > Como regra, eu adoto a política de tentar fazer um código tão claro que > dispense comentários. Só quando isto não é possível por uma idiossincrasia > da vida que eu comento e tento ser o mais explicativo possível. > > "Vc pode ter um código tão simples que obviamente não tem erros ou tão > complicado que não tem erros óbvios." -Não lembro o autor. > > Reparem, por exemplo, neste trecho fictício: > > if ((e1.comparaMaior(e2) || e1.vazio()) && (e2 != null)) { > fazerAlgo(); > } > > em contraste com: > > if (elemento1AtendeRestricaoXelemento2(e1, e2)) { > fazerAlgo(); > } > > boolean elemento1AtendeRestricaoXelemento2(e1, e2) { > return (e1.comparaMaior(e2) || e1.vazio()) && (e2 != null); > } > > Notem que fica claro o que está sendo testado no if e fica clara também a > intenção daquela comparação enorme quando vc vê o método implementado > abaixo. Não é necessário o comentário. Assim, evita-se, entre outras coisas, > que o código seja atualizado, e o comentário esquecido, ficando > desatualizado e informando uma condição diferente da que acontece, causando > muitos transtornos. > > Usar nomes de variáveis que signifiquem alguma coisa também é outra boa > prática. Todas as boas IDEs completam os nomes quando digitamos os primeiros > caracteres e pressionamos ctrl+space. > Notem que não poupei letras no nome do método. O importante é deixar claro > e organizado. > > Abraço! > > Peter P. Lupo > Undergraduating in Computer Science DCC/UFRJ > MPS.BR Authorized Implementation Practitioner > Sun Certified Java Associate > http://sites.google.com/site/pplupo > Cell. +55 (021) 81742487 > > > 2009/9/1 Bruno Medeiros <[email protected]> > >> E isso afeta a nota? Como é o critério de avaliação? >> >> >> >> > > > > -- Leonardo Borba --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Comp 2 - Geral" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/comp2-geral?hl=en -~----------~----~----~----~------~----~------~--~---
