Quando um emérito fala, prestem atenção! -) Jonathan 2009/9/1 Peter P. Lupo <[email protected]>
> Valeu pelo endorsement. :-) > > 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 Leonardo Borba <[email protected]> > > 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 -~----------~----~----~----~------~----~------~--~---
