📚 APRENDE PROGRAMACIÓN EN PLATZI Accede a más de 1000 cursos y 21 áreas de estudio con este DESCUENTO para nuestra comunidad: 🔗 mouredev.com/platzi 🔗 Redes y enlaces de interés | moure.dev 👾 Discord | mouredev.com/discord
Yo creo que te empecé a seguir y mirar tus videos porque me relajás, sos como el modo Zen del programador extremo. Te pongo de fondo casi como un podcast... La mayoría de las cosas de las que hablás ya las sé, por experiencia y la facultad etc, pero siempre algún concepto nuevo se aprende. Aún así dejo todo para relajarme jajaja. Me encantaría tener más amigos y conocer más gente como vos. Yo soy muy electrificado, y las personas como vos me hacen bien. Gran contenido abrazo.
A mí en lo personal me gusta modularizar mas algunos compañeros de trabajo en alguna oportunidad me han dicho que programo "enredado". Otra práctica que he empezado a utilizar este año (y en proyectos personales) es programar en inglés, ya que los nombre de funciones y variables son más cortos, entre otras muchas ventajas (como mejorar y aprender el idioma). Saludos desde Santiago de Chile.
Razón extra en el punto 14: las palabras en Inglés son usualmente mas cortas en ese idioma a comparación con el nuestro, por lo mismo los nombres de funciones y variables terminarán siendo mas cortos, por ende mas legibilidad en bloques grandes de codigo.
@Kung Foo - Programación y demás sandeces Entiendo y en parte estoy de acuerdo, lo decía desde el punto de vista de "buscar el pedazo de codigo dentro del archivo donde esta X funcionalidad", No puedes negar que un shorthand if es mucho mas legible con variables cortas jaja. Sobre el naming, hay bastantes convenciones para mantenerlas concisas e informativas, personalmente uso camel case con tipo al inicio, como "strTitle", "arrPosts", "oPost", para strings, arreglos y objetos respectivamente.
De verdad que es agradable ver tus videos, transmites paz y tu castellano no pareciera que estas en España. Un gusto haber llegado a tu canal y a ver si un dia nos cuentas como te organizas en un día de labores(o como lo hacías en el pasado y que mejoraste, tanto profesional como familiar)
Que buen video es el mejor que e visto ya que no solo te muestran como mejorar tu forma de programación sino también dan una comprensión más profunda del todo lo que realizas durante la programación y esto como bien dice es aplicado a todos los lenguajes de programación, la verdad me encantó ya que no había en internet ningún curso así donde te explican el porque de las cosas muchos cursos en línea actualmente se centran en como resolver un problema o como usar una metodología y ya es todo nunca explican el motivo de porque esa estructura ni porque debes hacerlo de esa forma o ni siquiera mencionan que esa es la forma correcta, la verdad me encantó el vídeo muchas gracias por el video me sirvió mucho sigue así 👍🏻 gran video pocos canales como el tuyo la verdad me alegro mucho de haberlo encontrado, estaré al pendiente de todos tus videos, saludos.
Tienes unamanera excelente de explicar las cosas, tus cursos son estupendos, recién empezaré el de python y espero luego continuar con los demás, muchas gracias Moure
Yo como desarrollador con muchos años en el sector, siempre recomiendo NUNCA COMENTAR CÓDIGO bajo casos excepcionales. Un código SIEMPRE TIENE QUE SER AUTODESCRIPTIVO por sí mismo. Si hay algo en el código que cuesta de entender,es por el echo de que el desarrollador no se ha explicado bien en el desarrollo semantico del código. Siempre hago la analogía con una partitura , a caso una partitura está reescrita por el compositor o se entiende por la simbología lo suficiente como para tocar un instrumento. Pues el mismo caso para el código NUNCA HAY QUE COMENTAR LO QUE YA ESTÁ COMENTADO, simplemente hay que encontrar técnicas de escritura para que un desarrollador pueda entender un código con solo un vistazo rápido. Si UN CÓDIGO ESTÁ MUY COMENTADO ES PORQUE NO ES AUTODESCRIPTIVO eso es sinónimo de mala programación. Sin embargo sí que considero que hay excepciones, por ejemplo, has tenido que hacer algún remiendo/ chapuza porque no se adapta bien tu libreria con el sistema. Y explicas porqué has tenido que solucionarlo así, trozos de código que crees que pueden causar algun efecto de duda, pero siempre en casos excepcionales. Otro problema al comentar el código es que los comentarios quedarán obsoletos en poco tiempo hasta que deje de ser consistente el comentario con el código ,por el simple echo de que el código ha pasado por muchas manos. Dejando como resultado confusión para la gente que empieze a tocar esa parte de código. Resumiendo NO COMENTES LO QUE YA ESTÁ COMENTADO.
Correcto, el código debe ser autodescriptivo. Si el trozo de código es difícil de entender es un mal diseño. Los comentarios también deben ser mantenidos para que expliquen los cambios en el código que comenta... Si se diseña bien no son necesarios.
Cuando tienes que retomar o retocar algo que hiciste hace 2-3 años se agradece que este mínimamente comentado para no volverte loco. Hay lenguajes que son mas autoexplicativos que otros, pero comentar nunca esta de mas y si trabajas con mas gente es obligatorio comentar lo que haces.
te agradezco por todo la información, la verdad no tenia idea alguna de todos esas malas practicas, esto es una ayuda muy importante para alguien que esta comenzando.
Mil gracias Maure llevo aprendiendo a programar desde hace 3 meses y la verdad saber donde están los agujeros para no pisarlos es muy bueno, y ya que lo has preguntado de los 15 conocía 10 los que tienen que ver con clases y funciones aun no se lo que son jejejeje seguro que con tiempo entiendo todo lo que has explicado en el video. Aun así mil gracias por el video
Excelentes Tips, personalmente me quedo con el uso del constructor para estados null de objetos en la sección de hardcoding este punto va resultar beneficioso en los diseños. gracias por el tutorial.
Estoy aprendiendo a programar (hace varios meses ya 😵💫) y estoy tratando de aplicar los consejos de este video en un programa de práctica, un registro de entrada y salida para ser más exacto. Estoy tratando de meter todo lo que pueda en funciones para reducir el código repetido, pero no puedo evitar anidar dos o tres sentencias if 😂. Como sea, me ha servido bastante este video como orientación.
Vídeo recomendadísimo, sobre todo para empezar a tapar smells antes de que llegue nuestro amigo y vecino Sonar 😂. Me ha llamado la atención la parte de comentar el código. Entre la "antigua" norma de comentar mucho y Uncle Bob diciendo que un código limpio no necesita comentarios, al final el saber dónde y cómo comentar es todo un arte jedi.
gracias por los tips, me interesó el tema, ya que soy programar por autoaprendizaje, según estos puntos, no estoy tan mal, siempre hay algo que mejorar, pero en general ando bien, gracias, execelente vídeo.
Muy amena realmente tu clase, oportuna, buenos tips, buenos ejemplos.. agradecido. Hay una mala practica que he observado en muchos programadores y yo mismo trato de corregir, y es que llega un punto donde tienes cansados ojos, espalda, etc... y en ese momento vale más parar así sea unos minutos e incluso hacer así sea unos estiramientos mínimos, yo sumaría masajear incluso la zona superior que bordea las cuencas de los ojos, en mi caso entreno algo de kunfu cuando ya no valgo medio o acumulo mucho stress y es impresionante lo que ayuda. Lo mismo lo de masajear las zonas indicadas e incluso cuello trapecios y estimular algún punto de acupuntura como 20VB... les recomiendo un canal de youtube llamado templo del masaje creoque la chica tiene mucha mística y aporta unos recursos que son útiles para el cotidiano y no se limitan solo a palear el cansacio acumulado por el trabajo...
Muchísimas gracias, me ayudó a darme cuenta de varios errores que he cometido y que me doy cuenta que me hubieran hecho el trabajo más fácil de haberlos hecho bien
imagino que no soy el único en comentar esto pero, la razón 14 no está al revés? es decir, que sería SI programar en inglés, por ser el idioma universal de programación?
Brais estás en mi lista de inspiración mil gracias por tu conocimiento, quisiera subieras una guia para programar en mobil usando HTML, JS y CSS no he encontrado información se que algunos mencionan angular, cordoba y la base de datos firebase pero no encuentro alguien que arme una guia para poder desarrollar una app en movil con lenguaje web y poder diseñar mis app te agradecería mucho anhelando en un futuro poder devolverte todo ese conocimiento
Excelente video man, respecto al punto 11 podría decir que los comentarios se ahorran si el nombre de la clase o función describe correctamente lo que hace. Si es una función que cuenta con un algoritmo complejo, si podría ayudar algún comentario que especifique cierto paso.
Para mi el objetivo de un hacer un código un programa un software es que funcione y listo y el buen programador sabe que aunque el programa sea correcto en el resultado sabe cuales son los errores escondidos es decir códigos que si sumamos 2+2 debe dar 4 es lo correcto pero debe tener en cuenta que si por error se digita cualquier tecla no se valide y esto debe tenerse en cuenta en la creación del código y listo cada programador diseña su programa independiente lo otro es que se copie el código pero si no lo entiende queda mamando.
Tengo un jefe que no le gusta que use palabras en ingles cuando programo, mas que todo en las bases de datos me gusta usar "id", mi jefe a pesar que sabe que significa no le gusta, dice que use identificador o secuencia... digo es mas fácil dos letras... en fin.
jajaja, Tengo un compañero que hacia (o hace) todo eso, a tal grado que terminaba los proyectos en minutos y el programa funciona, aunque no hace lo que deberia hacer.
Has enseñado un poco de POO o OOP. Eso es un poco avanzado. Sería bueno que expliques algunas palabras en Inglés que usas como por ejemplo Hard Coding. Yo no tengo problemas pero otros se pueden quedar en la luna. Me gusta sus videos porque necesito saber las palabras técnicas que se usa en español. Gracias.
Completamente de acuerdo en todas ellas, pero particularmente me gusta nombrar a mis variables y funciones en español ya que así las distingo muy fácilmente de las que he usado del propio lenguaje y librerías y además hace más comprensible mi código.
Otra mala práctica muy hbaitual que he visto es la de usar códigos de mil o más líneas, meter todo en una única clase o método/función, y también lo contrario, astraer en 20 clases algo.
14:39 *_"Pensemos siempre en la seguridad de la ejecución de ntro programa. Cuantas menos cosas pueda hacer, más seguro será, y menos podremos meter la pata"_* Y esto señores es la definición de la filosofía Unix, q Linux adoptó exitosamente x 20 años... hta la llegada de Poettering y sus "bad boys" balbuceando q era un criterio viejo y "obsoleto" q no cabía en una mentalidad "moderna" y "revolucionaria" como la de ellos y lo desecharon... lo q llevó a esas "maravillas" de systemd, pulseaudio y otras, a las q pintan color "progreso" y no son más q la versión remozada de una mala idea, fallida y antiquísima. Muy agradecido x este video. Es una bocanada de aire fresco en este ambiente viciado de necios con pretensiones de "lumbreras".
Me encanta tu comentario de 'tu yo del futuro'. A todos los que han trabajado conmigo les digo (en cuanto a comentarios) pon el comentario para que , al menos, tu yo del futuro se entere.... Bueno... De 15... Tengo q revisar bien las de las variables... Ahí tengo q decir que no le presto toda la atención aunque suelo hacerlo. Por el resto... Me has dado un "subidón... subidón..."😁
Algo que dijiste me hizo mucho ruido... yo el code smell que uso con respecto a comentarios es el opuesto: Si un código tiene mucho comentario explicando como funciona, es probable que ese código esté mal escrito y no sea lo suficientemente legible. Lo dice Rob Martin: un comentario es una demostración de la incapacidad de expresarse en código. Aparte el código evoluciona y nunca se está 100% seguro que se modifique los comentarios. Mejor separar el código complejo en varias funciones autoexplicativas
Cero comentarios me parece un error. Me refiero a comentar código que lo precise. A veces, por bueno que sea el código, un comentario acertado puede ahorrarte mucho trabajo.
@@mouredev O sea, me parece que decir que "Cero comentarios me parece un error" es demasiado fuerte. Yo te puedo pasar código que escribí sin comentarios(hablo de comentarios, no xdoc que si me parece bueno) y estoy seguro que vas a entender bien y rápido lo que hace inclusive sin saber la tecnología que estoy usando. El comentario es en si el ultimo recurso cuando no se puede lograr un código más entendible. Es más, concuerdo con Rob Martin cuando expresa que un comentario es una incapacidad de expresarse(que eso es lo que hacemos cuando codificamos). Muchos comentarios son facilmente eliminables si se aplica lo que dice en video(modulacion + bien nombrado) Por Ejemplo: if ((person.sex = FEMALE && person.age > 60)) || (person.sex = MALE && person.age > 65) || (person.isDisabled())) {...} // Is the person eligible for a pension? ese comentario aporta valor porque explica facilmente que chequea ese if y como decis nos facilita el trabajo. Pero no es mejor: if (person.isPensionEligible()) {...} Con el resto de los puntos estoy en general de acuerdo, alguno con pequeño matiz y agregaría alguno más(el else es un enemigo por ejemplo)
Me gustaría que profundizaras un poco más en el apartado de seguridad ya que ha quedado un poco abierto (entiendo que cada lenguaje tendrá lo suyo). Lo de los comentarios es una de las cosas que genera más dilemas, hay quien comenta poco (o nada) y quien comenta demasiado, a nivel personal prefiero un código sobre comentado que no un código apenas comentado. Buen video.
excelentes consejos ! consulta sobre el curso de kotlin que tenes en youtube! esta actualizado? o lo vas a actualizar? estoy estudiando programacion full stack , pero quisiera a futuro irme para el lado mobile, me llama muchisimo la atencion,y quisiera aprender kotlin, se java pero por lo que vi en kotlink hay muchos cosas que varian y me confunden por eso quiero arrancar con kotlin aparte que veo el lenguaje esta ganando terreno en lo que es mobile
Con el tema de los comentarios no estoy de acuerdo, si haces los tests, estos mismos documentarán el código. Nosotros no ponemos ningún comentario para explicar código, lo consideramos una mala práctica en el equipo...
Yo creo que hay que poner muy pocos, pero en algunos casos, a pesar de test, pueden ayudar mucho a entender la complejidad de una funcionalidad rápidamente empleando medio minuto. Obviamente, todo es discutible :)
No estoy de acuerdo con esa práctica tan extendida de dividir funciones relativamente extensas en funciones más pequeñas, creo que si lo que hace la función tiene coherencia y sigue una secuencia lógica de pasos relacionados entre sí, no hay motivo para segregar dicha lógica, en mi opinión así se consigue lo contrario a "simplificar".
No se Pyton, pero por el estructurado, creo intuir que es el lenguaje que usastes para los ejemplos. Una duda ¿el proceso de minimizar lineas, tambien puede ser considerado mala practica?, ejemplo burdo : una funcion con un parametro y un console.log para ver si llegó el objeto correctamente, todo en una sola linea... es considerada mala practica? Se ganó de antemano un like por lo bien explicado en el video. Gracias
📚 APRENDE PROGRAMACIÓN EN PLATZI
Accede a más de 1000 cursos y 21 áreas de estudio con este DESCUENTO para nuestra comunidad:
🔗 mouredev.com/platzi
🔗 Redes y enlaces de interés | moure.dev
👾 Discord | mouredev.com/discord
Yo hace meses que estoy estudiando en Platzi :P
Yo creo que te empecé a seguir y mirar tus videos porque me relajás, sos como el modo Zen del programador extremo. Te pongo de fondo casi como un podcast... La mayoría de las cosas de las que hablás ya las sé, por experiencia y la facultad etc, pero siempre algún concepto nuevo se aprende. Aún así dejo todo para relajarme jajaja. Me encantaría tener más amigos y conocer más gente como vos. Yo soy muy electrificado, y las personas como vos me hacen bien. Gran contenido abrazo.
A mí en lo personal me gusta modularizar mas algunos compañeros de trabajo en alguna oportunidad me han dicho que programo "enredado". Otra práctica que he empezado a utilizar este año (y en proyectos personales) es programar en inglés, ya que los nombre de funciones y variables son más cortos, entre otras muchas ventajas (como mejorar y aprender el idioma).
Saludos desde Santiago de Chile.
Razón extra en el punto 14: las palabras en Inglés son usualmente mas cortas en ese idioma a comparación con el nuestro, por lo mismo los nombres de funciones y variables terminarán siendo mas cortos, por ende mas legibilidad en bloques grandes de codigo.
@Kung Foo - Programación y demás sandeces Entiendo y en parte estoy de acuerdo, lo decía desde el punto de vista de "buscar el pedazo de codigo dentro del archivo donde esta X funcionalidad", No puedes negar que un shorthand if es mucho mas legible con variables cortas jaja. Sobre el naming, hay bastantes convenciones para mantenerlas concisas e informativas, personalmente uso camel case con tipo al inicio, como "strTitle", "arrPosts", "oPost", para strings, arreglos y objetos respectivamente.
De verdad que es agradable ver tus videos, transmites paz y tu castellano no pareciera que estas en España. Un gusto haber llegado a tu canal y a ver si un dia nos cuentas como te organizas en un día de labores(o como lo hacías en el pasado y que mejoraste, tanto profesional como familiar)
Que buen video es el mejor que e visto ya que no solo te muestran como mejorar tu forma de programación sino también dan una comprensión más profunda del todo lo que realizas durante la programación y esto como bien dice es aplicado a todos los lenguajes de programación, la verdad me encantó ya que no había en internet ningún curso así donde te explican el porque de las cosas muchos cursos en línea actualmente se centran en como resolver un problema o como usar una metodología y ya es todo nunca explican el motivo de porque esa estructura ni porque debes hacerlo de esa forma o ni siquiera mencionan que esa es la forma correcta, la verdad me encantó el vídeo muchas gracias por el video me sirvió mucho sigue así 👍🏻 gran video pocos canales como el tuyo la verdad me alegro mucho de haberlo encontrado, estaré al pendiente de todos tus videos, saludos.
Muchísimas gracias!
¡Qué buenos consejos!. Muy útiles y directos. Se agradece.
Tienes unamanera excelente de explicar las cosas, tus cursos son estupendos, recién empezaré el de python y espero luego continuar con los demás, muchas gracias Moure
Bueno, me quedo tranquilo porque no suelo hacer ninguno de estos fallos y eso que he sido autodidacta toda la vida!
Yo como desarrollador con muchos años en el sector, siempre recomiendo NUNCA COMENTAR CÓDIGO bajo casos excepcionales. Un código SIEMPRE TIENE QUE SER AUTODESCRIPTIVO por sí mismo. Si hay algo en el código que cuesta de entender,es por el echo de que el
desarrollador no se ha explicado bien en el desarrollo semantico del código. Siempre hago la analogía con una partitura , a caso una partitura está reescrita por el compositor o se entiende por la simbología lo suficiente como para tocar un instrumento. Pues el mismo caso
para el código NUNCA HAY QUE COMENTAR LO QUE YA ESTÁ COMENTADO, simplemente hay que encontrar técnicas de escritura para que un desarrollador pueda entender un código con solo un vistazo rápido. Si UN CÓDIGO ESTÁ MUY COMENTADO ES PORQUE NO ES AUTODESCRIPTIVO eso es sinónimo de mala programación. Sin embargo sí que considero que hay excepciones, por ejemplo, has tenido que hacer algún remiendo/ chapuza porque no se adapta bien tu libreria con el sistema. Y explicas porqué has tenido
que solucionarlo así, trozos de código que crees que pueden causar algun efecto de duda, pero siempre en casos excepcionales. Otro problema al comentar el código es que los
comentarios quedarán obsoletos en poco tiempo hasta que deje de ser consistente el comentario con el código ,por el simple echo de que el código ha pasado por muchas manos. Dejando como resultado confusión para la gente que empieze a tocar esa parte de código. Resumiendo NO COMENTES LO QUE YA ESTÁ COMENTADO.
Correcto, el código debe ser autodescriptivo. Si el trozo de código es difícil de entender es un mal diseño. Los comentarios también deben ser mantenidos para que expliquen los cambios en el código que comenta... Si se diseña bien no son necesarios.
Cuando tienes que retomar o retocar algo que hiciste hace 2-3 años se agradece que este mínimamente comentado para no volverte loco. Hay lenguajes que son mas autoexplicativos que otros, pero comentar nunca esta de mas y si trabajas con mas gente es obligatorio comentar lo que haces.
te agradezco por todo la información, la verdad no tenia idea alguna de todos esas malas practicas, esto es una ayuda muy importante para alguien que esta comenzando.
Mil gracias Maure llevo aprendiendo a programar desde hace 3 meses y la verdad saber donde están los agujeros para no pisarlos es muy bueno, y ya que lo has preguntado de los 15 conocía 10 los que tienen que ver con clases y funciones aun no se lo que son jejejeje seguro que con tiempo entiendo todo lo que has explicado en el video. Aun así mil gracias por el video
Excelentes Tips, personalmente me quedo con el uso del constructor para estados null de objetos en la sección de hardcoding este punto va resultar beneficioso en los diseños. gracias por el tutorial.
Este video vale oro., Felicitaciones, estoy empezando y estos consejos me vinieron muy bien. Gracias!!! Saludos desde Perú.
@@marioir9624 saludos a tu comunidad lgbt
Estoy aprendiendo a programar (hace varios meses ya 😵💫) y estoy tratando de aplicar los consejos de este video en un programa de práctica, un registro de entrada y salida para ser más exacto. Estoy tratando de meter todo lo que pueda en funciones para reducir el código repetido, pero no puedo evitar anidar dos o tres sentencias if 😂.
Como sea, me ha servido bastante este video como orientación.
Gracias por el aporte
Excelentes consejos!!! Muchas Gracias desde Perú
Son muchas cosas que mejorar!! Gracias por la información!! Saludos!
herramientas como el sonar te ayudan a mejorar mucho. excelentes consejos
Vídeo recomendadísimo, sobre todo para empezar a tapar smells antes de que llegue nuestro amigo y vecino Sonar 😂.
Me ha llamado la atención la parte de comentar el código. Entre la "antigua" norma de comentar mucho y Uncle Bob diciendo que un código limpio no necesita comentarios, al final el saber dónde y cómo comentar es todo un arte jedi.
Muy bueno el vídeo 👏👏. Muy bien explicado en cada punto y con los ejemplos justos para una mejor comprensión. Gracias. Saludos.
Gracias, cualquiera que ha intentado programar reconoce el valor de estos consejos, principalmente el de los comentarios. 👍
gracias por los tips, me interesó el tema, ya que soy programar por autoaprendizaje, según estos puntos, no estoy tan mal, siempre hay algo que mejorar, pero en general ando bien, gracias, execelente vídeo.
Muy amena realmente tu clase, oportuna, buenos tips, buenos ejemplos.. agradecido. Hay una mala practica que he observado en muchos programadores y yo mismo trato de corregir, y es que llega un punto donde tienes cansados ojos, espalda, etc... y en ese momento vale más parar así sea unos minutos e incluso hacer así sea unos estiramientos mínimos, yo sumaría masajear incluso la zona superior que bordea las cuencas de los ojos, en mi caso entreno algo de kunfu cuando ya no valgo medio o acumulo mucho stress y es impresionante lo que ayuda. Lo mismo lo de masajear las zonas indicadas e incluso cuello trapecios y estimular algún punto de acupuntura como 20VB... les recomiendo un canal de youtube llamado templo del masaje creoque la chica tiene mucha mística y aporta unos recursos que son útiles para el cotidiano y no se limitan solo a palear el cansacio acumulado por el trabajo...
muchas gracias, excelenes consejos...
Muchas gracias! Siempre hay algo para mejorar.
Gran vídeo, me encantó!
9:30
¿Aquí se podría utilizar la sobrecarga de métodos? 🤔
Si pudieras ahondar en el tema de la seguridad en próximos videos estaría genial
excelente video, mucha gracias Mau, me ayudo mucho
me desespero con la programacion, me doy cuenta que toma tiempo, algun consejo para lidiar con eso y tener mas paciencia?
Este tipo de contenido siempre es necesario. Seguramente mi yo del futuro pasará por aquí a refrescar algo. Gracias
🙌🙌🙌
Muchísimas gracias, me ayudó a darme cuenta de varios errores que he cometido y que me doy cuenta que me hubieran hecho el trabajo más fácil de haberlos hecho bien
compre una membresía, no es mucho pero es de corazón, gracias por el contenido!!! cuando sea programador apoyaré mas!!!
Muchísimas gracias por tu ayuda 🙌
imagino que no soy el único en comentar esto pero, la razón 14 no está al revés? es decir, que sería SI programar en inglés, por ser el idioma universal de programación?
El título puede confundir, pero me refiero a no programar en inglés como lo que está mal
Excelente, muy acertados todos los consejos.
muy buen video gracias
Pensé que el primer error aprender a programar en Platzi
que buen te consulto es difícil editar un archivo bin es de un juego y quiero mopdificarlo para ver si funciona el nuevo objeto que quiero agregar
Muy útil, gracias!
Recomiendo usar swiftlint para evitar el code shmel
Brais estás en mi lista de inspiración mil gracias por tu conocimiento, quisiera subieras una guia para programar en mobil usando HTML, JS y CSS no he encontrado información se que algunos mencionan angular, cordoba y la base de datos firebase pero no encuentro alguien que arme una guia para poder desarrollar una app en movil con lenguaje web y poder diseñar mis app te agradecería mucho anhelando en un futuro poder devolverte todo ese conocimiento
Mil gracias!!
excelente video, gracias por todos los consejos que das bro, enserio eres increible
Genial! Muy útil
Que bien lo explicas.
Muy buen video ¡Gracias!
Excelente tutorial muy bien resumido y explicado. Muchas gracias
Muchísimas gracias!
Muy útil el video.
Excelente video man, respecto al punto 11 podría decir que los comentarios se ahorran si el nombre de la clase o función describe correctamente lo que hace. Si es una función que cuenta con un algoritmo complejo, si podría ayudar algún comentario que especifique cierto paso.
como acorto una cadena de if si quiero saber que tecla fue apretada? .Me pasa usando pygame get event en python
Para mi el objetivo de un hacer un código un programa un software es que funcione y listo y el buen programador sabe que aunque el programa sea correcto en el resultado sabe cuales son los errores escondidos es decir códigos que si sumamos 2+2 debe dar 4 es lo correcto pero debe tener en cuenta que si por error se digita cualquier tecla no se valide y esto debe tenerse en cuenta en la creación del código y listo cada programador diseña su programa independiente lo otro es que se copie el código pero si no lo entiende queda mamando.
Vengo de LinkedIn, excelente video!
Buenísimo me encantó 👏👏
Excelente video! 🕶
Tengo un jefe que no le gusta que use palabras en ingles cuando programo, mas que todo en las bases de datos me gusta usar "id", mi jefe a pesar que sabe que significa no le gusta, dice que use identificador o secuencia... digo es mas fácil dos letras... en fin.
No pinta bien... Pero bueno, si os entendéis 😀
Si no valen 2 letras, pues se le llama identifier o sequence
@@mouredev voy a aplicarsela jajaja
jajaja, Tengo un compañero que hacia (o hace) todo eso, a tal grado que terminaba los proyectos en minutos y el programa funciona, aunque no hace lo que deberia hacer.
Pensé que el código 🍝 era aquél que en una clase se crea la vista, el controlador y las consultas SQL.
Todo en uno, sin separar lo.
Has enseñado un poco de POO o OOP. Eso es un poco avanzado. Sería bueno que expliques algunas palabras en Inglés que usas como por ejemplo Hard Coding. Yo no tengo problemas pero otros se pueden quedar en la luna. Me gusta sus videos porque necesito saber las palabras técnicas que se usa en español. Gracias.
En pycharm con python me marca como typo escribir en español, ostias tío si con la variables en español me entiendo
Sigo sin entender porque algunos youtubers ponen voz de GPS
Completamente de acuerdo en todas ellas, pero particularmente me gusta nombrar a mis variables y funciones en español ya que así las distingo muy fácilmente de las que he usado del propio lenguaje y librerías y además hace más comprensible mi código.
El guru de la programacion
Yo añadiría como error crítico el pensar que ya sabes programar y no seguir formándote
Hola compañero TH-camr. Tu revisas aplicaciones???
Muy buen vídeo. Yo soy mucho de ifs kilometricos (ahi estan los retos semanales xD)
Es como Valentín San Juan y Joe Burger Challenge
Otra mala práctica muy hbaitual que he visto es la de usar códigos de mil o más líneas, meter todo en una única clase o método/función, y también lo contrario, astraer en 20 clases algo.
me ah parecido grandioso :D
El que más comete uno es hacer código similar para diferentes pantallas en vez de crear una con parámetros.
14:39 *_"Pensemos siempre en la seguridad de la ejecución de ntro programa. Cuantas menos cosas pueda hacer, más seguro será, y menos podremos meter la pata"_*
Y esto señores es la definición de la filosofía Unix, q Linux adoptó exitosamente x 20 años... hta la llegada de Poettering y sus "bad boys" balbuceando q era un criterio viejo y "obsoleto" q no cabía en una mentalidad "moderna" y "revolucionaria" como la de ellos y lo desecharon... lo q llevó a esas "maravillas" de systemd, pulseaudio y otras, a las q pintan color "progreso" y no son más q la versión remozada de una mala idea, fallida y antiquísima.
Muy agradecido x este video. Es una bocanada de aire fresco en este ambiente viciado de necios con pretensiones de "lumbreras".
mi cara después de que literalmente dijo las 15 cosas que hago mal
(┬┬﹏┬┬)
Me encanta tu comentario de 'tu yo del futuro'. A todos los que han trabajado conmigo les digo (en cuanto a comentarios) pon el comentario para que , al menos, tu yo del futuro se entere....
Bueno... De 15... Tengo q revisar bien las de las variables... Ahí tengo q decir que no le presto toda la atención aunque suelo hacerlo. Por el resto... Me has dado un "subidón... subidón..."😁
Algo que dijiste me hizo mucho ruido... yo el code smell que uso con respecto a comentarios es el opuesto: Si un código tiene mucho comentario explicando como funciona, es probable que ese código esté mal escrito y no sea lo suficientemente legible. Lo dice Rob Martin: un comentario es una demostración de la incapacidad de expresarse en código. Aparte el código evoluciona y nunca se está 100% seguro que se modifique los comentarios. Mejor separar el código complejo en varias funciones autoexplicativas
Cero comentarios me parece un error. Me refiero a comentar código que lo precise. A veces, por bueno que sea el código, un comentario acertado puede ahorrarte mucho trabajo.
@@mouredev O sea, me parece que decir que "Cero comentarios me parece un error" es demasiado fuerte. Yo te puedo pasar código que escribí sin comentarios(hablo de comentarios, no xdoc que si me parece bueno) y estoy seguro que vas a entender bien y rápido lo que hace inclusive sin saber la tecnología que estoy usando.
El comentario es en si el ultimo recurso cuando no se puede lograr un código más entendible. Es más, concuerdo con Rob Martin cuando expresa que un comentario es una incapacidad de expresarse(que eso es lo que hacemos cuando codificamos).
Muchos comentarios son facilmente eliminables si se aplica lo que dice en video(modulacion + bien nombrado) Por Ejemplo:
if ((person.sex = FEMALE && person.age > 60)) || (person.sex = MALE && person.age > 65) || (person.isDisabled())) {...} // Is the person eligible for a pension?
ese comentario aporta valor porque explica facilmente que chequea ese if y como decis nos facilita el trabajo. Pero no es mejor:
if (person.isPensionEligible()) {...}
Con el resto de los puntos estoy en general de acuerdo, alguno con pequeño matiz y agregaría alguno más(el else es un enemigo por ejemplo)
Osea los rusos y los chinos también programan en ingles?
Saudações do Brasil 🙂
Me gusto el video pero... donde puedo encontrar la playera?
Hahahah, la compré hace años en Primark
excelente video
Excelentes puntos.
Ahora veo el Video mouredev un like poderoso para ti brooo y me ayudara mucho tu video 🤟🤟🤟👍🙂🙂
Me han funcionado más los cursos de edteam.
Typo solo se le dice a los errores ortograficos. El mal nombramiento de variables es otra cosa aparte.
Me gustaría que profundizaras un poco más en el apartado de seguridad ya que ha quedado un poco abierto (entiendo que cada lenguaje tendrá lo suyo).
Lo de los comentarios es una de las cosas que genera más dilemas, hay quien comenta poco (o nada) y quien comenta demasiado, a nivel personal prefiero un código sobre comentado que no un código apenas comentado.
Buen video.
Ja Ja, eres exactamente una versión joven pero barbuda de mi profesor de base de datos e ingeniería del software.
Hola Moure, no me carga el enlace para el descuento de platzi 😔
Hola! Prueba con este: platzi.com/unete/afiliados-expert/?Brais
excelentes consejos ! consulta sobre el curso de kotlin que tenes en youtube! esta actualizado? o lo vas a actualizar? estoy estudiando programacion full stack , pero quisiera a futuro irme para el lado mobile, me llama muchisimo la atencion,y quisiera aprender kotlin, se java pero por lo que vi en kotlink hay muchos cosas que varian y me confunden por eso quiero arrancar con kotlin aparte que veo el lenguaje esta ganando terreno en lo que es mobile
Con el tema de los comentarios no estoy de acuerdo, si haces los tests, estos mismos documentarán el código. Nosotros no ponemos ningún comentario para explicar código, lo consideramos una mala práctica en el equipo...
Yo creo que hay que poner muy pocos, pero en algunos casos, a pesar de test, pueden ayudar mucho a entender la complejidad de una funcionalidad rápidamente empleando medio minuto. Obviamente, todo es discutible :)
Very good
y luego los programadores chinos que no cumplen con esto son los que mejor programan XD
No estoy de acuerdo con esa práctica tan extendida de dividir funciones relativamente extensas en funciones más pequeñas, creo que si lo que hace la función tiene coherencia y sigue una secuencia lógica de pasos relacionados entre sí, no hay motivo para segregar dicha lógica, en mi opinión así se consigue lo contrario a "simplificar".
No se Pyton, pero por el estructurado, creo intuir que es el lenguaje que usastes para los ejemplos. Una duda ¿el proceso de minimizar lineas, tambien puede ser considerado mala practica?, ejemplo burdo : una funcion con un parametro y un console.log para ver si llegó el objeto correctamente, todo en una sola linea... es considerada mala practica? Se ganó de antemano un like por lo bien explicado en el video. Gracias
Dijo al principio del video que es Swift (lenguaje que usa iOS/iPhone)
Los concole.log() colados en si son una mala practica. Solo utilizalos hasta comprobar que funciona de ahi eliminalo o coméntalo.
@@eltrolado5764 No es el enfoque el console.log (era sólo para dar un ejemplo), sino la práctica de minimizar y disminuir líneas.
Empieza el vídeo en el 3:15
que grande meintv
No programar en Inglés? Te referías a programar en inglés no?
No programar en inglés es la mala práctica
me jodi en el primer consejo
Qué grande Karim Benzema. Buenos tips!
Por que todos los programadores en yoututbe tienen barbita larga y siempre andan en franela ? 😂😂😂😂
Suscribanse al Canal de MoureDev, Primero otra vez. (Fijado en el Chat).
ho
ala madre creí que eras Hola mundo
😊😊😊
5 minutos para empezar!!!! Mucho intro.
Sería, en tal caso, "muchA intro"