A escrita de comentários dentro de métodos não é uma boa prática? [duplicado]

62

Um amigo me disse que escrever comentários dentro de métodos não é bom. Ele disse que deveríamos ter comentários apenas para as definições do método (javadocs), mas não dentro do corpo do método. Parece que ele leu em um livro que ter comentários dentro do código significa que há um problema no código. Eu não entendo muito bem o seu raciocínio. Acho que escrever comentários dentro do corpo do método é bom e ajuda outros desenvolvedores a entender melhor e mais rápido. Por favor, forneça seus comentários.

    
por Srini Kandula 28.02.2011 / 02:16
fonte

24 respostas

150

Seu amigo está errado e poucos programadores concordariam com ele. Você deve escrever comentários sempre e onde quer que você sinta melhor para ajudar na compreensão.

    
por 28.02.2011 / 02:18
fonte
88

Ignore seu amigo. Comente conforme necessário. Mas esforce-se para tornar seu código auto-explicativo, para que os comentários não sejam necessários. Lembre-se de que seu computador não está executando comentários e, portanto, é fácil para os comentários ficarem fora de sincronia com o que realmente está acontecendo.

Eu costumo usar um bloco de comentário para explicar uma parte particularmente complicada da lógica, que, de outra forma, levaria algum tipo de distorção para ler. E então tentarei deixar a lógica mais clara e remover a necessidade de explicação.

    
por 28.02.2011 / 02:18
fonte
44

O bom código é auto-documentado. Um método deve fazer exatamente uma coisa, e uma coisa deve ser óbvia pelo nome do método e especificações do comentário. Portanto, a necessidade de comentários no método que explica a lógica sugere que o método deve ser dividido em métodos de responsabilidade única.

Agora, pela realidade. Você se depara com uma base de código complexa de código espaguete e está tentando ser gentil com os mantenedores. Você não tem tempo ou mandato para refatorar 8 milhões de linhas de código, e mesmo se você o fizesse, haveria nuanças porque tudo é complexo. O que você faz?

    
por 28.02.2011 / 02:19
fonte
24

Estou surpreso com quantas pessoas não concordam com essa visão.

  1. Um bom código deve ser auto-documentado, então você deve escolher cuidadosamente nomes de métodos, nomes de variáveis, etc.
  2. Seu método não deve ser tão longo que você não pode ver todo o método e os comentários em uma tela

Dito isto, há exceções. Mas eles são exceções. E o ponto com exceções é que eles são poucos em números. Você realmente só precisa explicar o código inline se estiver fazendo algo contra-intuitivo.

Uma situação típica em que você pode precisar de comentários em seu método é quando você aplica um hack local para otimizar a velocidade, mas que na primeira leitura pode dar a outro programador um momento no momento. Esse é um bom ponto para adicionar um comentário.

Mas, em geral: não, não adicione comentários em seus métodos.

    
por 28.02.2011 / 02:29
fonte
18

Acho que ele está falando de um caso como este:

public void upload() {
    // destination host
    String host = ....
}

Onde você poderia melhorar o código com um nome de variável mais explícito, em vez do comentário:

public void upload() {
    String destinationHost = ....
}
    
por 28.02.2011 / 02:25
fonte
16

Acredito que seu amigo esteja se referindo a "Código limpo", de Robert C. Martin. No entanto, acho que ele está simplificando demais a situação. O livro fala sobre métodos claros e descritivos, que todos nós devemos conhecer, mas que nunca podem ser repetidos o suficiente. O livro também recomenda tornar os métodos muito pequenos envolvendo qualquer bloco de código que possa receber um nome claro e descritivo em um método próprio. Portanto, se você achar que um bloco de código precisa de um comentário explicando o que ele faz, você deve torná-lo um método separado com um nome apropriado. Em teoria, se todos os seus métodos tiverem menos de 5 linhas, e se todos tiverem bons nomes descritivos, deve ser óbvio o que eles fazem sem ter que explicá-lo em um comentário.

No entanto, isso não significa que você nunca deve ter comentários dentro de seus métodos. O ponto é que os comentários não devem ser redundantes. Eles devem adicionar informações. Se você tem um método que faz exatamente uma coisa, e essa coisa é óbvia a partir do seu nome, então você não precisa de um comentário explicando o que ele faz. No entanto, faz todo o sentido ter um comentário explicando por que ele faz a coisa dessa maneira específica. Você pode querer um comentário explicando por que escolheu um algoritmo em detrimento de outro ou por que escolheu uma estrutura de dados sobre outra. Em outras palavras, você quer que o próprio código explique como funciona e deseja que os comentários expliquem as razões de suas decisões de design, i. e. por que as coisas são feitas dessa maneira particular.

O livro recomenda a refatoração de código incorreto em vez de comentá-lo. Esta é certamente uma ótima idéia em teoria, mas na realidade você pode não ter tempo ou infraestrutura, como uma estrutura de teste de unidade de trabalho com o conjunto apropriado de testes de unidade para fazer isso. Há momentos em que você se depara com uma base de código confusa, que precisa trabalhar ontem, e a única maneira de avançar é tentar entender as peças confusas e comentá-las como uma maneira de fazer anotações.

    
por 28.02.2011 / 04:05
fonte
8

Sim, você definitivamente escreve comentários dentro de métodos em Java.

Como convenção do código da Sun diz:

Java programs can have two kinds of comments: implementation comments and documentation comments. Implementation comments are those found in C++, which are delimited by /*...*/, and //. Documentation comments (known as "doc comments") are Java-only, and are delimited by /**...*/. Doc comments can be extracted to HTML files using the javadoc tool.

Assim, os comentários nos métodos são comentários de implementação.

    
por 28.02.2011 / 02:20
fonte
6

Eu discordo strongmente do seu amigo e afirmo que comentários de função in-line são uma parte muito importante da escrita de um bom código. Comentários de função são projetados para fornecer aos clientes do código uma melhor compreensão do que o código deve fazer - o que seus parâmetros e valores de retorno significam, os tipos de invariantes que ele espera ter na entrada e saída, etc. Comentários embutidos, no entanto, são dirigidos principalmente aos mantenedores do código e idealmente como uma série de notas mentais para o autor original do código. Eles tornam possível olhar para um método complexo que outra pessoa leu e intuir o que o autor original estava pensando. Eles também facilitam o diagnóstico de bugs, pois se os comentários descrevem qual é a intenção do código e quais suposições estão sendo feitas, pode ser muito mais fácil descobrir como um trecho de código está errado quando um mau funcionamento é detectado.

Eu pessoalmente acho útil comentários in-line porque eles me forçam a provar para mim mesmo que o código que estou prestes a escrever vai funcionar corretamente. Muitas vezes, vou criar o hábito de não escrever nenhum código sem primeiro comentar claramente qual é a intenção e como ela vai funcionar. Mais vezes do que não, isso me impede de cometer erros tolos no código, porque eu vou descobrir que minha explicação está incorreta ou não leva em consideração algum caso extremo.

Naturalmente, todo mundo tem sua própria disciplina de codificação, e talvez algumas pessoas achem mais fácil escrever código sem comentários embutidos e, em vez disso, dividir o código em vários métodos menores. No entanto, com base na experiência, descobri que comentários in-line são inestimáveis durante o desenvolvimento e a depuração, e extremamente úteis para outras pessoas que precisam examinar e manter meu código por muito tempo depois que mudei para outro projeto.

    
por 28.02.2011 / 02:21
fonte
6

Seu amigo pode estar expressando a noção de que os comentários são, se não forem um "cheiro de código", um " desodorante ". Isso não é específico para comentários no método, mas pode tender a ser mais verdadeiro de comentários no método do que de comentários de preâmbulo.

Quando você escreve um comentário, normalmente é para explicar alguma coisa. Quando algo precisa ser explicado - bem, não é auto-explicativo. Ótimo código é autoexplicativo. Então, quando você adiciona comentários, você está encobrindo sua falha em se autoexplicar, sem torná-los auto-explicativos. Então toda vez que você escreve um comentário como esse, ao invés de mudar o código - renomeando, extraindo o método, etc. - para tornar auto-explicativo, você está ficando aquém do ideal.

Mas todos nós ficamos aquém da perfeição de vez em quando. E geralmente é melhor adicionar um comentário explicativo do que deixar o código difícil de entender e não documentado.

    
por 28.02.2011 / 06:14
fonte
2

Ao comentar seu código (ou o código realmente mal documentado de outra pessoa), você pode ser confrontado com sentimentos de puro repulsa , ódio ou ira O código pode se comportar de maneiras frustrantes e inesperadas, e você pode ter que adicionar alguns hacks muito ruins para que ele funcione em algum prazo.

Em todos esses casos, expressando seus sentimentos anotando as respectivas partes do código com alguns palavrões pesados (veja o fuckcount do kernel do Linux ) é uma prática comum. Esses comentários devem estar dentro dos métodos para que eles não apareçam na API documentada automaticamente, de modo que nem seu chefe nem seus clientes, nem qualquer outra pessoa agnóstica de código fonte, jamais o verão.

Seus colegas programadores, no entanto, sentirão grande alívio e felicidade ao estudar a fonte. (E, claro, você pode adicionar notas a si mesmo ou usar o código-fonte como meio de comunicação, em certa medida, #TODO: add more examples here )

É claro que você pode argumentar que esses tipos de comentários não devem estar lá em primeiro lugar, ou que eles devem ser removidos antes do lançamento final, mas atualmente os projetos de software têm ciclos de lançamento muito curtos e alguns comentários ainda são relevantes muitas construções noturnas depois, então talvez seu amigo deva começar a aprender a ler (e escrever) entre as linhas .

    
por 28.02.2011 / 15:36
fonte
2

Bons comentários explicam porque não o como. Essa é a distinção fundamental aqui. A maioria das pessoas será capaz de seguir o que você está fazendo, mas por que você fez isso requer comentários extras. Esses comentários devem estar próximos da operação possível.

    
por 28.02.2011 / 16:03
fonte
1

É uma prática comum para programadores colocar comentários dentro de métodos sempre que eles acham que não está claro para outros programadores o que o código está fazendo. Além disso, os programadores colocam comentários TODO dentro do método, às vezes. No entanto, é verdade que, se você tiver muitos comentários dentro dos métodos, talvez seja necessário voltar atrás e pensar se estiver fazendo coisas muito complicadas do que deveria. Em outras palavras, você provavelmente evitará comentar sobre algo óbvio para outros programadores, pois é mais difícil ler o código com eles.

Para tirar a sugestão de seus amigos de forma positiva, lembre-se de que podemos evitar comentar muito ao nomear variáveis e métodos adequadamente e manter cada método pequeno e garantir que eles não trabalhem demais.

    
por 28.02.2011 / 02:24
fonte
1

Acho que a razão pela qual ele disse isso é porque ele acredita que as funções devem ser curtas o suficiente para que cada uma encapsule apenas uma única operação conceitual.

Eu não necessariamente subscrevo essa crença ao extremo (por várias razões, incluindo a leitura de tal código pode se tornar um pesadelo), mas se um fizesse, poderia acontecer que eles tivessem apenas um comentário por função, como há apenas um conceito por função e um comentário por conceito.

De qualquer forma, eu uso comentários sempre e onde quer que haja código cuja escolha ou comportamento não seja imediatamente óbvio - muitas vezes tendo a ver com considerações de desempenho ou matemática esotérica. Esse tipo de coisa muitas vezes não diz respeito ao consumidor da função, então eu diria que é uma boa idéia escondê-lo da documentação.

    
por 28.02.2011 / 03:14
fonte
1

Acredito que seu amigo estava falando sobre o javadoc, que gerará documentação do seu comentário se estiver acima da declaração do método (e decorado com um asterisco extra) assim:

/**
   get a webpage for a given url 
   @param url: the url to get
   @returns String: the http-source 
*/
public String getWebpage (String url) {
... 

Se você colocar este comentário dentro do método, será inútil.

Portanto - como regra geral: colocar comentários na fonte java acima do método.

Exceções podem e irão ocorrer. Eu concordo em: usar métodos curtos, escrever código de auto-documentação. No entanto, o javadoc como ferramenta incentiva a duplicação de comentários, porque senão parece tão nu na documentação. :)

    
por 28.02.2011 / 07:03
fonte
1

Admito que, em um método escrito do zero, é possível documentar sua função apenas no cabeçalho. No entanto,

Eu acho que os comentários são frequentemente inseridos onde os bugs foram descobertos e uma nuance sutil foi ignorada mesmo se o método tiver apenas uma responsabilidade - que sejamos honestos, raramente é o caso no código legado . Além disso, não vejo razão para ter um nome de variável com quarenta caracteres (mesmo que seja usado apenas em dois lugares) quando um nome de variável mais curto com um comentário sucinto puder ser mais facilmente digerido e reutilizado posteriormente. Limpo e conciso é o melhor, mas acima de tudo, é um meio de comunicação para outros programadores tanto quanto e-mails, cartas e poesia também. E para isso eu adiciono a citação:

"Eu só tornei esta carta mais longa porque não tive tempo para torná-la mais curta."

Blaise Pascal, (1623-1662) Lettres provinciales

    
por 28.02.2011 / 07:42
fonte
1

É bom ter código que não precise de comentários. Quando você obtém, salva e exclui coisas, temos uma boa ideia do que está acontecendo e não precisa de comentários.

Às vezes, o código fica confuso e é um candidato para refatoração, então você pode ter que comentar nesse meio tempo.

Hoje eu tive uma linha de código que não faz o que é esperado. Aparentemente, uma tabela de dados .net não acredita que uma linha importada seja um novo registro. Quando você insere os registros da tabela, nada acontece. A linha que está sendo importada precisa ter seu status alterado primeiro. Um simples comentário é tudo o que é necessário, então quando eu voltar a ele daqui a seis meses e pensar: "Para que diabos eu preciso disso?" Eu saberei.

    
por 28.02.2011 / 23:13
fonte
0

Os comentários apenas tornam o código mais amigável ao programador, lembre-se de que os comentários não serão executados.

Se você ler seu código depois de alguns meses, os comentários facilitarão a leitura do código.

Ele tornará o código sustentável e qualquer outro programador que olhar o código achará fácil entender a lógica que você implementou.

Isso não significa que você sempre tenha que adicionar comentários, mesmo para um método com poucas linhas de código.

Como, por exemplo, o código a seguir é auto-explicativo e não requer nenhum comentário para tornar sua função clara

public String getName(){
    return name;
}

Quando um método é grande, adicione comentários para que seja mais legível sempre que qualquer programador olhar para ele.

Lembre-se de que, ao codificar, você pode pensar que o código é auto-explicativo, mas depois de seis meses, os comentários adicionados seis meses atrás ajudarão você ou qualquer outro programador a entender o código rapidamente.

    
por 28.02.2011 / 09:56
fonte
0

Em primeiro lugar, sua pergunta foi especificamente orientada para Java - o que influencia significativamente a resposta.

A quantidade de comentários exigidos está altamente relacionada ao idioma em que você está trabalhando.

  • Algumas linguagens como Java e C # se prestam muito bem ao conceito de código de auto-documentação. Nessas linguagens, seus esforços são mais bem aplicados, tornando o código em si o mais legível e descritivo possível, e adicionando comentários em linha apenas para coisas que você não pode descrever nativamente dentro do idioma.

  • Algumas linguagens como SQL são mais difíceis de serem legíveis. A sintaxe, a ordem de avaliação, o aninhamento e assim por diante podem tornar mais desafiador o design de maneira autodocumentável. A mesma abordagem básica ainda se aplica: concentre-se em usar o idioma o máximo possível, depois adicione comentários para compensar áreas que não são claras ou confusas.

No geral, você não pode 100% abolir os comentários, mas seu objetivo deve ser remover a necessidade de comentários, tanto quanto possível, tornando o código mais autodescritivo. Os resultados desses esforços geralmente são menos código geral e melhor código organizado. Independentemente de haver ou não comentários presentes, isso significa que seu código será muito mais fácil de manter e acessível - o que é realmente o que os comentários devem ajudar em qualquer consideração.

    
por 28.02.2011 / 16:23
fonte
0

A idéia de que o Javadoc (ou mesmo o autopreenchimento Delphi sugere) deve mudar a maneira como uma pessoa codifica (além de adicionar funcionalidades para o javadoc) é bastante absurda.

Pergunte ao seu amigo que veio primeiro, o javac ou o javadoc?

É como perguntar qual veio primeiro, a vaca ou a Sra. O'Leary

Além disso, o javadoc deve ser para pessoas que implementam sua classe e funções, os comentários no código são para as pessoas que estão mantendo seu código. Especialmente com seus métodos privados, ninguém deve necessariamente ter que olhar seu código para ver o que ele faz. Isso é o que o doc é para. Mas se alguém precisar ajustar algo por causa de um erro por um erro, então você quer comentar isso em seu método.

Ele está, obviamente, assumindo que 90% do código é, na verdade, correções de bugs. Eu nunca li "O programador pragmático", mas posso supor que ele não está fazendo referência a esse livro.

    
por 28.02.2011 / 16:45
fonte
0

Vou jogar meus dois centavos agora que a festa está bem acabada. Eu uso comentários quando estou descrevendo um pouco específico da lógica de negócios ou quando eu tenho que adicionar algo para cobrir uma borda imprevista.

O código evolui ao longo do tempo para explicar coisas que não eram conhecidas de antemão, e então quando você aplica um band-aid, em vez de assumir que é conhecido por que você coloca esse band-aid, às vezes ajuda a adicionar um pequeno bloco dentro do código que diz "ah, a propósito, eu tive que consertar isso e aqui está a referência do bugtracker para que você possa acompanhar a conversa" e no meu caso (como eu uso o FogBugz) é assim:

//Case: 1234 ~ Throttling based on unusual activity per ABC request.
Throttler myThrottler = new Throttler( oldActivity );

ou qualquer outra coisa. Então, meu ponto é que algo que parece fora do lugar e não é tão legível é provavelmente um bom lugar para documentar inline. O conhecimento coletado é uma coisa linda.

Mas meu primeiro ponto foi minha lógica de negócios. Eu literalmente tenho um bloco em um procedimento armazenado que estou prestes a reescrever este AM que tem algumas regras de negócios na frente.

/****************************************************************
author  yourstruly
date    2010-11-18
descrip intended use is to blah blah blah
        ended up over actual measured blah blah blah according to blah blah blah
        rules from the customer are:
        If the sum of the blah blah blah is higher than the blah blah blah
        and the blah blah blah contain blah blah blah,
        and the blah blah blah is non-zero,
        recalculate the blah blah blah to fit within the blah blah blah

        Additional rules for us internally: 
        if the blah blah blah originally read blah blah blah don't blah blah blah (set to zero)

        rewritten here with (1) traceable statements for the where clauses.
        If 
            the blah blah blah(1) is higher than the blah blah blah (2)
        and the blah blah blah (3)
        and the blah blah blah is non-zero (9)
        and the blah blah blah is lower than the blah blah blah (4)
        and the edited blah blah blah is higher than the blah blah blah (5)
        then recalculate the blah blah blah (6)
        // See note lower in this document on the math

        If 
            the blah blah blah(1) is higher than the blah blah blah (2)
        and the blah blah blah (3)
        and the blah blah blah is higher than the blah blah blah (7)
        then set the blah blah blah to zero (8)

        (7) dictates the same as (4) but it's easier to do (7)
****************************************************************/

Sorry for the blah blah blah's but proprietary rules and all that ;)

E de repente você vê que eu tenho requisitos (!) incorporados no meu código como comentários e posso me referir aos comentários como /*(1)*/ (o que eu faço) para que isso seja facilmente rastreável para o próximo funcionário ( que foi, e ele foi capaz de encontrar as partes que precisavam de ajustes imediatamente) e, em seguida, se alguém quiser saber o que a especificação era, eles podem ler o comentário de cima, e se alguém quiser saber o que é o pseudo-código é lá e se alguém quiser converter o pseudo-código para o código, aí vai você. Para mim isto é muito mais legível (no meu caso), pois preserva o pedido original (recortado do e-mail) e permite que a linha de pensamento seja rapidamente reunida sem muita reflexão, e permite o uso de transformações fáceis do pseudo em código real.

E sim, há alguns comentários in-line dizendo que tal e tal não funcionaram como esperado no pseudo-código porque o requisito não combinava com os dados, então precisávamos ajustar os dados. Mas esse é o meu ponto. Documentamos em linha os casos de borda e deixamos o pseudo-código no código adequado para seguir a lógica, então todos sabíamos o que era esperado dos requisitos originais

    
por 28.02.2011 / 18:27
fonte
0

O problema com comentários embutidos é que eles precisam ser mantidos junto com o código (também verdadeiro para comentários de função / método / módulo / nível de classe, mas não tão grande); Deus sabe o quanto o código-fonte ainda está lá fora, onde os comentários não têm absolutamente nada a ver com o código que eles documentam mais, o que é tão ruim ou pior do que não ter nenhum comentário.

Idealmente, a documentação em linha deve ser limitada às seguintes situações:

  • Explicando o código que é altamente otimizado ou "complicado", juntamente com uma justificativa para por que o código é tão otimizado ou "complicado" ("estávamos faltando o requisito de desempenho X e o perfil mostrado o gargalo a ser nesta seção; as otimizações abaixo ganharam desempenho de Y% ");

  • Referindo-se a um padrão ou requisito ("DTED 0 espaçamento entre postes é 30 segundos de arco");

  • Identifique o código que precisa de análise / desenvolvimento adicional ("TODO");

Primeira lei de codificação - não documente o óbvio. Corolário da primeira lei de documentação de código - escreva código que seja óbvio na maior medida possível.

    
por 20.02.2012 / 01:59
fonte
-1

Seu amigo está errado.
Seu amigo está parcialmente correto em que o usuário do seu método só precisa ler os comentários da documentação. No entanto, a menos que você esteja escrevendo um código de limpeza claro e inequívoco que NUNCA precisará ser modificado por qualquer motivo (isso significa que os requisitos e as plataformas nunca serão alterados), então os comentários no corpo são muito úteis.

Quando escrevo código com um design pouco claro (Isso acontece, não deveria, mas acontece) Muitas vezes, escrevo os comentários da documentação (o que o método deve fazer), o bloco do método (Retorno 0, retorno nulo, throw NotImplemented - O que você precisar) e depois escrevo comentários de implementação como:

//Get Connection String
//Connect to DB !!-- EXCEPTION --!!
//Build Query and Params.
//Parse Query Results
//Return answer

Isso me dará uma ideia clara do que precisa ser feito. Isso também dará ao desenvolvedor futuro uma ideia clara do que eu estava tentando realizar.

Em outras palavras, os comentários da documentação são para os usuários, explicando o que está sendo feito. Comentários internos (Comentários de código) são para desenvolvedores, explicando como isso está sendo feito.

    
por 28.02.2011 / 16:59
fonte
-1

Grande pergunta.

A resposta pode ser "depende".

Se você puder dividir uma porção pouco clara em um método ou função própria, faça isso, e outras pessoas que precisam manter seu código irão aparecer e chamá-lo de abençoado. Use os comentários do Javadoc para deixar o claro mais claro. Este pode ser o ponto principal do seu amigo.

Aqui está uma citação de um texto que não consigo lembrar (e peço desculpas ao autor):

i++; // increment the counter

O ponto do autor no exemplo é que o comentário é supérfluo. Se você fez a Programação 101, não precisa do comentário.

Se você estiver fazendo algo que não seja óbvio para os outros (ou possivelmente para si mesmo daqui a seis semanas), então, por favor, comente o óbvio não tão óbvio.

Por exemplo, você compreende imediatamente

assertFalse("valid status differs", file1.isValid() ^ file2.isValid);

ou você pode ser ajudado por esses comentários

// Java XOR operator a^b returns true iff a and b differ.
// If file1 and file2 are both isValid, return false.
// The assertion is that the two versions of isValid should be the same.

Mesmo que você seja excelente com operadores booleanos e use o XOR regularmente, os comentários devem ajudar e agilizar sua compreensão.

Ou considere este fragmento para converter uma string em um int, usando um Number n, sem comentários:

...
} else {
  Double d = (Double) n;
  Long l = d.longValue(n); 
  int ans = n.intValue(); 
  if (l.equals ((long) ans)) return ans; 
  throw new ParseException("Field too big to be stored as int");
}

Compare com o código comentado:

...
} else {
  // n must be a double
  Double d = (Double) n;
  Long l = d.longValue(n); // l contains the sInt as a long
  int ans = n.intValue(); // was it truncated?
  if (l.equals ((long) ans)) return ans; // not truncated -- they were equal as longs
  throw new ParseException("Field too big to be stored as int");
}

Admito prontamente que este último fragmento é "strongmente comentado". Eu acho que bons programadores irão codificar para ajudar a comunicar e esclarecer. Errar do lado de comentários liberais. Você sempre pode removê-los depois.

    
por 28.02.2011 / 17:44
fonte
-4

Comente quando for necessário, não tanto quanto possível.

    
por 19.02.2012 / 21:34
fonte