 Buenas. Veo a presentaros a Fernando García. Fernando es desarrollador por vocación y profesión. Ha pasado por un montón de tecnologías y lenguajes. Y desde el año 2017 se dedica como autónomo, casi en exclusiva, a hacer proyectos a medida con WordPress y Google Commerce. Sus clientes son, en mayoría, agencias y profesionales que requieren desarrollos complejos en WordPress. Aparte, bueno, también le gusta el cine, la música. Y, bueno, él vive en un pequeño pueblo de Cantabria, su tierra, y desde allí trabaja mientras disfruta del privilegio de estar entre praos verdes. Así que, por favor, recibámosle con un grandísimo aplauso. Muy buenas. ¿Qué tal? ¿Bien? Vamos a ir rápido, ¿eh? Vamos a hablar de estándares de programación en WordPress, ¿vale? Simplemente, esto es muy denso, pero simplemente que sepáis que hay nuevos estándares de programación, os voy a contar un poquito en qué consiste. Y nada, vamos allá. Venga. Me presento. Me llamo Fernando. Bueno, ya me han presentado bastante bien. Soy desarrollador web autónomo. Mis trabajos, sobre todo, van orientados a hacer cosas raras en el entorno de WordPress y con bucomes, ¿vale? Llevo una mitad de la Venga y en Cantabria tengo un podcast con Adrián, que se llama El Arroyo. Y también colaboro haciendo desarrollos y demás con esta empresa de hosting, WP Ercules, que está orientada al hosting a profesionales y agencias, ¿vale? Si queréis echar un vistazo. Y nada, vamos allá. Estándares de programación. Esto es lo que dice la Wikipedia, ¿vale? Termino que describe convenciones para escribir código fuente en ciertos lenguajes de programación, ¿vale? Esto es lo que dice. Vamos a ver por qué necesitamos este tipo de convenciones en lenguajes de programación. Reuncen programas de seguridad y rendimiento, derivados de malas prácticas en codificación. Seguro que sí habéis mirado un código mal hecho, sabéis de qué estamos hablando, ¿no? Corrección de errores, muy importante. Si tenemos unos estándares, ¿vale? Podemos corregir fácilmente eso. Mantenimiento. No somos inmortales. Es decir, hoy estamos aquí. Mañana sabemos y el que venga detrás hay que facilitarle también un poquitín el trabajo. ¿De acuerdo? Legibilidad. Si alguna vez os ha tocado revisar algún código mal hecho, nos podemos tirar un día entero para saber qué es lo que haces. Entonces, hay que facilitar las cosas. Y esto también es muy importante y más dentro de Wordpress. Es muy importante en entornos como Wordpress, que somos pensores, ¿vale? Donde hay muchísimos colaboradores, es importante seguir unas normas para que cualquiera pueda entender qué es lo que hacemos ahí. Esta frase me encanta, ¿vale? Es un poco lo que resumo un poco lo que os quiero contar. Cualquier base de código debe tener el aspecto de haber sido escrito por una sola persona, independientemente del número de personas que hayan contribuido, ¿vale? Esto es un poco lo que hacemos en Wordpress. Wordpress tiene un montón de colaboradores, pero todos debemos ser capaces de leer un código escrito con Wordpress y saber qué es lo que hace, ¿vale? Y para esto tenemos los estándares. Bien, entonces, teniendo claro un poco los estándares de programación, los estándares en Wordpress, tenemos varios. Dentro de Wordpress hay varios estándares, ¿vale? Tenemos uno de PHP, HTML, CSS, JavaScript y estándares de accesibilidad. Estos son los estándares que podréis encontrar en la documentación de Wordpress, ¿vale? Para cada uno de los lenguajes, vamos a tener una forma de hacer el código para que, entre todos, podamos hacer un código más léger, ¿vale? Lo que os voy a hacer es simplemente darles algunas pautas de cada uno de ellos muy rápido, que sepáis que existen, podéis entrar a la documentación y leerlo, ¿vale? Mirad, empezamos por PHP, estándares de PHP. Os pongo aquí algunas cosas, no todas, ¿eh? Pero algunas. La eterna lucha, no, la eterna discusión de los programadores. ¿Tú querés espacios o de tabulador? Es como la tortilla con cebolla o sin cebolla. Bien, pues aquí somos de tabuladores, ¿vale? Aquí tabulaciones. Nombres de variables, minúsculas y con queón bajo. Etiquetas PHP en cada nueva línea y muchas más cosas. Aquí os dejo un cuérreo y luego la presentación lo compartiré, ¿vale? Para que podéis interrumpir. Por ejemplo, este código. Tenemos ahí un id, que si se cumple esa condición, los pinta ahí un parrafo, ¿vale? Según los códigos estándares de PHP, ¿esto está bien o está mal? Mal. Esto, error. ¿Por qué? Porque el bueno sería este. Fijaos, el de cerrar y PHP y volver a abrir PHP, tiene que estar en cada línea, ¿vale? Bien, más HTML. Las etiquetas han de cerrarse siempre. Etiquetas y atributos en minúscula y todos atributos tienen que tener un valor, ¿vale? Y escribir el valor con comillas. Tabuladores de nuevo y ahí os dejo el cuérreo. Por ejemplo, este ejemplo, un input, ¿vale? Veis que tiene name, nombre y disable. ¿Esto funciona? Sí, funciona. Pero no sigue estos estándares. Esos. Los suyos sería escribir así, entre comillas escribimos, el name y el disable, aunque funcione, le damos un valor. ¿Vale? Esos. ¿Vale? CSS, ¿qué tenemos en CSS? Otra vez, tabuladores. Aquí ganan tabuladores. Cada selector en una línea. Cada selector va a ir en una línea. Por lo general, en media queries, deberían de ir al final del archivo CSS. Por lo general, esto es complicado. Pero bueno, es complicado verlo que cada uno hace. Y nombre de clases, minúsculas, leíbles. O sea, vamos a intentar facilitar el trabajo del que venga detrás y vamos a poner un nombre de clases que se sepa que es eso, ¿vale? Y separados por guiones. Y esto vale para todo. Los comentarios son bienvenidos, por favor. Cuando desarrollemos, me da igual en qué lenguaje, comentad. No nos pagan menos por comentar. Hay que comentarlo todo. Porque el que venga detrás tiene que saber qué pasa ahí. Ahí está eso. Por ejemplo, mirad este ejemplo de CSS. Tenemos esas clases que es clase 1, clase 2, clase 3. Lo tenemos ahí y le damos un color, ¿no? Bien, esto estaría mal según estos estándares porque las clases deberían de ir el nombre de clase cada una en una línea. Este sería el correcto, ¿de acuerdo? JavaScript, tabuladores. Otra vez. Bien. Hay que evitar en todo la medida lo posible, las líneas demasiado largas. Joder, no me da tiempo. Nombres de variables, camel case. Y siempre que sea posible, utilicemos cons y led en vez de bar, ¿vale? Voy muy rápido, pero es que no me queda tiempo. Mirad este ejemplo, ¿vale? Eso está mal porque lo suyo sería hacerlo más legible. ¿De acuerdo? Vale, OK. Venga. Y luego tenemos accesibilidad. La accesibilidad se rige por estos cuatro principios. Ahí os dejo el enlace por los que se rigen los estándares de accesibilidad de works, ¿vale? Y, por favor, lo que os decía antes, quiero hacer hincapié en esto. Intentar hacer los desarrollos, comentar. Este es un meme muy clásico, pero está basado en hechos reales. Este comentario dice, cuando escribiste código, solo Dios y yo sabíamos lo que hacía. Ahora solo Dios lo sabe. ¿Por qué? Porque no he comentado el código. O sea, haceros un favor a vosotros mismos, a vuestro yo del futuro, y comentad todo. ¿Vale? Y lo siento, pero no. Hay tiempo de más. Muchas gracias.