e claro.Metodos <= 20 linhasLinha <= 100 caracteresClasse = 200 a 500 linhasClaro que toda regra tem sua excecao. Essas sao dicas do livro, porem se voce tem uma classe que vai precisar de mais linhas, um metodo que tambem precise de mais linhas, isso nao e um problema, o lance e mais ter isso em mente como uma bussola.Metodos e funcoes devem fazer somente uma coisa, faze-la certa e somente faze-la.Vejo essa frase como o principio da coesao no seu codigo.Muitas vezes nao e facil saber se aquele metodo esta fazendo somente uma coisa. Uncle Bob da uma boa dica. Ele diz que voce deve tentar extrair parte do seu codigo para um metodo, se voce conseguir, isso e porque aquele seu metodo realmente nao esta tendo uma so funcao.Vamos imaginar se eu tivesse um metodo onde eu quisesse mostrar os detalhes de um usuario:private void mostrarDadosUsuario(Usuario usuario){ mostrarCabecalhoUsuario(); System.out.print(Nome: , usuario.getNome()); System.out.print(Sobrenome: , usuario.getSobrenome());}As linhas do System.out.print sao os detalhes do usuario, entao sera que nao ficaria melhor:private void mostrarDadosUsuario(Usuario usuario){ mostrarCabecalhoUsuario(); mostrarDetalhesUsuario();}private void mostrarDetalhesUsuario{ System.out.print(Nome: , usuario.getNome()); System.out.print(Sobrenome: , usuario.getSobrenome());}Se um dia voce quiser so listar os dados de um usuario, pronto ! Vc tem os metodos separados. Imagine se voce quisesse imprimir os dados da maneira que estava antes, voce nunca conseguiria.Isso tambem e um bom exemplo do tipo de refatoracao chamada Extract Method, vamos falar mais a frente sobre a importancia da refatoracao.Uma outra coisa esta na quantidade de parametros de um metodo. Um dia desses peguei uma aplicacao legada que tinha uma funcao javascript com 34 parametros. Eu considero isso uma manutencao quase impossivel. Imagine uma chamada:montaMenu(1,2,1,1,1,1,1,2,2,2,2,,,,2,1,2,3 ...)Como entender ? o pior que o metodo era no nivel Date d, logo, e preferivel refazer. Uncle Bob fala que voce deve ter uma justificativa muito boa para ter uma quantidade tao grande de parametros em um metodo.Um outro agravante de um metodo com varios parametros e a dificuldade de se testar uma vez que voce tera que testar todas as combinacoes possiveis.Outra coisa que tem que se tomar cuidado e com metodo que diz que vai fazer uma coisa e faz outra.Vamos imaginar:public boolean verificarSenha(String senha){ if(senha.equals(zzz)){ Session.initialize(); return true; } return false;}O objetivo do metodo e verificar a senha, porem, se a senha estiver correta o mesmo inicializa uma sessao, ou seja, o metodo ja nao tem a coesao esperada, o mesmo esta com duas responsabilidades.E se eu quisesse inicializar uma sessao ? eu seria obrigado a ter a senha correta ?Para uma melhor coesao, seria melhor:if(verificaSenha(zzz){ Session.initialize();}public boolean verificarSenha(String senha){ if(senha.equals(zzz)){ return true; } return false;}Metodos devem fazer algo ou retornar algo, mas nao as duas coisas ao mesmo tempo (principio do command query separation)Comentarios nos codigosComentarios podem ser mentirosos e trazer desinformacao. Porque podemos afirmar isso ? Alguem conhece alguem que atualiza comentario ? Passei por varios codigos na vida com uma montueira de comentarios que nao serviam para nada e ainda confundiam. Se um metodo ou uma classe estiver bem escrito o comentario passa a ser dispensavel.Uma outra coisa importante, comentario nao ira