Cai de paraquedas no vídeo, entrei sem expectativas e recebi uma aula de lógica e simplificação dela, sem encheção de linguiça, direto ao ponto. Seu conteúdo eh excelente cara, uma das poucas pessoas que realmente ensinam algo de valor nessa rede.
@@matheus.tecchio Como você conseguiu o o acento no ó de lógica e no ú de conteúdo então? E o í de vídeo então? Se foi editando ainda falta um acento no í de "Cai", pois o correto é "Caí" nesse caso e o "eh" deveria ser "é"
@@MemorizadordeVerbos porque o próprio navegador corrige algumas palavras para mim, mas ele não é tão bom, então sai errado, qualquer idiota sabe disso, mas você deve ser o maior deles, aí não sabe. Quer uma foto do meu teclado, das configurações do meu navegador e da minha compra do mês também? Nem minha professora de português se preocupava tanto com ortografia na internet
Comecei a implementar o Look up table recentemente em um projeto e isso tem me ajudado muito. Antes eu estava me confundindo d++ com a quantidade de IFs/IF-ELSE que tinha, agora ta bemmm mais fácil de entender e arrumar o código caso necessário
Na parte do look up table, o problema apresentado pelo Google é mais complexo, não? Já que nem mesmo com switch seria possível resolver, já que os valores checados em cada condicional vem de origens diferentes.
No exemplo do Google, podemos utilizar o padrão Chain of Responsibility combinando-o com o Command Pattern. Para isso, criamos uma lista de objetos, onde cada um contém um método condition e outro execution. Em seguida, iteramos sobre os elementos dessa lista, executando o método condition. O primeiro objeto cujo condition retorne verdadeiro terá seu método execution invocado. Essa abordagem facilita tanto a adição de novos itens à cadeia quanto a alteração da ordem em que as condições são verificadas, tornando o sistema mais flexível e modular.
match é um superset de switch, faz muito mais que o switch simples pois é structural pattern matching, mt mais parecido com o que existe em linguagens funcionais; mas vc tá certo, seria aplicável aqui
Além das ideias de guard clause e lookup table também tem casos onde em linguagens OO da para usar certos design patterns como Factory, Strategy e State também. Em alguns casos em conjunto com essas técnicas para melhorar a legibilidade e facilitar a manutenção e evolução do código
trabalho com e existe uma keyword chamada match, é basicamente um switch também (tem diferenças sintática, mas no geral é a mesma coisa). Mas eu sempre, prefiro utilizar esse padrão que até então achava que se chamava de strategy, faz um apanhado com alguns patterns mais utilizados. Vlw, conteúdo true.
Valeu pelo vídeo! Ao meu ver, no exemplo da Google, uma vez que cada condicional checa um atributo diferente da instância, a solução do lookup table não é aplicável. Nesse caso, pra mim o "switch" (que na verdade "existe" para Python >= 3.10 com o nome de match [Structural Pattern Matching], que pode ser visto como um switch com esteroides) é a solução mais simples e direta. Um ponto em relação a solução da Google é que o elif do CPython não tem otimização nenhuma é apenas syntax sugar que deixa o código mais limpo, mas sendo equivalente a if-else aninhados. Outra coisa é que eu tenho um pouco de receio em introduzir variáveis globais no código, mas como um dicionário é mutável o Python não consegue (não tenho certeza, já que no exemplo o dicionário não sobre alterações) otimizar o valor da variável local e teria que recriar ele toda vez que a função é chamada...
@@leonardodias3393 Não sei dizer, cara. Teria que ver o código fonte do CPython. Como o match-case do Python tem bastante funcionalidades, deve ser algo bem complexo. Como é built-in no Python, com certeza o core é todo em C.
Muito bom, podemos incluir nessa questão, que geralmente os else's tratam de cenários excepcionais, principalmente no ato da leitura do código, o simples fato de lermos "se isso acontecer faça X, SENÃO y", senão indica essa ideia de exceção, e um princípio muito conhecido e utilizado é o Fail-Fast, que no caso trata mais de exceções mesmo, mas podemos estender o conceito para esses cenários normais, onde temos o happy-path e os unhappy-paths, este se traduzindo aos casos excepcionais muitas vezes utilizados no else, usando um return early pra esses unhappy-paths se mostra muito mais legível e de fácil manutenção no longo prazo, sendo bem mais fácil identificar potenciais erros. Tem gente que reclama de early return por adicionar mais returns e que isso seria um anti-pattern, dizendo que as funções/métodos só devem ter um return, mas sinceramente isso não é bem verdade, particularmente eu resumo no entendimento que o happy-path tem que ter um return só (return dentro switch dá pra considerar como 1 return só tbm), ou pelo menos returns próximos um do outro como no exemplo no vídeo, mas cada unhappy-path pode usar o return early naturalmente, pois torna a leitura do código mais simples sem adicionar complexidade.
Concordo 100%, inclusive uma das coisas que eu mais detesto em não poder usar error como valor em algumas linguagens é como fica distante o catch das execuções que deram erro dentro do try. As proposta de linguagens como rust e principalmente golang, que é visto como verborrágico, são muito mais fáceis de entender na minha visão.
Dependendo da linguagem é melhor você usar as cláusulas de guarda (guard clauses) se for possível, senão alguns casos você precisa usar o switch porque as condicionais nem sempre vão ser relacionais. Quando você tem uma condicional simples de duas condições, ás vezes três, pode usar o else, else if tranquilo porque o ganho em performance e segurança vão ser mínimos ou nulos.
Vídeo muito bom. Eu geralmente sou do grupo antielse kkkkk, mas reconheço que em alguns casos são necessários. E acho que vale adicionar como exemplo os casos de quando não necessariamente há um return/throw no if-else. Se há um bloco de código abaixo continuando a função por exemplo, faz sentido usar o if-else
A função size é mais simples de entender porem em performace ele pode ser pior, se a tendencia dos numeros a entrarem no codigo forem abaixo de 100 o codigo vai ter que passar por TODOS os ifs em todas as vezes. Já se a tendencia for que numeros altos cheguem acontece o contrario. Nem sempre codigo "limpo" é melhor que codigo "sujo"
A diferença é irrisória pq uma instrução de comparação leva apenas 1 ciclo de máquina O código menor pode entretanto ajudar o branch prediction a carregar as instruções no cache pq tá tudo próximo e na prática ser mais rápido que um monte de if-else, pq esses aninhamentos de estrutura vão basicamente desativar o uso de execução especulativa (pq não tem como prever de forma concisa para onde o código vai executar, sem executar)
@@AlexeiDimitri Daí depende muito de que processador estamos falando. Se for embarcado (que é onde isso mais faz diferença) uma comparação pode levar até 10 ciclos ou até mais se duvidar.
@@ZantsuRocks Mesmo que seja a diferença de performance é irrisória frente ao esforço necessário para dar manutenção num software com muitas linhas de código e pouca estruturação.
@@AlexeiDimitri Nunca, se algum dia tu programar pra embarcado tu vão ver, qualquer ciclo de processamento importa, qualquer 1 byte de memória importa. O programador que faz software pra embarcado e sai aplicando cleancode em tudo é um péssimo programador.
Sabe aqueles de codificador de TV LENTO de TV a cabo, 100% de certeza que tá cheio de cleancode. Sabe aquele que flui lindamente? 0 cleancode. Sabe aquele teu aparelho IoT que trava.... Cleancode. Sabe aquele que nunca nem perdeu conexão? 0 cleancode. O mundo dos embarcados não suporta código não performatico.
Lookup Table é um pattern que eu conhecia como Observer Pattern em Javascript, funciona exatamente dessa maneira a logica! Utilizar um objeto no lugar de varios IFs facilita muito na hora de adicionar remover ou editar regras...
O video foi muito bom, mas entendo que se for pra colocar 3 if's na msm identaçao, seria melhor fazer uso do elif (no python). Pq com 3 if's, msm que o 1o if seja vdd, os outros serao consultados, o q nao ocorre com o elif
Acredito que essa discussão do ELSE seja bem relativa e engloba muito mais do que é boilerplate ou não, pois a visão de utilidade do mesmo varia de acordo com o paradigma utilizado. Porque ora, se nos paradigmas mais imperativos e funcionais, onde há maior ramificação no comportamento e comandos extensos, o else se torna uma escolha viável. Agora qnd paramos pra pensar na orientação a objetos e nos princípios do S.O.L.I.D, cara, se a sua função contém vários IFs aninhados e validações, com certeza a sua classe precisa ser refatorada.
Com certeza! se a tua classe contém um conjunto de if's e validações é hora de pensar em responsabilidades e tratamento de erros! Eu não preciso lidar se um argumento de parâmetro está correto ou não! quem resolver acessar minha interface esteja ciente do contrato! "A minha classe precisa lidar com isso?", "A responsabilidade é de quem me chamou?", é bom pensar sempre em classes mais atômicas e com semântica mais assertiva.
Concordo com todos os pontos destacados no vídeo, só com uma ressalva: Existem sim casos em que usar else é de certa forma obrigatória porque não é possível retornar diretamente os valores. Casos onde você está fazendo uma construção parcial de um objeto ou instância, por exemplo. function criarCarro() { const carro = new Carro(); if(algumaCondição) { carro.cor = "Vermelho" } else { carro.cor = "Azul" } if(outraCondição){ carro.cambio = "Automático" } else { carro.cambio = "Manual" } return carro; } É claro que dá pra criar outras funções para cada caso e dentro delas usar early return como um getCambio() ou getCor(), mas em alguns casos pode fazer mais sentido deixar a lógica direto na função. Além disso usar else não é um "pecado", existem formas mais eficazes, muitas vezes, de escrever um código limpo que não usam ele sim, porém se não tornar a leitura complexa e não tiver muitos aninhamentos não há problema nenhum em usar esse recurso da linguagem. Acho, como você disse, este tipo de discussão boba e também é um baita exagero dizer que usar else em si é um anti-pattern. O importante é que a leitura do código seja simples e objetiva com uma descrição clara do que está sendo feito. E isso independe se você vai ou não usar else
2:57 Isso também depende da linguagem (e do paradigma). Algumas linguagens que se escoram em meta-programação torna praticamente impossível evitar if-if-if, já que não há como garantir as propriedades de "alguma coisa" fora do if.
muito bom, pelo que entendi, nao é que o uso do else seja ruim, mas a quantidade exagerada de ifs e elses que dificulta de forma exponencial a leitura e manutenção do código.
Pra mim, o problema do início do vídeo foi uma surpresa, pq quando comecei a programar isso de fato me incomodava, aí eu comecei a fazer funções pra quase tudo no código e esqueci que isso ocorria. Depois de um tempo aprendi a modularização e ficou ainda mais fácil de ler o código mesmo que ele tenha vários if's e else's. Ainda vou terminar o vídeo, mas foi um pensamento que me ocorreu.
eu vi um vídeo de um gringo era sobre fazer um código pra checar se um número é par ou impar mas usando tipo uns 2.000.000 de ifs algo assim. era um vídeo zoeira
Massa pra caramba essa dica da lookup table, não conhecia. Eu to começando no python (programo muito em VBA), já conhecia esse método da inversão, mas não sabia que dava pra usar um dicionário assim no python O que eu mais curto no jeito que vc faz o video é que explica o porque de usar tal método. Não é só um "ah não usa metodo x, faz o metodo y", e sim "no caso x, você pode usar o metodo a, b, c"
Em um método void, click do botão, melhor uso do else, se o metodo tem retorno, ok coloca o retorno no final, se não entrar nos ifs acima, o else entra no final
Sendo bem sincero, eu não tinha pensado por este lado ao não utilizar "else", mas geralmente utilizo esta abordagem que você explicou como solução. Interessante.
Único problema a ser encontrado caso use IF-ELSE e outros que dão saltos na linha de execução do código. Se resume a você fazer branches ou jumps, que podem afetar desempenho. Vai depender do compilador e políticas usadas para tratar. Em linguagem C, vejo que o melhor caso (depender da situação) é fazer um módulo fora da main.
Raras vezes discuti sobre o else usando a questão de complexidade ciclomática (acho que na verdade essa discussão só é válida apenas no campo de nesting das estruturas), a primeira vez que vi esse tipo de argumento achei bem fraco, o máximo que aprendemos é early return (e dentro disso chegar em lookup tables), mas se formos um pouco mais fundo, chegares numa discussão entre "happy path" e "unhappy path", é muito mais interessante trazer o caso de exceção (else) para cima (usando um if not, por ex) do que mantendo lá em baixo
De acordo. Apesar de ser dev a 3 anos me considero ainda bem inexperiente, principalmente com patterns. Mas é uma tendência natural que vejo na evolução de um programador, que é tratar a lógica de forma contrária, ou seja, o que não pode acontecer primeiro, e se a função não retornou nada ainda, subentende-se que o fluxo da operação seguirá conforme esperado.
Tem um outro ponto que esses dias tava conversando com minha equipe, que muitas vezes o pessoal usa o else como se toda a condição contrária do if devesse executar aquele código, quando na verdade é apenas uma outra condição específica que, caso não aconteça a primeira, deve ser executada. Com isso a condicional fica "escondida" (implícita) e não deixa claro quando a execução deve entrar naquela parte do código. Nesses casos vale extrait em um outro if e até mesmo aplicar o elif como foi falado no vídeo, pois assim deixa-se explícito essa segunda condicional.
tem horas q é difícil fugir dele, mas onde dá pra usar early-return melhora bastante no quesito de profundidade (nesting), pra gente nn ter coisas como: if() if() if() if() if() else else else else else Parece até uma pirâmide kkkkkkkkkkkkk.
Esse tipo de função costuma aparecer em códigos com devs menos experientes. É muito comum que as validações sejam de uma variável apenas, por exemplo. Com isso, tem-se muito mais paradas de verificação (que embora sejam muito rápidas hoje em dia), o que eu particularmente prefiro evitar. Muitas vezes é possível trazer toda a informação que se quer validar, e com apenas um ou dois ifs, já validar tudo.
discordo somente do caso do else enuances (6:31). Não seria um switch porque a condicional não é a mesma. Então entendo que o uso do elif estaria correta no exemplo apresentado do lado esquerdo do quadro.
De uns tempos pra cá eu percebi que tinha abandonado o else em favor do if return mas ainda uso o elif quando quero reforçar uma exceção à condição anterior. O dicionário de constantes também é uma ótima dica mas eu ainda não descarto o switch! 😅
Meu Deus, tô estudando pra um dia conseguir ser dev e caí aqui, que isso? Hahaha mas do mesmo jeito me inscrevi no canal mt bom o conteúdo, fico perdido nos else e nos for, forEach por aí vai 😱
qnd se tem apenas 3 ifs aninhados ta trql, agora pega um código que algum lazarento fez e por algum karalhos de motivo meteu uma função de 400 linhas e dentro dessa função tem pelomenos 20 if aninhados..... Isso sim é tristeza asodkasodkaosdkasd
Mas ai tem a galera anti-switch também... ja trabalhei num lugar onde uma feature de negocio foi negada de ser feita porque so dava pra ser feita com switch e o líder era "anti-switch".
A discução é interessante, mas é temporal. Houve um momento do desenvolvimento de software em que a grade polêmica é se uma função poderia ter mais de um ponto de retorno. A ideia da vez é que adicionar mais pontos de retorno dificultava aa manutenibilidade do software. No seu código de "bom exemplo" você colocou 4 returns e provavelmente ninguém irá apontar isso como um problema. As discussões de padrões são temporais. Embora não deixem de ser interessantes
O grande ponto de discordância não acaba sendo o else em si, mas o efeito colateral do seu uso, aí entramos mais em estrutura de algoritmo mesmo. Se levarmos a discussão pra linguagens funcionais ela morre, é impossível não ter else quando se lida puramente con expressões.
Falei esses dias com um júnior da equipe. Normalmente eu olho o código e tento simplificar a lógica pra não ter tipos de casos de if/else e else if várias vezes Sabendo separar bem como foi feito no vídeo de pensar o reverso da ideia ou de outra maneira. Senão uso um switch pra casos com mais se 3 tipos de estados Uso pouco else, mais um if com retorno do método acho que fica fácil de entender
Meu deus eu tava com esse problema ( trocentos elses) com as mesmas condiçoes malucas (range de números) e meu deus agora meu código tem tipo 20 linhas a menos. Obrigada
Instintivamente parei de usar else. Achei q era só comigo, mas pelo jeito mais pessoas pensam assim. Particularmente gosto de usar elif mesmo com return. Pra ajudar a dizer que todas condições são sobre o mesmo problema.
A utilização de blocos tem a ver com conclusões de ideias lógicas. Se seu objetivo referente à uma variável é modificar seu valor naquele bloco, então é elegante usar if/elif/else para o objetivo, ou até mesmo um match/case. Quando se utiliza diversos blocos if únicos, passa um ideia amadora de lógicas dispersas que não se interligam. Todo bloco tem uma finalidade.
Ia comentar sobre o match (ou switch como falou) mas vários colegas já comentaram No mais, gosto e uso bastante o que chamou de lookup table. Sempre pensei e chamei isso de mapeamento de dados (de para)
6:48 eu uso else exatamente pra isso. O uso dele pra mim é só pra facilitar mais ainda a legibilidade, mas não uso a real funcionalidade dele. Tem certos casos q usar switch eh até válido, mas ficaria melhor usar uma cadeia de if else, tipo para verificar várias variáveis diferentes
Na minha opinião esle é bom quando é só um, Tipo código pra game, uma porta está trancada, se o player tem a chave abre, senão manda a mensagem porta está trancada Eu posso até copiar e colar esse código em todas as portas e só trocar qual chave cada porta ou grupo de portas usa em caso dos keycards do doom
só uma coisa, quando vc tava lendo o artigo e disse q o if elif, poderia ser substituído por um switch, na verdade ele n poderia, pois justamente a diferença do switch é q ele n executa na sequencia de cima pra baixo, então no exemplo do artigo, se por exemplo o usuario não estivesse logado e estivesse no modo incógnito ao mesmo tempo, viraria uma condição de corrida.
Em várias linguagens como o próprio C, vc tem a opção de usar um BREAK ao final do tratamento de cada uma das cláusulas, pq vc pode querer fazer justamente isso de continuar checando por outras condições Em outras o break é implícito e não dá para usar esse tipo de fluxo.
Eu não acho uma discussão técnica boba, legibilidade pra mim é uma das coisas mais importantes no meu código, eu quero bater o olho e saber o que tá acontecendo, você ganha muito tempo, não precisa ficar com 5 condições na cabeça pra ler o miolo do código, e a manutenção como foi dito no vídeo é muito mais fácil. Um outro benefício é que você pode espremer a janela do código muito mais, já que cada if dentro de if é um espaço da tela que é perdido.
O uso ou não de "else" pode não fazer muito sentido em muitas aplicações atualmente. Principalmente se o foco for acadêmico em relação à utilização de técnicas ou como exemplificado muito bem por você Augusto, no sentido de ter maior clareza no entendimento do processo. Mas os devs devem sempre avaliar se a sua criação necessita ser eficiente ou eficaz. Explicando melhor, o resultado que os devs precisam sofrerão evolução constante ou planejadas e neste caso, a redução da complexidade é muito bem vinda, ou devido ao volume de dados ou necessidade de comunicação que tenha alguma limitação, a aplicação precisa de performance ( existe um custo de máquina que pode ser relevante para alguma aplicação). Não é recomendado abandonar esta ou aquela técnica, mas entender o melhor momento de aplicar todo o nosso arsenal de informações ou situações nos momentos certos.
6:03, o problema é que "você" tem que recalcular uma variável após a outra, no final de um código estruturado dessa forma, você vai ter um consumo de memória e processamento muito maior. Imagina ter que recalcular o valor 500 vezes, você perde tempo e processamento. Se você faz um "x => 5" ele pode retornar um valor, sim ou não, correto? Nesse caso essa situação, do minuto 6:03, pode até ser válida, mas imagina, uma seqüência de calculos, para resolver uma coisa. O Else-IF já faz o calculo, intrinsicamente , para todos os Ifs, Elses e Elses-Ifs. Por isso a programação está indo de mal à pior, o povo nem sabe o que está escrevendo.
Não sabia que python não tinha switch. Uso c# e se so tem 2 caminhos (if/else) uso ele, mas se tem 3 caminhos ou mais, ai eu uso switch, é mais rápido porque o compilador não precisa verificar cada if pra saber se é verdade, vai direto ao ponto. Lembro da primeira aula de Switch do Guanabara que assisti, ele usando um desenho na lousa desenhando as ruas simbolizando cada variação (if dobrar pra direita chega na padaria?) kkkkkk o cara é mestre em explicar para quem ta no absoluto zero.
Acho que o maior problema em usar else, nao seja usar else, seja logica que se aplica quando se usa else, porque quando se programa desse jeito o seu programa/funcao acaba tendo muitas regras contida em outras regras, deixando o codigo dificil de ler e dificultando tambem os testes e a legibilidade dos testes . So pra constar que a funcao size poderia ser escrita como size = lambda value: int(math.log(value, 10)) e o user_roles.get deveria ter o default 'Unknown User' .
Cara o else é muito útil quando tu precisa fazer uma validação simples e depois rodar alguma coisa depois, tipo ler os dados de um usuário e depois montar uma resposta baseado nessa info. Se os dados que vou retornar são idênticas, tirando os dados do usuário que virão ou não, o else se encaixa bem. Pq o Early return vai te obrigar a fazer todas as outras tarefas antes de validar o usuário e dar um append das informações do usuário lá no final. Eu prefiro deixar o if sempre no topo do código nesse caso pq logo de cara eu sei que tem dados de usuário sendo tratados ali
Sou totalmente leigo em programação, tô começando com c++ e cai por aqui de paraquedas kkkkkk bom vídeo apesar de eu não ter entendido nada kkkk Edit: Não pretendendo trabalhar com programação, só que eu sempre gostei de programação e hacking, mas tinha muita preguiça de ir atrás pra aprender, então acabei criando vergonha na cara depois de 6 anos e decidi aprender algo kkkk quero aprender só por hobby, quero acordar algum dia e falar "não tenho nada pra fazer, vou codar"
Existem 3 tipos de programadores: 1° Os que fizeram prog 2 2° Os que preferem aeds. 3º Os que preferem engenharia de software. Em tese, else diminui o custo de execução do código. Quem estudou assembly, por exemplo, faz prioridade de comparação, ou seja, o que vai ser mais acessado primeiro. Então se tu sabe que 1 if será executado 50% das vezes, outros 30%, o outro 20%, fica nessa ordem. Logo, imagine que você tem 30 if's em sequência. Com else se primeiro corresponder ele não vai executar os outros 29 if's (se não tiver um return dentro dela), já se não tiver, mesmo que o primeiro seja o certo vai executar 30 vezes. Agora, dentro de usa função, onde todo if tem return, não tem porque else. A Google usou um péssimo exemplo. Para quem usa linguagens focadas em eficiência de execução else é bem útil, já quem programa em Python, eficiência não é nem levada em conta, else dispensável. Eu programo c/c++, vou mais para eficiência que legibilidade ou patterns. Por mais que eu use uma versão de um, que quebra tudo em pequenas funções, com o inline, o custo não muda muito.
EXATO! Sou engenheiro e desde o técnico em eletrônica compilando um Z80 no braço, sempre penso no tempo de máquina que vou ficar em cada scan e mesmo em python acabo mantendo essa mentalidade.
Impressionante, sempre usei esse approach diferente nos meus códigos e só uso o ELSE quando não tenho outra saída. Mas descobri agora que tem toda uma discussão sobre disso hahahaha
Não sou programador profissional, mas acho o else muito mais claro. Não só no exemplo do google, mas em todos que eu me lembre. Quando você usa o return pra indicar que o que vem depois não será executado me parece uma espécie de "goto", pois eu tenho que entender um fluxo que não é tão natural, justamente por remover dependências dos blocos... O else e else if deixam claro o fluxo para mim.
Piazada seguinte, else é quando o input recebido nao pode ser lidado pelo seu codigo, por exemplo ali no ultimo exemplo dele, ele ainda precisaria retornar algo se o user nao existisse no object, um if/else reolveria.(se usar early return um simples if resolve eu sei, mas nao fica tao legivel)
Cai de paraquedas no vídeo, entrei sem expectativas e recebi uma aula de lógica e simplificação dela, sem encheção de linguiça, direto ao ponto. Seu conteúdo eh excelente cara, uma das poucas pessoas que realmente ensinam algo de valor nessa rede.
Igualmente. Aulas!
RIP Português. Espero ressuscitá-lo com meu app.
@@MemorizadordeVerbos meu teclado é inglês internacional, não tem acento... Agora tô com acento pq to no celular
@@matheus.tecchio Como você conseguiu o o acento no ó de lógica e no ú de conteúdo então? E o í de vídeo então? Se foi editando ainda falta um acento no í de "Cai", pois o correto é "Caí" nesse caso e o "eh" deveria ser "é"
@@MemorizadordeVerbos porque o próprio navegador corrige algumas palavras para mim, mas ele não é tão bom, então sai errado, qualquer idiota sabe disso, mas você deve ser o maior deles, aí não sabe. Quer uma foto do meu teclado, das configurações do meu navegador e da minha compra do mês também? Nem minha professora de português se preocupava tanto com ortografia na internet
2:57 "raramente no mundo real vc vai ver codigo assim". Eu vendo todo dia kkkkkkk
SIM 🤣
Onde é que vcs tão trabalhando? 😮 ver isso é bizarro kkk
Acho que ele quis dizer sobre a lógica do código, não sobre a estrutura
Se eu vejo um desse já dou commit na main a resolução
Já vi código com
if (condição) {
...codigo
return valor;
} else {
outra logica...
}
return outro_valor;
Você não usa else porque é inteligente. Eu não uso else porque sou preguiçoso. Nós não somos iguais.
😂😂😂
E eu uso else pq nn sei como substituir ele kkkk
@@Plikso Ta com preguiça de aprender, logo, é preguiçoso kk (sendo que é bem fácil)
Tipo de conteúdo que sinto muita falta, merece mais alcance
como assim sente falta? o Augusto faz video direto
@@alandavidlima Falei no youtube em geral
Que video bom, cara... Didático, direto ao ponto e muito explicativo. Esse cara merece muita relevância pelo conteúdo que faz.
O conteúdo que você entrega é de muito valor.
Comecei a implementar o Look up table recentemente em um projeto e isso tem me ajudado muito. Antes eu estava me confundindo d++ com a quantidade de IFs/IF-ELSE que tinha, agora ta bemmm mais fácil de entender e arrumar o código caso necessário
Na parte do look up table, o problema apresentado pelo Google é mais complexo, não? Já que nem mesmo com switch seria possível resolver, já que os valores checados em cada condicional vem de origens diferentes.
exatamente, não fez sentido o exemplo com hashtable
verdade
No exemplo do Google, podemos utilizar o padrão Chain of Responsibility combinando-o com o Command Pattern. Para isso, criamos uma lista de objetos, onde cada um contém um método condition e outro execution. Em seguida, iteramos sobre os elementos dessa lista, executando o método condition. O primeiro objeto cujo condition retorne verdadeiro terá seu método execution invocado. Essa abordagem facilita tanto a adição de novos itens à cadeia quanto a alteração da ordem em que as condições são verificadas, tornando o sistema mais flexível e modular.
Eu acho o seu canal simplesmente fenomenal!! Linguagem totalmente didática e muito inteligente.
Caramba, esses vídeos são muito bons. Sou iniciante em programação e ajuda bastante esse tipo de discussão.
Excelente! Obrigado pelo conteúdo, não sou um programador experiente e é um privilégio ter acesso a um material como esse.
A partir do python 3.10, a lógica do switch case foi implementada, mas sendo a palavra match no lugar da palavra switch
match é um superset de switch, faz muito mais que o switch simples pois é structural pattern matching, mt mais parecido com o que existe em linguagens funcionais; mas vc tá certo, seria aplicável aqui
só que o switch só verifica igualdades, oq não resolve a maioria dos casos.
@@ErlisonSantos-wg3we do que vc está falando? Como falado, o switch não existe em Python.
@@higorhi72Ele tá respondendo o primeiro comentário doidão kkkkk
@@O_Martelo_de_Nietzsche kkkkkkkkk msm assim ficou estranho
Python introduziu o "match" na versão 3.10 no final de 2021.
mas nem sempre é python
Esse canal vai ser gigante! Merece muito, parabéns e obrigado pelo conteúdo!
Além das ideias de guard clause e lookup table também tem casos onde em linguagens OO da para usar certos design patterns como Factory, Strategy e State também. Em alguns casos em conjunto com essas técnicas para melhorar a legibilidade e facilitar a manutenção e evolução do código
trabalho com e existe uma keyword chamada match, é basicamente um switch também (tem diferenças sintática, mas no geral é a mesma coisa).
Mas eu sempre, prefiro utilizar esse padrão que até então achava que se chamava de strategy, faz um apanhado com alguns patterns mais utilizados.
Vlw, conteúdo true.
Cara que didática profissional e direta você tem, justamente o quê eu estava precisando. Pela primeira vez, obrigado algoritmo do UA-cam.
Valeu!
@@TheR7HD brigadão 🫶
Valeu pelo vídeo!
Ao meu ver, no exemplo da Google, uma vez que cada condicional checa um atributo diferente da instância, a solução do lookup table não é aplicável. Nesse caso, pra mim o "switch" (que na verdade "existe" para Python >= 3.10 com o nome de match [Structural Pattern Matching], que pode ser visto como um switch com esteroides) é a solução mais simples e direta. Um ponto em relação a solução da Google é que o elif do CPython não tem otimização nenhuma é apenas syntax sugar que deixa o código mais limpo, mas sendo equivalente a if-else aninhados.
Outra coisa é que eu tenho um pouco de receio em introduzir variáveis globais no código, mas como um dicionário é mutável o Python não consegue (não tenho certeza, já que no exemplo o dicionário não sobre alterações) otimizar o valor da variável local e teria que recriar ele toda vez que a função é chamada...
Como eh implementado esse match do python? Tem alguma relacao com a implemenacao de switch a nvl de codigo de maquina a partir de jump table?
@@leonardodias3393 Não sei dizer, cara. Teria que ver o código fonte do CPython. Como o match-case do Python tem bastante funcionalidades, deve ser algo bem complexo. Como é built-in no Python, com certeza o core é todo em C.
Muito bom, podemos incluir nessa questão, que geralmente os else's tratam de cenários excepcionais, principalmente no ato da leitura do código, o simples fato de lermos "se isso acontecer faça X, SENÃO y", senão indica essa ideia de exceção, e um princípio muito conhecido e utilizado é o Fail-Fast, que no caso trata mais de exceções mesmo, mas podemos estender o conceito para esses cenários normais, onde temos o happy-path e os unhappy-paths, este se traduzindo aos casos excepcionais muitas vezes utilizados no else, usando um return early pra esses unhappy-paths se mostra muito mais legível e de fácil manutenção no longo prazo, sendo bem mais fácil identificar potenciais erros.
Tem gente que reclama de early return por adicionar mais returns e que isso seria um anti-pattern, dizendo que as funções/métodos só devem ter um return, mas sinceramente isso não é bem verdade, particularmente eu resumo no entendimento que o happy-path tem que ter um return só (return dentro switch dá pra considerar como 1 return só tbm), ou pelo menos returns próximos um do outro como no exemplo no vídeo, mas cada unhappy-path pode usar o return early naturalmente, pois torna a leitura do código mais simples sem adicionar complexidade.
Concordo 100%, inclusive uma das coisas que eu mais detesto em não poder usar error como valor em algumas linguagens é como fica distante o catch das execuções que deram erro dentro do try. As proposta de linguagens como rust e principalmente golang, que é visto como verborrágico, são muito mais fáceis de entender na minha visão.
Parabéns pela didática, rapaz!! Explicação fenomental!
Cara, seu conteudo é simplesmente incrível, sério, já virei seu fã #1
ficou mt bom esses cortes ( eu gostei ao menos )
fera da bola!
Dependendo da linguagem é melhor você usar as cláusulas de guarda (guard clauses) se for possível, senão alguns casos você precisa usar o switch porque as condicionais nem sempre vão ser relacionais. Quando você tem uma condicional simples de duas condições, ás vezes três, pode usar o else, else if tranquilo porque o ganho em performance e segurança vão ser mínimos ou nulos.
Vídeo muito bom. Eu geralmente sou do grupo antielse kkkkk, mas reconheço que em alguns casos são necessários. E acho que vale adicionar como exemplo os casos de quando não necessariamente há um return/throw no if-else. Se há um bloco de código abaixo continuando a função por exemplo, faz sentido usar o if-else
A função size é mais simples de entender porem em performace ele pode ser pior, se a tendencia dos numeros a entrarem no codigo forem abaixo de 100 o codigo vai ter que passar por TODOS os ifs em todas as vezes.
Já se a tendencia for que numeros altos cheguem acontece o contrario.
Nem sempre codigo "limpo" é melhor que codigo "sujo"
A diferença é irrisória pq uma instrução de comparação leva apenas 1 ciclo de máquina
O código menor pode entretanto ajudar o branch prediction a carregar as instruções no cache pq tá tudo próximo e na prática ser mais rápido que um monte de if-else, pq esses aninhamentos de estrutura vão basicamente desativar o uso de execução especulativa (pq não tem como prever de forma concisa para onde o código vai executar, sem executar)
@@AlexeiDimitri Daí depende muito de que processador estamos falando.
Se for embarcado (que é onde isso mais faz diferença) uma comparação pode levar até 10 ciclos ou até mais se duvidar.
@@ZantsuRocks Mesmo que seja a diferença de performance é irrisória frente ao esforço necessário para dar manutenção num software com muitas linhas de código e pouca estruturação.
@@AlexeiDimitri Nunca, se algum dia tu programar pra embarcado tu vão ver, qualquer ciclo de processamento importa, qualquer 1 byte de memória importa.
O programador que faz software pra embarcado e sai aplicando cleancode em tudo é um péssimo programador.
Sabe aqueles de codificador de TV LENTO de TV a cabo, 100% de certeza que tá cheio de cleancode.
Sabe aquele que flui lindamente? 0 cleancode.
Sabe aquele teu aparelho IoT que trava.... Cleancode.
Sabe aquele que nunca nem perdeu conexão? 0 cleancode.
O mundo dos embarcados não suporta código não performatico.
Lookup Table é um pattern que eu conhecia como Observer Pattern em Javascript, funciona exatamente dessa maneira a logica! Utilizar um objeto no lugar de varios IFs facilita muito na hora de adicionar remover ou editar regras...
O video foi muito bom, mas entendo que se for pra colocar 3 if's na msm identaçao, seria melhor fazer uso do elif (no python).
Pq com 3 if's, msm que o 1o if seja vdd, os outros serao consultados, o q nao ocorre com o elif
Parabéns pelo trabalho, sem enrolação e com muito conteúdo. +1 inscrito
Acredito que essa discussão do ELSE seja bem relativa e engloba muito mais do que é boilerplate ou não, pois a visão de utilidade do mesmo varia de acordo com o paradigma utilizado. Porque ora, se nos paradigmas mais imperativos e funcionais, onde há maior ramificação no comportamento e comandos extensos, o else se torna uma escolha viável. Agora qnd paramos pra pensar na orientação a objetos e nos princípios do S.O.L.I.D, cara, se a sua função contém vários IFs aninhados e validações, com certeza a sua classe precisa ser refatorada.
Sem contar com outras praticas e libs que evitam esse tipo de código
@@50113392 fato
Com certeza! se a tua classe contém um conjunto de if's e validações é hora de pensar em responsabilidades e tratamento de erros! Eu não preciso lidar se um argumento de parâmetro está correto ou não! quem resolver acessar minha interface esteja ciente do contrato! "A minha classe precisa lidar com isso?", "A responsabilidade é de quem me chamou?", é bom pensar sempre em classes mais atômicas e com semântica mais assertiva.
Mais um video que surpreende além das expectativas. Parabéns.
Parabéns, analiso código a todo momento e vejo que o pessoal não compreende muito sobre complexidade ciclomatica. Seu conteúdo é toop.
Augusto seus videos são muito bons, me ajudam muito em meus estudos é um conteudo explicado de maneira simples e direto ao ponto .
Concordo com todos os pontos destacados no vídeo, só com uma ressalva: Existem sim casos em que usar else é de certa forma obrigatória porque não é possível retornar diretamente os valores. Casos onde você está fazendo uma construção parcial de um objeto ou instância, por exemplo.
function criarCarro() {
const carro = new Carro();
if(algumaCondição) {
carro.cor = "Vermelho"
}
else {
carro.cor = "Azul"
}
if(outraCondição){
carro.cambio = "Automático"
}
else {
carro.cambio = "Manual"
}
return carro;
}
É claro que dá pra criar outras funções para cada caso e dentro delas usar early return como um getCambio() ou getCor(), mas em alguns casos pode fazer mais sentido deixar a lógica direto na função.
Além disso usar else não é um "pecado", existem formas mais eficazes, muitas vezes, de escrever um código limpo que não usam ele sim, porém se não tornar a leitura complexa e não tiver muitos aninhamentos não há problema nenhum em usar esse recurso da linguagem.
Acho, como você disse, este tipo de discussão boba e também é um baita exagero dizer que usar else em si é um anti-pattern. O importante é que a leitura do código seja simples e objetiva com uma descrição clara do que está sendo feito. E isso independe se você vai ou não usar else
No caso do exemplo da Google, os ifs estão sendo feitos em variaveis diferentes, logo nem switch nem map table funciona.
2:57 Isso também depende da linguagem (e do paradigma). Algumas linguagens que se escoram em meta-programação torna praticamente impossível evitar if-if-if, já que não há como garantir as propriedades de "alguma coisa" fora do if.
Gostei do conteudo, sou relativamente novo na programação e essess topicos vão me ajudar bastante
muito bom, pelo que entendi, nao é que o uso do else seja ruim, mas a quantidade exagerada de ifs e elses que dificulta de forma exponencial a leitura e manutenção do código.
Vídeo muito bom!! Só uma observação, o python a partir da da versão 3.10 tem switch case sim, match case na syntax dele.
Acabei te conhecer o canal, ótima recomendação do google. Vim sem expectativas e ganhei uma excelente aula
Pra mim, o problema do início do vídeo foi uma surpresa, pq quando comecei a programar isso de fato me incomodava, aí eu comecei a fazer funções pra quase tudo no código e esqueci que isso ocorria. Depois de um tempo aprendi a modularização e ficou ainda mais fácil de ler o código mesmo que ele tenha vários if's e else's.
Ainda vou terminar o vídeo, mas foi um pensamento que me ocorreu.
eu vi um vídeo de um gringo era sobre fazer um código pra checar se um número é par ou impar mas usando tipo uns 2.000.000 de ifs algo assim. era um vídeo zoeira
Massa pra caramba essa dica da lookup table, não conhecia. Eu to começando no python (programo muito em VBA), já conhecia esse método da inversão, mas não sabia que dava pra usar um dicionário assim no python
O que eu mais curto no jeito que vc faz o video é que explica o porque de usar tal método. Não é só um "ah não usa metodo x, faz o metodo y", e sim "no caso x, você pode usar o metodo a, b, c"
Em um método void, click do botão, melhor uso do else, se o metodo tem retorno, ok coloca o retorno no final, se não entrar nos ifs acima, o else entra no final
Sendo bem sincero, eu não tinha pensado por este lado ao não utilizar "else", mas geralmente utilizo esta abordagem que você explicou como solução. Interessante.
Único problema a ser encontrado caso use IF-ELSE e outros que dão saltos na linha de execução do código. Se resume a você fazer branches ou jumps, que podem afetar desempenho. Vai depender do compilador e políticas usadas para tratar.
Em linguagem C, vejo que o melhor caso (depender da situação) é fazer um módulo fora da main.
Raras vezes discuti sobre o else usando a questão de complexidade ciclomática (acho que na verdade essa discussão só é válida apenas no campo de nesting das estruturas), a primeira vez que vi esse tipo de argumento achei bem fraco, o máximo que aprendemos é early return (e dentro disso chegar em lookup tables), mas se formos um pouco mais fundo, chegares numa discussão entre "happy path" e "unhappy path", é muito mais interessante trazer o caso de exceção (else) para cima (usando um if not, por ex) do que mantendo lá em baixo
De acordo. Apesar de ser dev a 3 anos me considero ainda bem inexperiente, principalmente com patterns.
Mas é uma tendência natural que vejo na evolução de um programador, que é tratar a lógica de forma contrária, ou seja, o que não pode acontecer primeiro, e se a função não retornou nada ainda, subentende-se que o fluxo da operação seguirá conforme esperado.
@@imperiaonlinebrperfeita analogia.
Tem um outro ponto que esses dias tava conversando com minha equipe, que muitas vezes o pessoal usa o else como se toda a condição contrária do if devesse executar aquele código, quando na verdade é apenas uma outra condição específica que, caso não aconteça a primeira, deve ser executada. Com isso a condicional fica "escondida" (implícita) e não deixa claro quando a execução deve entrar naquela parte do código.
Nesses casos vale extrait em um outro if e até mesmo aplicar o elif como foi falado no vídeo, pois assim deixa-se explícito essa segunda condicional.
tem horas q é difícil fugir dele, mas onde dá pra usar early-return melhora bastante no quesito de profundidade (nesting), pra gente nn ter coisas como:
if()
if()
if()
if()
if()
else
else
else
else
else
Parece até uma pirâmide kkkkkkkkkkkkk.
Exatamente o que ele chamou de "código hadouken" kkkkkkkk
Esse tipo de função costuma aparecer em códigos com devs menos experientes. É muito comum que as validações sejam de uma variável apenas, por exemplo.
Com isso, tem-se muito mais paradas de verificação (que embora sejam muito rápidas hoje em dia), o que eu particularmente prefiro evitar.
Muitas vezes é possível trazer toda a informação que se quer validar, e com apenas um ou dois ifs, já validar tudo.
@@imperiaonlinebr exatamente! if((a ou b) e (y e x)) já diminui bastante a dor de cabeça.
discordo somente do caso do else enuances (6:31). Não seria um switch porque a condicional não é a mesma. Então entendo que o uso do elif estaria correta no exemplo apresentado do lado esquerdo do quadro.
De uns tempos pra cá eu percebi que tinha abandonado o else em favor do if return mas ainda uso o elif quando quero reforçar uma exceção à condição anterior. O dicionário de constantes também é uma ótima dica mas eu ainda não descarto o switch! 😅
hahahaaha excelente didática, bem melhor que tentando explicar no trabalho por que eu não uso else kkkk
A modelagem do "user_role" para um dicionário escancara a necessidade de estudarmos Estruturas de Dados. Conteúdo muito bom.
Meu Deus, tô estudando pra um dia conseguir ser dev e caí aqui, que isso? Hahaha mas do mesmo jeito me inscrevi no canal mt bom o conteúdo, fico perdido nos else e nos for, forEach por aí vai 😱
qnd se tem apenas 3 ifs aninhados ta trql, agora pega um código que algum lazarento fez e por algum karalhos de motivo meteu uma função de 400 linhas e dentro dessa função tem pelomenos 20 if aninhados..... Isso sim é tristeza asodkasodkaosdkasd
Anão aí pelo amor kkk 😂😂 ja peguei dessas
Isso pareceu um pouquinho pessoal kskskaka
@@semnome-cq5gi pq foi 🥲 foram 4 horas de puro estresse kkkkk xinguei até a 3° geração msm sem saber qm fez aqls atrocidade kkkksosisjsisks
@@ricardao069dê um git blame e descubra quem foi o infeliz
Isso foi tão específico, você está bem? Kkkkkk
O Python tem switch case só que com nome diferente, chamado de match case, desde a versão 3.10 em 2021
Mas ai tem a galera anti-switch também... ja trabalhei num lugar onde uma feature de negocio foi negada de ser feita porque so dava pra ser feita com switch e o líder era "anti-switch".
Gostei demais do vídeo. Simples, objetivo e direto. Top!
A discução é interessante, mas é temporal. Houve um momento do desenvolvimento de software em que a grade polêmica é se uma função poderia ter mais de um ponto de retorno. A ideia da vez é que adicionar mais pontos de retorno dificultava aa manutenibilidade do software. No seu código de "bom exemplo" você colocou 4 returns e provavelmente ninguém irá apontar isso como um problema. As discussões de padrões são temporais. Embora não deixem de ser interessantes
O grande ponto de discordância não acaba sendo o else em si, mas o efeito colateral do seu uso, aí entramos mais em estrutura de algoritmo mesmo. Se levarmos a discussão pra linguagens funcionais ela morre, é impossível não ter else quando se lida puramente con expressões.
Falei esses dias com um júnior da equipe. Normalmente eu olho o código e tento simplificar a lógica pra não ter tipos de casos de if/else e else if várias vezes
Sabendo separar bem como foi feito no vídeo de pensar o reverso da ideia ou de outra maneira. Senão uso um switch pra casos com mais se 3 tipos de estados
Uso pouco else, mais um if com retorno do método acho que fica fácil de entender
Não prometeu nada, e entregou tudo!
Quanta informação de qualidade!
Passo longe de ser bom, porém, em 5:09, faz mais sentido na minha cabeça a refatoração recomendada com apenas If
Meu deus eu tava com esse problema ( trocentos elses) com as mesmas condiçoes malucas
(range de números) e meu deus agora meu código tem tipo 20 linhas a menos. Obrigada
Instintivamente parei de usar else. Achei q era só comigo, mas pelo jeito mais pessoas pensam assim. Particularmente gosto de usar elif mesmo com return. Pra ajudar a dizer que todas condições são sobre o mesmo problema.
Eu já estava fazendo isso sem nem saber. Percebi que era mais fácil adicionar ou remover itens do código desta forma.
A utilização de blocos tem a ver com conclusões de ideias lógicas. Se seu objetivo referente à uma variável é modificar seu valor naquele bloco, então é elegante usar if/elif/else para o objetivo, ou até mesmo um match/case.
Quando se utiliza diversos blocos if únicos, passa um ideia amadora de lógicas dispersas que não se interligam. Todo bloco tem uma finalidade.
Faltou só falar sobre extrair em métodos quando o código for grande
Ia comentar sobre o match (ou switch como falou) mas vários colegas já comentaram
No mais, gosto e uso bastante o que chamou de lookup table.
Sempre pensei e chamei isso de mapeamento de dados (de para)
6:48 eu uso else exatamente pra isso. O uso dele pra mim é só pra facilitar mais ainda a legibilidade, mas não uso a real funcionalidade dele. Tem certos casos q usar switch eh até válido, mas ficaria melhor usar uma cadeia de if else, tipo para verificar várias variáveis diferentes
Na minha opinião esle é bom quando é só um,
Tipo código pra game, uma porta está trancada, se o player tem a chave abre, senão manda a mensagem porta está trancada
Eu posso até copiar e colar esse código em todas as portas e só trocar qual chave cada porta ou grupo de portas usa em caso dos keycards do doom
só uma coisa, quando vc tava lendo o artigo e disse q o if elif, poderia ser substituído por um switch, na verdade ele n poderia, pois justamente a diferença do switch é q ele n executa na sequencia de cima pra baixo, então no exemplo do artigo, se por exemplo o usuario não estivesse logado e estivesse no modo incógnito ao mesmo tempo, viraria uma condição de corrida.
Em várias linguagens como o próprio C, vc tem a opção de usar um BREAK ao final do tratamento de cada uma das cláusulas, pq vc pode querer fazer justamente isso de continuar checando por outras condições
Em outras o break é implícito e não dá para usar esse tipo de fluxo.
Eu não acho uma discussão técnica boba, legibilidade pra mim é uma das coisas mais importantes no meu código, eu quero bater o olho e saber o que tá acontecendo, você ganha muito tempo, não precisa ficar com 5 condições na cabeça pra ler o miolo do código, e a manutenção como foi dito no vídeo é muito mais fácil. Um outro benefício é que você pode espremer a janela do código muito mais, já que cada if dentro de if é um espaço da tela que é perdido.
O uso ou não de "else" pode não fazer muito sentido em muitas aplicações atualmente.
Principalmente se o foco for acadêmico em relação à utilização de técnicas ou como exemplificado muito bem por você Augusto, no sentido de ter maior clareza no entendimento do processo.
Mas os devs devem sempre avaliar se a sua criação necessita ser eficiente ou eficaz.
Explicando melhor, o resultado que os devs precisam sofrerão evolução constante ou planejadas e neste caso, a redução da complexidade é muito bem vinda,
ou devido ao volume de dados ou necessidade de comunicação que tenha alguma limitação, a aplicação precisa de performance ( existe um custo de máquina que pode ser relevante para alguma aplicação).
Não é recomendado abandonar esta ou aquela técnica, mas entender o melhor momento de aplicar todo o nosso arsenal de informações ou situações nos momentos certos.
Se adicionar orientação a objetos aí então, fica mais xuxu beleza ainda, cria uma interface de user, e retorna um tipo de user na sua tabelinha 😊
Caraca, sua voz é igual a daquele youtuber que ensina idiomas.
6:03, o problema é que "você" tem que recalcular uma variável após a outra, no final de um código estruturado dessa forma, você vai ter um consumo de memória e processamento muito maior. Imagina ter que recalcular o valor 500 vezes, você perde tempo e processamento. Se você faz um "x => 5" ele pode retornar um valor, sim ou não, correto? Nesse caso essa situação, do minuto 6:03, pode até ser válida, mas imagina, uma seqüência de calculos, para resolver uma coisa. O Else-IF já faz o calculo, intrinsicamente , para todos os Ifs, Elses e Elses-Ifs.
Por isso a programação está indo de mal à pior, o povo nem sabe o que está escrevendo.
nossa. como nao encontrei seu canal antes!!
ja virei fã!
Não sabia que python não tinha switch.
Uso c# e se so tem 2 caminhos (if/else) uso ele, mas se tem 3 caminhos ou mais, ai eu uso switch, é mais rápido porque o compilador não precisa verificar cada if pra saber se é verdade, vai direto ao ponto.
Lembro da primeira aula de Switch do Guanabara que assisti, ele usando um desenho na lousa desenhando as ruas simbolizando cada variação (if dobrar pra direita chega na padaria?) kkkkkk o cara é mestre em explicar para quem ta no absoluto zero.
Acho que o maior problema em usar else, nao seja usar else, seja logica que se aplica quando se usa else, porque quando se programa desse jeito o seu programa/funcao acaba tendo muitas regras contida em outras regras, deixando o codigo dificil de ler e dificultando tambem os testes e a legibilidade dos testes . So pra constar que a funcao size poderia ser escrita como size = lambda value: int(math.log(value, 10)) e o user_roles.get deveria ter o default 'Unknown User' .
Cara o else é muito útil quando tu precisa fazer uma validação simples e depois rodar alguma coisa depois, tipo ler os dados de um usuário e depois montar uma resposta baseado nessa info. Se os dados que vou retornar são idênticas, tirando os dados do usuário que virão ou não, o else se encaixa bem. Pq o Early return vai te obrigar a fazer todas as outras tarefas antes de validar o usuário e dar um append das informações do usuário lá no final. Eu prefiro deixar o if sempre no topo do código nesse caso pq logo de cara eu sei que tem dados de usuário sendo tratados ali
Video muito bom man! Sem enrolação e bem claro! Valeu!😊
Eu realmente evito o Else mas tem vezes que é impossível não usar, meus códigos tem poucos mas os que estão lá são necessários
Augusto galego seu conteúdo é perfeito 😭😭
8:00 Não é um switch porque as condicionais são diferentes
cai de paraquedas no video mas adorei o conteúdo!! abraços!
07:55 mas o "match case" do python não é um tipo de switch?
sim
Sensacional! o match case em python configura o mesmo que o switch case? Obrigado!
Sou totalmente leigo em programação, tô começando com c++ e cai por aqui de paraquedas kkkkkk bom vídeo apesar de eu não ter entendido nada kkkk
Edit: Não pretendendo trabalhar com programação, só que eu sempre gostei de programação e hacking, mas tinha muita preguiça de ir atrás pra aprender, então acabei criando vergonha na cara depois de 6 anos e decidi aprender algo kkkk quero aprender só por hobby, quero acordar algum dia e falar "não tenho nada pra fazer, vou codar"
Existem 3 tipos de programadores:
1° Os que fizeram prog 2
2° Os que preferem aeds.
3º Os que preferem engenharia de software.
Em tese, else diminui o custo de execução do código. Quem estudou assembly, por exemplo, faz prioridade de comparação, ou seja, o que vai ser mais acessado primeiro. Então se tu sabe que 1 if será executado 50% das vezes, outros 30%, o outro 20%, fica nessa ordem.
Logo, imagine que você tem 30 if's em sequência. Com else se primeiro corresponder ele não vai executar os outros 29 if's (se não tiver um return dentro dela), já se não tiver, mesmo que o primeiro seja o certo vai executar 30 vezes.
Agora, dentro de usa função, onde todo if tem return, não tem porque else. A Google usou um péssimo exemplo.
Para quem usa linguagens focadas em eficiência de execução else é bem útil, já quem programa em Python, eficiência não é nem levada em conta, else dispensável.
Eu programo c/c++, vou mais para eficiência que legibilidade ou patterns. Por mais que eu use uma versão de um, que quebra tudo em pequenas funções, com o inline, o custo não muda muito.
EXATO! Sou engenheiro e desde o técnico em eletrônica compilando um Z80 no braço, sempre penso no tempo de máquina que vou ficar em cada scan e mesmo em python acabo mantendo essa mentalidade.
Impressionante, sempre usei esse approach diferente nos meus códigos e só uso o ELSE quando não tenho outra saída. Mas descobri agora que tem toda uma discussão sobre disso hahahaha
Que legal, gostei do seu conteúdo! Ganhou um Inscrito!
o pior que gente querendo evitar hadouken de if com escadinha de ternário
Look up table é massa.
Ótimo canal, muito obrigado por compartilhar o conhecimento!
Não sou programador profissional, mas acho o else muito mais claro. Não só no exemplo do google, mas em todos que eu me lembre. Quando você usa o return pra indicar que o que vem depois não será executado me parece uma espécie de "goto", pois eu tenho que entender um fluxo que não é tão natural, justamente por remover dependências dos blocos... O else e else if deixam claro o fluxo para mim.
eu particulamente sou fã de pattern matching, acreito que qualquer condicional possa se resolver com ele, ponto.
Aula de clean code
tb gostei do canal. as explicacoes sao diretas
Hoje em dia Python possui "Switch Case". Se chama Match Case. Só para complementar a informação :D
Piazada seguinte, else é quando o input recebido nao pode ser lidado pelo seu codigo, por exemplo ali no ultimo exemplo dele, ele ainda precisaria retornar algo se o user nao existisse no object, um if/else reolveria.(se usar early return um simples if resolve eu sei, mas nao fica tao legivel)
python tem swtich, é uma feature recente, mas acredito que é anterior à 2 semanas do vídeo.