Comentar Códigos é uma Forma de Fracassar // Análise do Livro Código Limpo (Capítulo 4)

🚀𝗘𝗦𝗧𝗨𝗗𝗘 𝗡𝗔 𝗧𝗥𝗬𝗕𝗘 → codft.me/trybe
Aconselhamos você assistir esse vídeo antes de comentar em seus códigos. Analisamos a fundo o capítulo 4 do livro Clean Code, onde ele descreve em que situações usar e não usar comentários. A verdade é que são bem poucas as situações em que se é aceitável ter comentários em códigos. Por muitos anos ignoramos esse capítulo do livro e por isso aproveitamos para fazer um "mea culpa" dos nossos erros do passado.
📚 𝗟𝗶𝘃𝗿𝗮𝗿𝗶𝗮 𝗱𝗼𝘀 𝗖𝗗𝗙𝘀
→ Livro Clean Code: amzn.to/3HW8yDd
📝 𝗟𝗶𝗻𝗸𝘀 𝗖𝗶𝘁𝗮𝗱𝗼𝘀
→ Livro Clean Code (Capítulo 1): • O que é Código Limpo? ...
→ Aprenda a dar nomes aos elementos (Capítulo 2): • Programadores Profissi...
→ Suas funções nunca mais serão as mesmas (Capítulo 3): • Suas Funções Nunca Mai...
→ Entender Código é Tão Importante Quando Fazer Rodar (Capítulo 5): • Entender Código é Tão ...
→ Acompanhe a playlist sobre o Livro Clean Code:
• Clean Code - Desvendan...
🎙️ Compilado Podcast
→ KZbin: codft.me/canal...
→ Spotify: codft.me/compi...
→ Newsletter: compilado.codi...
🔗 Mais links do Código Fonte TV
→ codigofonte.tv
#cleancode #agile #programação
#MãoNoCódigo67

[@IgorogI1000]

Não levem livros como um conjunto de dogmas, e sim ideias e sugestões. Existem pessoas tão experientes quanto o Uncle Bob que discordam dele, e isso faz parte da vida. Minha visão sobre comentários em código é: praticamente não uso, porque meu código é geralmente bem autoexplicativo, mas quando há cenários específicos, exceptions, acho que é válido esclarecer com um comentário. Mas em se tratando de libs que vão ser usadas por pessoas fora do seu time de desenvolvimento, comentários são bem importantes para que a pessoa rapidamente entenda como um código funciona sem precisar lê-lo.

[@samuel_do_prado]

Façam outra série sobre o Refactoring ou Clean Architecture, por favor, são tópicos muito úteis

[@BeTrybe]

Ótimo conteúdo! 👏 Acredito que, para quem está aprendendo, os comentários são muito úteis. Mas é muito importante não esquecer de voltar neles e buscar sempre melhorar o código para que, no futuro, eles sejam um recurso que mais ajuda do que atrapalha, principalmente para quem exagera na quantidade e torna o código muito poluído.

[@noriller]

Numa discussão que tive recente, a ideia geral era de comentar os porques e os quando usar. Normalmente comento mesmo algo pra ser usado "pra fora" ou que outros vão precisar aprender algo pra usar (refatorei um código que usava de uma lib, e já que tava aprendendo pra usar, já deixei comentado e com jsdocs uma descrição do que passar em cada coisa pro próximo, ou eu mesmo usar depois). Algo importante de comentar é sempre o "parece mais não é", tem coisas que você olha e pensa: não dava pra fazer assim? Dai quebra o código e a cabeça, então já é bom deixar o lembrete que não, aquilo tem uma razão de ter sido escrito daquela maneira.

[@timoteoqueiroz1627]

Isso mesmo, mts vezes o código ja passou por uma pancada de testes, e tem q ficar dakele jeito mesmo pra funcionar, de um modo q parece contra intuitivo, passível de refatoração por alguem outro q bater o olho ali. Ai comento pra não deixar o outro programador bater a cabeça em vão tudo denovo.

[@fabiovicente4322]

@@timoteoqueiroz1627 penso igual vc...

[@joaopessanha5774]

Eu comento algumas partes do meu código mas estou sempre procurando deixar meu código mais clean, afim de evitar comentários. Obrigado pelas dicas código fonte.

[@marceloLoschiBH]

Se não comenta é preguiçoso, se comenta é pq não é claro, está parecendo a revista Você SA , se Deus se candidatar ele não consegue entrar...

[@JohnDoe-bu3qp]

O que eu sempre falo é que comentários devem dizer "porque", e não "o que". Se entre o nome da classe, do método e das variáveis não deu pra entender o que o código faz o problema é outro. Mas pode ser que o que você está fazendo precise de contextualização pra outra pessoa não ter que ir ler um monte de outros méotodos. Também não deveria acontecer muito em uma aplicação coesa.

[@marciorjusto]

@@JohnDoe-bu3qp Gostei dessa estratégia. Nem sempre conseguimos nomear objetos corretamente (ainda mais se vêm de algum framework externo ou pacote fechado) então algum comentário é necessário para justificar aquela lógica

[@filipianjos6583]

No final do vídeo eles dão exemplos de bons comentários. Comentar algo que deveria ser explicado no código demonstra, desleixo ou inexperiência do autor .

[@andre-SJP-PR]

Muito interessante. Realmente ,uma variável bem nomeada elimina, no mínimo uma linha de comentário.

[@darkneslightgamer9172]

Eu comento apenas se algo for complexo

[@papking6092]

Eu vou continuar comentando. Mas vou tentar fazer isso de melhor forma.

[@marciorjusto]

Não são regras, mas boas práticas! Os próprios "gurus" estão cansados de responder no Twitter: "Usem o bom senso!"

[@edupazz]

Meu tipo de comentário "desfavorito" é o famoso "// TODO: ..." que quando tu vai ver no git blame tem uns 3 anos

[@zardobeckerg.1220]

Estou adorando essa série! Pensei tambem nos outros dois livros do codigo limpo, para uma futura série! Obrigado!

[@sergioaraujo9886]

No caso do comentário que informa as circunstâncias em que funciona é muito útil quando outras pessoas alteram o código, porém nem todas são responsáveis pelo resultado. Em empresas ou organizações onde falta ordem, respeito e disciplina é muito útil.

[@XKMetralhaDO]

Normalmente, se precisa comentar, é pq tem algo estranho com o código, com exceção de coisas muito específicas.

[@TheSamfelgar]

Trabalho com PHP e pra mim, o único sentido de comentar é usar docblocks, para ajudar a IDE a me ajudar, definindo tipos que ainda não são possíveis usar nativamente, como generics, por exemplo.

[@samuel_do_prado]

Costumo adicionar as exceções que podem ser lançadas também

[@martafernandes1837]

Sinceramente, se existe a possibilidade de fazer comentários no código, é porque é importante. Quando faço manutenção muitas vezes comentário deixados por outro programador me ajudou a entender regras de negócios.

[@DevAteAAlma]

"...se existe... é porque é importante" foi o que eu pensei antes de assistir ao vídeo

[@CharlyBraga]

Este livro do uncle Bob me ajudou visualmente no trabalho. Passei criar funções pensando em deixá-las altoexplicativas, sem precisar de comentários, e realmente funciona. Como é dito no livro, os comentário ficam obsoletos e passam a contar mentiras sobre o código. Quantas vezes a gente acessou uma função, às vezes nossa mesma, em que os comentários já não faziam sentidos? O livro é um grande investimento, e cada página que você lê já consegue aplicar no seu trabalho. Algumas dicas que lembro do livro que validei na prática: - Use nome altoexplcativos, descritivos não repetitivos em em funções e variáveis - Use funções pequenas, que fazem coisas específica (não use uma função gigante que faça várias coisas) - Evite comentários, faça seu código ser o comentário - Não tenha preguiça, refatore se precisar - Evite código repetitivo, coloque tudo em único lugar, como função (facilita manutenção) - Use espaçamento e identação no código - Trate exceções quando necessário Dentre outras...

[@claudiojunior2578]

Eu concordo com tudo isso, mas eu gosto de colocar aqueles comentários que até uma criança de 5 anos entende kkkk, só assim consigo assimilar o que estou estudando, muito legal essa aula!

[@lucasarend7164]

Eu uso comentários só para explicar a regra de negocio, quando acho que é algo mais complexo. Ótima serie!

[@robertomelo8815]

Comentar código deve ser entendido de várias maneiras. Uma delas é quando o comentário serve de documentação rápida, no começo de uma classe ou biblioteca, explicando o conteúdo e usos de forma suscinta, já salva tempo, pois quem lê não precisa ler todo o código para saber o que tem disponível ali, principalmente se for disponibilizar ao mundo. Esses dias peguei um dos melhores exemplos em código de arquitetura hexagonal, porém, sem nenhum tipo de documentação no repositório, sem a arquitetura e sem comentários. É possível fazer tudo isso à partir do código? Sim... mas quem fez o código deve ter desenhado também a arquitetura. Um pouco de comentário em algum ponto mais complexo ou onde existe uma padronização de formato e nome também é bem vindo. Outra questão é a limitação de tamanhos de dados e de arquivos em algumas linguagens e sistemas. Antigamente, era muito comum abreviar nomes de variáveis e funções. Hoje em dia é aceitável utilizar nomes tão grandes quanto uma tela curva de 3840px couber, tudo em nome da legibilidade. Por fim, em AUTOMAÇÃO INDUSTRIAL, por exemplo, é OBRIGATÓRIO utilizar comentários e simbólicos em programas de CLPs, por exemplo, pois eles servem de ALIAS no programa. O código fica simplesmente ILEGÍVEL sem comentários ou sem o projeto, inclusive, isso é utilizado por algumas empresas como forma de proteção de propriedade intelectual ou cobrar bem mais caro para fornecer o projeto, mesmo sendo possível programar de forma que a inteligência do sistema fique protegida e inacessível, mantendo o mínimo disponível para manutenção.

[@MagnoLima]

Se você esta desenvolvendo uma rotina ou função utilitária, algumas linguagens como o Swift por exemplo, no Xcode, faz uso de um comentário para ajudar explicar o uso dela, se tem parametros, etc, no caso do Xcode você mesmo promove o completion para o help da sua rotina, isso é um tipo de comentário muito interessante.

[@DaniloStill]

No C# existe o summary, aqueles comentários no cabeçalho criados quando se colocam 3 barras "///". Esses comentários descrevem o método e também seus parâmetros e retorno, que são atualizados automaticamente se você mudar os parâmetros ou o retorno. Quando você utiliza o método, essas informações são exibidas pelo Intellisense.

[@marcosr.weimer3433]

no Delphi tambem tem

[@dspic33]

Quero ver vocês programarem e/ou configurarem os registradores um microcontrolador sem comentar o que cada bit do registrador representa, ou comenta ou abre o DataSheet milhares de vezes. Impossivel prosseguri sem comentar, nem que seja copia do DS.

[@Unknown-868]

Há casos e casos. No geral o Clean Code se aplica a OOP, o cenário que você está ilustrando não atende a isso. É o caso clássico do código de baixo nível, espaguete e salve-se quem puder! 😁

[@marciorjusto]

A intenção do livro - e acredito que do canal - não é impor uma regra, mas incentivar boas práticas conforme cada tecnologia disponibiliza.

[@mmaldonadojr]

Exatamente meu caso, me especializei em embedded com linguagem C. Eu morro de rir com a indústria moderna de software, parece a TV Câmara com os parlamentares discutindo projetos de lei na tribuna!

[@Lucian-Alves]

Existe um abismo de diferença entre comentar *o que* um código faz e comentar *pra que* ou *porque* foi feito assim. Quem entende essa diferença consegue detectar as exceções onde um comentário no código pode ser útil. Mas de fato existe muito comentário desnecessário, como os abordados no livro, que eu costumo encontrar principalmente em código legado. Já vi até comentário "TODO" abandonado no código há mais de 5 anos.

[@julioDinisdLima]

Para mim, os comentários do phpdocs e Java docs incluindo os com exemplo de utilização é muito prático quando está na ide e com um atalho de teclado acesso essa informação.

[@miguellopes9177]

Clean code fala sobre aqueles loops gigantes? Aquele while que começa linha 23 E acabar na 712. Não sei se é mal prática, mas eu acho que é, odeio esse tipo de coisa, eu pelo pelo menos tenho dificuldade em entender esse tipo de prática.

[@Unknown-868]

Com certeza tem uma falha de design nesse código! Provavelmente está quebrando os princípios SOLID e consequentemente não está de acordo com o Clean Code.

[@miguellopes9177]

@@Unknown-868 isso foi um exemplo, Porque o code que eu lembrei que fazia isso.... Trechos de código no meio da página. Mão encostados, não identados e sim No meio.

[@eBrunoro]

Se uma função minha tem mais de 15 linhas, eu a divido em funções menores. Se tiver mais que 3 níveis de identação, também

[@WILLKATECH]

Eu utilizo os comentários pra organizar o código, e pra qdo eu enviar o código pra alguém que tem menos conhecimento consiga aprender com o código e entender

[@arcstur]

O cargo test, do Rust, tem uma feature muito legal para não deixar os comentários/exemplos de documentação obsoletos. Além de rodar os testes unitários e de integração, ele roda os exemplos utilizados na documentação!

[@codigofontetv]

Aí sim! Se ter utilidade prática então está liberado. :D

[@rafaelparrini]

Isso coleguinha, não comenta não. Confia! =]

[@akattsuki1ives]

***Comentando sem ter visto o vídeo ainda*** Sou estudante, e uma coisa q eu comecei a perceber a partir de ontem após algumas horas de estudo é q é possível olhar pra um código e saber tudo q ele faz se ele estiver bem organizado, a partir daí me perguntei se vale a pena ou não deixar comentários no código, vai fazer ele parecer até mais bagunçado, essa foi a minha visão e me interessei pelo assunto e aqui estou no vídeo de vocês, procurando saber sobre isso... •Aahh, e estou MT feliz por ter progredido agr eu consigo ler um código inteiro sabendo oq cada coisa faz e assim eu consigo achar onde está erros

[@thiagoandrade7365]

Eu não comento nada, não vejo necessidade pois quem olha o meu código entende tudo, ele é simples e conciso.

[@digodasilva]

Ia comentar aqui nesse vídeo, mas depois dessa paulada eu desisti. Hahahaah Piadinhas infames à parte, parabéns pela série.

[@eder_tinti]

adicione mais comentários aqui, e menos comentários no código... também daria para falar dos "cometários de comentários"... que é quando mais de uma pessoa trabalha no código e começam a comentar que nem um chat, dá até para agendar uma reunião pelos comentários

[@carlos28018]

Comentar ou não, pelo que entendi do livro e pelo vídeo, é uma questão de percepção se vale a pena ou não e como o Uncle Bob sugere, se com o tempo aquilo não irá se tornar algo mentiroso. Eu acrescentaria que muitas vezes um comentário é inserido por não haver discussão com a equipe sobre determinada ação.

[@edupazz]

14:58 nesse caso em específico eu consideraria que uma refatoração mitigaria a necessidade do comentário. Jogar o magic number 40 em uma constante MIN_QUALITY_THRESHOLD ou algo do tipo já daria pra remover o comentário e o porquê desse número ainda seria claro para o leitor.

[@Unknown-868]

Quando a gente para pra analisar, todo código comentado só foi comentado por falta de design pattern ou boas práticas de programação.

[@ViniciusSouza-gi2kr]

Eu uso muito comentário enganador quando estou aprendendo algo novo, pq nesse caso, pra mim, realmente não tem nada de óbvio em algumas coisas

[@codigofontetv]

Nesse caso vale comentar à vontade! Para aprender vale tudo

[@emanuelmoraes9668]

Claro que existem muitos comentários muito ruins por aí e talvez na maioria das vezes eles sejam desnecessários. Mas as vezes o comentário é necessário. Programar é a arte de abstrair. Muitas vezes precisamos criar conceitos do zero que não existem na linguagem natural ou não tem como ser obvio de se entender apenas batendo o olho (frameworks em geral fazem isso direto). A premissa de que o próprio código deve ser entendido por qualquer programador sem que nenhuma explicação seja feita, por menor que ela seja, limita a possibilidade de sintetizar conceitos diferentes em um só. Nestes casos, a alternativa ao comentário seria a obrigatoriedade de códigos mais extensos cheios de pequenos detalhes apenas para não usar uma palavra nova ou genérica que precisaria de um comentário, mesmo que breve, pra explicar o que ela significa. Isso sem falar das interfaces que ao serem usadas exigem a confiança de que quem implementou sabia de todos os possíveis pontos de atenção que por acaso não tem um comentário explicando.

[@betocaldas]

Esse do regex eu sempre faço e um outro que eu costumo fazer no mesmo sentido é quando crio algum filtro.

[@adrianomoura5397]

Vou continuar comentando no código-fonte e de forma sucinta e em métodos complexos. Simples assim. Para que futuramente outros desenvolvedores menos experientes possam compreender mais facilmente.

[@Roberto-oz6et]

Eu uso os comentários em projetos pessoais quando estou aprendendo algo novo. Eu já li comentários que mais me confundiram do que ajudaram então, num projeto compartilhado, eu evito comentar.

[@saturnosync]

Comento sempre que desconfio que vou esquecer. Ainda mais quando se desenvolve uma lógica nova. Aqui pelo menos funciona bem 😁

[@humbertoluks]

Simplesmente Espetacular

[@DaniloStill]

Se você precisa explicar o que seu código faz, algo está errado, rs. Porém, existem casos em que o comentário é muito útil, como cálculos fiscais e contábeis, geralmente baseados em alguma lei e que o comentário ajuda a explicar esses cálculos, mas, isso é uma faca de 2 legumes, porque se a legislação mudar e o comentário não, isso pode ficar obsoleto e confundir.

[@heitormbonfim]

To amando esse quadro pppppqqqqqqppppppp

[@youreale]

Como tudo na vida, isso depende da dose e do contexto: comentar CADA linha código é desnecessário, toma tempo e gera poluição (assumindo que você não esteja programando em Assembly). Ao mesmo tempo, não podemos assumir que as pessoas que vão manter aquele código tenham o mesmo nível de conhecimento que nós sobre o fonte e as decisões de arquitetura - principalmente em se tratando de um projeto complexo. Por isso é importante ter uma documentação no código sobre o que não é óbvio e que poderia ser interpretado erroneamente. O mesmo vale para decisões pouco "ortodoxas" que às vezes somos obrigados a tomar (os chamados "workarounds") para resolver certos problemas bizarros. Escrever código é como contar histórias e se ninguém entende o que você escreve, você está no ramo errado.

[@Unknown-868]

"Escrever código é como contar histórias", que frase bonita!

[@mmaldonadojr]

"O código-fonte deveria ser explicativo em 99% dos casos". Verdade, mas sou parte do 1% que programa em linguagem C para microcontroladores. Enfim, só comento o mínimo, o não óbvio, ou coisas que tenho medo de esquecer.

[@eBrunoro]

"Sem essa linha tudo para de funcionar" Eu tive que comentar em cima de um import que o VS Code insistia que era desnecessário

[@Unknown-868]

Vai ver era mesmo! 🤭

[@sauanbraddok]

estou terminando o clean code...é realmente muito bom, mas eu dei sorte de não ler tão cedo na carreira. O livro é excelente mas para dar realmente valor a esses conceitos é preciso antes entender o método no-rabo, ou seja, aprende tomando nele kk

[@danivalc]

Uma coisa que não é coberta aqui é quando o código fonte está errado. Imagina se naquela expressão regular usada no exemplo tiver algum erro, seria muito complexo descobrir a intenção de quem fez a expressão. Daí um comentário de código pode ser importante, dizendo o que o programador queria fazer. Um outro problema para brasileiros é o padrão de muitas empresas em fazer códigos em inglês. Muitas vezes algo é traduzido de forma confusa e só o comentário que salva. Um exemplo é como fazer o CPF, já vi muitas formas de traduzir e ajuda muito um comentário no campo dizendo que é o CPF ou o CNPJ.

[@pwcodigo]

Obrigado pelo conteúdo.

[@KauanCancelier]

Seria legal trazer o livro "Head first: Design Patterns", é um livro de acesso um pouco mais difícil principalmente pelo preço que ele está na amazon e em outros sites.

[@MyPezzini]

Eu uso swagger no meu dia a dia e realmente é uma maravilha

[@sergiolima2251]

Rapaz, depois deste vídeo irei reavaliar e muito a maneira como uso comentários em meus códigos kkkkkkkk Tem alguns que estão recheados deles. Mãe do céu hahahaha

[@technoir-1984]

Código comentado é sinalização de inexperiência e/ ou ignorância em estruturar um algoritmo. Todo código cheio de comentários que já peguei era um horror.

[@Edson_295]

Onde eu trabalho, nenhum pull request é aprovado com comentários no código

[@isaacsouto9302]

Eu usava bastante comentário no começo da carreira e com o tempo fui diminuindo, diminuindo e hj em dia não faço mais comentários, não me recordo da última vez que usei um comentário

[@danivalc]

Existe uma confusão no vídeo sobre comentários de documentação e de código. O comentário de documentação (JavaDoc) serve para quem vai usar o método em questão, então ele é focado em explicar para quem não tem o fonte O QUE o método faz, o que cada parâmetro representa e algumas variações no uso. Já o comentário de código serve para ajudar a quem vai dar manutenção no código a entender COMO o algoritmo foi feito e assim poder corrigir um bug ou implementar uma mudança de regra. O livro "Effective Java 3rd. Edition" do Joshua Bloch tem um item que é uma aula sobre como escrever bons comentários, o item 56. O autor deste livro é um dos "pais" do Java, que projetou a API de Collections e ajudou em outras estruturas importantes como Generics e Lambda.

[@earmarques1]

O livro dele que mais gostei é Arquitetura limpa. Terminando o clean code, este deve ser o próximo de vcs. Abraço

[@matheusacioli2861]

Quando li isso pela primeira vez minha reação foi: "O QUÊ?". Porém, quando você para pra analisar, faz total sentido. Se você se sente obrigado a comentar uma parte do seu código, é porque algo está errado e não dá pra entendê-lo lendo-o. Comentá-lo será como uma preguiça de deixá-lo legível por si só e pode acabar fazendo você ignorar isso achando que seu comentário dá conta. A melhor forma de tornar um código legível não é comentando, é nomeando bem as variáveis, extraindo funções, enfim, a legibilidade pode inclusive ser comprometida se tiver um comentário no meio do nada, pois acabará interrompendo o raciocínio do leitor que pensará "opa, preciso ler isso". Um bom código não precisa ser comentado, isso é uma regra. Basicamente, no meu dia a dia, eu reservo comentários pra coisas mais supérfluas, como especificar o autor do código, Copyright e raramente pra me ajudar a localizar partes do código.

[@maurodeamorim3229]

Não concordo, lidamos com milhares de linhas de codigo, tem que comentar sim, ora so porque um cara resolveu escrever um livro os aceitacionistas vão atrás faça me o favor.

[@faelpinho]

@@maurodeamorim3229 concordo contigo.

[@matheusacioli2861]

@@maurodeamorim3229 Tratam-se de dados estatísticos e análises com base em projetos de software de longo prazo. Comentários tendem a envelhecer mau. Deixar um código legível por si só dispensa o uso de comentários, pois muitas vezes eles até atrapalham a leitura. "Clean Code" não é um livro qualquer, é quase uma bíblia pra o desenvolvimento de software moderno e se você acha que quem segue seus princípios são "aceitacionistas", então você envelheceu mau como programador, muito mau.

[@emanuelmartins9508]

@@matheusacioli2861 Como q vc deixa um código que trabalha com várias threads ou tem cálculos matemáticos complexos ou dependências obscuras "legível"? Isso só funciona pra codificações simples. No máxmo de média complexidade, e mesmo assim vc teria funções, classes e variáveis dando pau no sistema por terem nomes grandes dms.

[@Unknown-868]

@@emanuelmartins9508 Como deixar legível? Aplicando os princípios do SOLID! :)

[@gabrielsiron4188]

Eu tenho a impressão de que, em projetos grandes, comentários do tipo "TODO" se perderiam, assim como quaisquer outros tipos de comentários. As pessoas teriam que procurar nos códigos por futuras implementações. Aí faz mais sentido ter um sistema como o GitLab ou GitHub, que de fato tem as ferramentas para gestão de pendências e issues, do que instalar uma extensão no VS Code pra isso. Já vi pendências desse tipo passarem meses sem ninguém fazer kkkkkkkkk, e se estivesse no GitHub a pessoa responsável pelo projeto poderia priorizar aquilo, direcionar alguém pra fazer...

[@cleversonsutil4495]

O melhor é acertar com toda a equipe a criação de um projeto chamado "Melhorias" e colocar lá o "ToDo" a se fazer no futuro. Ai vai acumulando com o tempo, e quando tiverem tempo, todo mundo revisa e decide o que fazer.

[@PCVARGAS]

Gabriel e Vanessa, na minha opinião NÃO EXISTE COMENTÁRIO RUIM, ruim é não documentar tudo !

[@Unknown-868]

Opa, documentação é coisa boa! Mas o tema fala sobre comentários dentro de rotinas, explicando o passo-a-passo do algoritmo ou coisas do tipo.

[@victorkinoshita9575]

O pior tipo de comentário é aquele que é um romance de 500 páginas e no final é só um clichê.

[@ReyMisterio-yt3xq]

obrigado pelas dicas👌

[@Andrewscarlosreis]

Façam outra série sobre o Design Patterns do GOF

[@olddeveloper8648]

Cada caso, um caso, a documentação é sim necessária caso você crie uma API ou biblioteca, sempre usando o modelo de documentação da própria linguagem, para gerar documentação externa.

[@fabiovicente4322]

Comentário em código só acho válido pra quem está entrando na empresa. Se durante o desenvolvimento do código o criador do projeto puder mastigar a idéia do negócio do site ou software, o programador que assumir as melhorias nos códigos deste projeto já poderá ter uma visão do projeto todo, evitando assim que o novo programador tenha que fazer centenas de perguntas ao gerente de TI da empresa.

[@dobbbri]

Configuro o editor para ocultar (fold) todas documentação no código

[@ChrisACorrea]

Sou dono de usar comentário posicional. Principalmente em html para separar "componentes". KKKKKK

[@joaodutra]

Não vejo o cleancode como o santo graal da boa codificação. Tem muita mas muita informação útil.. aprendi muito com ele mas... desde que vi esse livro falando que tenho que enfrentar o cliente em defesa de um bom código...fiquei com meu pé atrás com esse livro.

[@codigofontetv]

Oi João não vejo problema nenhum no seu pensamento. Algumas das lições fazem mais sentido para uns do que para outros. Em alguns pontos parecem ser mais lições filosóficas do que práticas e técnicas. Por isso há tanta discussão em torno dele, o que é salutar.

[@joaodutra]

@@codigofontetv Exato! É um ganho gigantesco ler esse livro. Mas como tudo na vida, sempre devemos ter um olhar crítico. Parabéns pelo conteúdo de vocês!

[@evertonoliveira9985]

Talvez o que você tenha entendido como "enfrentar o cliente" seria uma postura do programador em defender o código-fonte de solicitações que eventualmente venham prejudicar a lógica, a arquitetura do sistema ou o padrão (como queira chamar) em que foi construído o sistema ao longo do tempo se utilizando de boas práticas de desenvolvimento. Esta armadilha é baseada na crença de que "o cliente sempre tem razão" quando, ao meu ver, isso não é verdade, pois é comum que o usuário faça solicitações fora do escopo do projeto ou que queira acrescentar funcionalidades que em nada têm a ver com o propósito do sistema, obrigando o desenvolvedor a criar os famosos "puxadinhos" que ao longo do tempo vão transformar o sistema em uma verdadeira "favela" de código. Você não contrata um pedreiro para construir uma churrasqueira no banheiro, certo? Pois é, mas as vezes é isso que o usuário quer e todo bom desenvolvedor deveria se recusar a fazer algo deste tipo.

[@jonnyvv]

O comentádio válido de verdade são os feitos nos vídeos do Código fonte TV! Fiz muitos comentários desnecessários e até bizarros trabalhos anterioes, felizmente o atual tech lead nos iluminou com o Clean Code hahahaah Uma serie de vídos sobre livro Design Patterns também é uma boa.

[@evertonoliveira9985]

Li o livro e concordo com ele: "O melhor comentário é aquele que não precisa ser feito".

[@fernandocarmo532]

Boa parte do meu código é escrito para ser lido por um humano, até mesmo trechos bem pesados, basta separar em funções menores com nomes compreesíveis. Comentários só JSDoc mesmo XD

[@selmobergamin]

Só concordo com 50%...

[@cortespoliglota]

Eu só comento áreas e funcionalidades no código.

[@edlinux]

Vi o vídeo ontem a noite e hoje de manhã não consigo comentar nada no código hehehe.

[@codigofontetv]

🤓🤓🤓

[@gabrielm_dev]

Seria bom se lançassem um novo clean code.

[@faelpinho]

Sim, principalmente revendo essa regra, digamos, ultrapassada.

[@silasnatan8575]

O próximo poderia ser o eXtreme Go Horse! 😬😅

[@codigofontetv]

😅😅😅

[@jonathanemanuel76]

Eu uso comentários to dos quando tem algo que não tô com vontade de fazer na hora ou realmente não dá pra fazer mesmo. Middlewares e exceptions normalmente são coisas não tenho vontade de fazer e espero acumular pra fazer várias de uma vez

[@leandromartins6935]

Os comentários são obviamente dispensáveis nos exemplos apresentados, que são curtos e simples de refatorar. Mas em uma aplicação real, muitas vezes grande demais, o comentário é um aliado sim. Tudo o que for facilitar a sua vida é valido... se vc vive bem sem os comentários, ai é uma posição profissional de cada um

[@gu00col]

eu uso comentarios mais pra marcar fazes da excução isso me ajuda a navegar em codigos gigantes quando preciso achar alguma coisa

[@FernandoTakeshiSato]

Outro dia me deparei com uma exceção no ambiente de teste, fui ver era porque a imagem do docker não tinha a fonte usada pelo app. O correto, acho, seria colocar a fonte como resource no aplicativo, mas na correria eu só troquei a fonte do app antes de criar as views nos setups dos testes. Funcionou, mas ficou aquela linha completamente sem contexto trocando a fonte do nada...e um comentário dizendo o porque. Na hora me veio aquela cena do Game of Thrones "shame, shame" hahahahaha mas fazer o que, quando tiver um tempinho eu limpo! p.s.: quem nunca? 😅

[@charlesmarques6045]

Faltou o comentário tipo "desodorante em suvaco suado": Um método Faz tudo com mais de mil linhas e um comentário de uma linha só antes: "Aqui começa o show"😂🤣

[@Unknown-868]

Bem real!! kkkkkkkkk

[@lhamaalada4302]

eu comento pra facilitar a deixar a leitura do codigo mais rapida

[@Unknown-868]

Aaahhh, entendi... Você faz tipo isso aqui, né: // Imprime a Nota Fiscal ImprimeNotaFiscal(nota); 😂

[@lhamaalada4302]

@@Unknown-868 exatamente

[@miguellopes9177]

Eu até concordo em partes mas quando penso melhor... Não ia conseguir nem entender como funciona um método do scanner

[@Unknown-868]

Não entendi. 🤔

[@miguellopes9177]

@@Unknown-868 O Scanner é comentado classe do java

[@Unknown-868]

@@miguellopes9177 Ata, entendi agora. Mas aí é a documentação do método, conforme a gente conversou no outro comentário, aí sim é algo bem vindo!

[@nicksonjeanmerson7412]

eu discordo disso no livro, trabalho com ts a anos e uso comentários e annotations pra gerar o swagger a partir das rotas, na empresa que trabalho criamos um processo em que além de fazer os testes unitários com 100% de cobertura, sempre matemos o swagger atualizado que pode servir inclusive para parceiros realizarem testes e homologações em um ambiente de sandbox ou também podem ser importado no postman, lembrando que o q está no livro, não precisa ser interpretado como verdade absoluta e nem está escrito em ferro e fogo.

[@Unknown-868]

O livro não é contra documentação, nesse caso aí os comentários são bem vindos. O problema é quando o programador utiliza comentários para explicar o fluxo de alguma rotina, daí o código deixa de ser pensado como OO e passa a ter uma interpretação procedural.

[@marcosrj21]

Para o trabalho: pergunte ao seu chefe o que ele pensa sobre comentários e siga o que ele falar. Para uso pessoal: use o que funciona para você. Para entrevistas: saiba explicar porque você escolheu a sua forma de usar comentários.

[@beiraodoaloucura9295]

Comentar é OBRIGATÓRIO

[@eduardumedeiros]

Tem comentário para explicar código que, por questões de eficiência, não tem como ser intuitivo.

[@AndreCarneiro666]

Considerar que seu código é "auto explicativo" ignora o fato de que humanos interpretam coisas de formas distintas. Portanto, é "desumano" não comentar o código! Assumir que você fez um código bom para todo mundo é puro narcisismo. Sempre assuma que seu código pode estar bom mas que outra pessoa pode discordar de você. Deste modo você aumenta as chances de alguém entender seu código de fato!

[@JoaoSouza04]

Tive uma reunião ontem com o instrutor de um bootcamp que participo e ele falou exatamante sobre isso, disse que se estou comentando algo quer dizer que meu código não está claro o suficiente kkkkkkkkkkkkkkkkkkkkk

[@marciorjusto]

Coloca ele pra dar manutenção em um sistema legado com 500 arquivos de fontes ... Mas é pra ontem, cliente no telefone que disse, kkk

[@L0RD.X]

Eu não trabalho com programação, faço por hobbie, mas comento coisas que caberíam no "informativo" tipo /* não medasapoha pq assim funciona */ mas de uma forma mais formal como /* da forma tal, tal e tal, da ruim, então mantenha como ta ou arrume uma solução melhor*/ .... tem um amigo meu q não manja nada sobre essas coisas de organizar, pra ele se roda ta bom, digamos que comento como se fosse pra ele entender já q meu git ta cheio de coisa inútil, meu titulo é "Reinventor da Roda"

[@cmsouzaac]

Muito util

[@gabrielcanciocosta4598]

Refactoring para o próximo!!

[@wesleyvilasboas5058]

Eu comento tudo. E organizo os códigos.

[@arleygoleiro22]

8:04 - faço muito dentro do .htaccess

[@MaxHeroGamer]

Só descrevo código se eu tiver que fazer bruxaria por motivos de otimização.

[@miguellopes9177]

Eu ainda não vir até o final do vídeo então se eu falar algo errado falem aí. Mas na minha opinião Quando você vai desenvolver um programa ou software eu acho que tá certo um bom código não precisaria ser comentado, Agora se você tá fazendo uma API,classe, biblioteca sei lá, para algum outro programa ou pessoa usar eu acho necessário. Pensei nisso com base no java.

[@Unknown-868]

Mas aí você está falando de dockblock, documentação xml ou seja lá como queira chamar. Documentação é importante, mas o ponto abordado no vídeo é sobre programadores que comentam o que as classes e métodos estão fazendo. :)

[@miguellopes9177]

@@Unknown-868 javadocs Por isso eu falei baseado em Java pelo menos até onde eu sei é assim no Java.

[@Unknown-868]

@@miguellopes9177 Aí é algo bem vindo!

[@jeffao7324]

Faço comentários para ficar mais fácil a visualização da posição dos meus itens, por exemplo básico onde um Container é composto por um texto e uma imagem, eu coloco os comentários //Título da imagem e //Imagem Principal, isso seria uma má prática ?

[@Unknown-868]

Você diz no front end? Se sim, não considero uma má prática. Os próprios códigos de demonstração da Microsoft possuem comentários assim, para organizar tags, seções, componentes e tudo mais. O problema é quando levamos isso pra OOP, ou seja, quando usamos comentários nas nossas classes e métodos.

[@jeffao7324]

​@@Unknown-868 Sim no caso fazendo o front de um app em Flutter por exemplo, as vezes tem vários componentes, aí gosto de colocar um comentário para ficar mais fácil de ir até o local para fazer uma eventual manutenção.

[@Unknown-868]

@@jeffao7324 Normal, acho até legal. A própria Microsoft faz isso nas páginas dela! =) O problema relatado no vídeo é quando alguém faz isso dentro do código comercial, quando alguém inclui comentários para explicar o que as classes e métodos estão fazendo.

[@that_80s_guy]

Como ainda sou aprendiz, eu comento muito. Até mesmo porque algumas vezes nem mesmo eu entendo o que eu codifiquei, ou o que faz. Portanto, eu ainda sou um comentador profissional! kkkk

[@marciorjusto]

Aproveite para ler o livro Código Limpo que o canal sugeriu. Com o tempo vc assimila - e quem sabe até automatiza - as boas práticas

[@_leandro_zz]

Eu tenho um vicio muito grande de comentar oque vou fazer em um determinado bloco de código kkkk como quando, por exemplo, vou validar um campo: # validando tal campo ... Não necessariamente por achar meu código ruim, mas acho que facilita quando o código esta muito grande e tenho que voltar para verificar oque eu fiz, eu só leio o comentário ao invés de precisar ler todo o bloco de código kkkk

[@Unknown-868]

Tem um problema de design na sua aplicação. Validação deve ficar em uma camada separada, você está misturando regra comercial com código que não deve.

[@edvaned8207]

grande aula. Confesso que cometia alguns dos erros e me sentia "fazendo a coisa certa". Corrigir para atingir a maturidade técnica é a meta de qualquer dev que deseja se tornar "SENIOR" (senior não somente na idade, é claro 😎!).

[@lucasg8455]

Quando é que vocês vão lá na Trybe pra um webinar?. Essa semana foi o CTO do Nubank e foi muito legal e produtivo.

[@kromodoro]

Li o livro, mas, sem usar ele como doutrina apenas como dicas. A decisão de adotar ou não ainda é minha.

[@eBrunoro]

A decisão de escrever um código limpo e bem escrito, ou não, é minha. Eu posso fazer um código mal feito de propósito se quiser 😇

[@kromodoro]

@@eBrunoro quem me dera fazer código ruim de propósito 😂