Mejores prácticas de codificación

format_list_bulleted Contenido keyboard_arrow_down
ImprimirCitar

Las mejores prácticas de codificación o mejores prácticas de programación son un conjunto de reglas informales, a veces personales (mejores prácticas) que muchos desarrolladores de software, en programación informática, siguen para mejorar la calidad del software. Muchos programas informáticos requieren ser robustos y confiables durante largos períodos de tiempo, por lo que cualquier regla debe facilitar tanto el desarrollo inicial como el mantenimiento posterior del código fuente por parte de personas distintas a los autores originales.

En la regla del noventa y noventa, Tom Cargill explica por qué los proyectos de programación suelen retrasarse: "El primer 90 % del código ocupa el primer 90 % del tiempo de desarrollo. El último 10 % ocupa otro 90 % del tiempo". Vale la pena considerar cualquier orientación que pueda corregir esta falta de previsión.

El tamaño de un proyecto o programa tiene un efecto significativo en las tasas de error, la productividad del programador y la cantidad de gestión necesaria.

Calidad del software

Como se indica a continuación, existen muchos atributos asociados con un buen software. Algunos de ellos pueden ser contradictorios entre sí (por ejemplo, ser muy rápido frente a realizar una comprobación exhaustiva de errores), y los distintos clientes y participantes pueden tener distintas prioridades. Weinberg ofrece un ejemplo de cómo los distintos objetivos pueden tener un efecto drástico tanto en el esfuerzo requerido como en la eficiencia. Además, señala que los programadores, por lo general, intentarán alcanzar cualquier objetivo explícito que se les pueda establecer, probablemente a expensas de cualquier otro atributo de calidad.

Sommerville ha identificado cuatro atributos generalizados que no tienen que ver con lo que hace un programa, sino con lo bien que lo hace: mantenibilidad, confiabilidad, eficiencia y facilidad de uso.

Weinberg ha identificado cuatro objetivos que un buen programa debería cumplir:

  • ¿Un programa cumple su especificación ("producto correcto para cada entrada posible")?
  • ¿Se produce el programa a tiempo (y dentro del presupuesto)?
  • ¿Cómo adaptable es el programa para hacer frente a los cambios de requisitos?
  • ¿Es el programa lo suficientemente eficiente para el medio ambiente en el que se utiliza?

Hoare ha identificado diecisiete objetivos relacionados con la calidad del software, entre ellos:

  • Definición clara de propósito.
  • Simplicidad de uso.
  • Ruggedness (difícil de usar mal, amable de errores).
  • Disponibilidad temprana (se entrega a tiempo cuando sea necesario).
  • Confiabilidad.
  • Extensibilidad a la luz de la experiencia.
  • Brevity.
  • Eficiencia (lo suficientemente rápida para el propósito al que se pone).
  • Costo mínimo para desarrollarse.
  • Conformity to any relevant standards (including programming language-specific standards).
  • Documentos de usuario claros, precisos y precisos.

Prerrequisitos

Antes de comenzar a codificar, es importante asegurarse de que se han cumplido todos los requisitos previos necesarios (o al menos se ha avanzado lo suficiente para proporcionar una base sólida para la codificación). Si no se cumplen los distintos requisitos previos, es probable que el software no sea satisfactorio, incluso si se completa.

De Meek & Heath: "Lo que sucede antes de llegar a la etapa de codificación suele ser de importancia crucial para el éxito del proyecto".

Los requisitos previos que se describen a continuación cubren cuestiones como:

  • ¿Cómo se estructura el desarrollo? (ciclo de vida)
  • ¿Cuál es el software destinado a hacer? (requisitos)
  • ¿Cuál es la estructura general del sistema de software? (arquitectura)
  • ¿Cuál es el diseño detallado de componentes individuales? (diseño)
  • ¿Cuál es la opción de programar idiomas?

Para proyectos pequeños y sencillos puede ser posible combinar la arquitectura con el diseño y adoptar un ciclo de vida muy simple.

Ciclo de vida

Una metodología de desarrollo de software es un marco que se utiliza para estructurar, planificar y controlar el ciclo de vida de un producto de software. Las metodologías más comunes incluyen la cascada, la creación de prototipos, el desarrollo iterativo e incremental, el desarrollo en espiral, el desarrollo de software ágil, el desarrollo rápido de aplicaciones y la programación extrema.

El modelo en cascada es un enfoque de desarrollo secuencial; en particular, supone que los requisitos pueden definirse completamente al comienzo de un proyecto. Sin embargo, McConnell cita tres estudios que indican que, en promedio, los requisitos cambian alrededor de un 25% durante un proyecto. Las otras metodologías mencionadas anteriormente intentan reducir el impacto de dichos cambios de requisitos, a menudo mediante algún tipo de enfoque gradual, incremental o iterativo. Diferentes metodologías pueden ser apropiadas para diferentes entornos de desarrollo.

Desde su introducción en 2001, el desarrollo de software ágil ha ganado popularidad, impulsado por los desarrolladores de software que buscan un enfoque más iterativo y colaborativo para el desarrollo de software.

Necesidades

McConnell afirma: "El primer requisito previo que se debe cumplir antes de comenzar la construcción es una declaración clara del problema que se supone que el sistema debe resolver".

Meek y Heath enfatizan que el objetivo a alcanzar es una especificación escrita clara, completa, precisa e inequívoca. Tenga en cuenta que puede que no sea posible lograr este objetivo y que es probable que cambie de todos modos (como se mencionó en la sección anterior).

Sommerville distingue entre requisitos de usuario menos detallados y requisitos de sistema más detallados. También distingue entre requisitos funcionales (p. ej., actualizar un registro) y requisitos no funcionales (p. ej., el tiempo de respuesta debe ser inferior a 1 segundo).

Arquitectura

Hoare señala: "Hay dos maneras de construir un diseño de software: una es hacerlo tan simple que no haya deficiencias obviamente; la otra es hacerlo tan complicado que no haya deficiencias obvias. El primer método es mucho más difícil".

La arquitectura de software se ocupa de decidir qué se debe hacer y qué componente del programa lo va a hacer (la forma de hacerlo se deja para la fase de diseño detallado que se encuentra más adelante). Esto es particularmente importante cuando un sistema de software contiene más de un programa, ya que define efectivamente la interfaz entre estos diversos programas. También debe incluir alguna consideración de las interfaces de usuario, sin entrar en detalles excesivos.

En esta etapa es necesario tener en cuenta todos los requisitos no funcionales del sistema (tiempo de respuesta, confiabilidad, capacidad de mantenimiento, etc.).

La arquitectura del software también es de interés para las distintas partes interesadas (patrocinadores, usuarios finales, etc.) ya que les brinda la oportunidad de verificar que sus requisitos se pueden cumplir.

Diseño

El objetivo principal del diseño es completar los detalles que se han pasado por alto en el diseño arquitectónico. La intención es que el diseño sea lo suficientemente detallado como para proporcionar una buena guía para la codificación real, incluidos los detalles de cualquier algoritmo particular que se vaya a utilizar. Por ejemplo, en el nivel arquitectónico, puede haberse observado que algunos datos deben ordenarse, mientras que en el nivel de diseño, es necesario decidir qué algoritmo de ordenación se va a utilizar. Como otro ejemplo, si se utiliza un enfoque orientado a objetos, entonces se deben determinar los detalles de los objetos (atributos y métodos).

Elección de lenguaje(s) de programación

Mayer afirma: "Ningún lenguaje de programación es perfecto. Ni siquiera existe un único lenguaje que sea el mejor; sólo hay lenguajes que se adaptan bien o mal a determinados propósitos. Es necesario comprender el problema y los requisitos de programación asociados para elegir el lenguaje más adecuado para la solución".

De Meek & Heath: "La esencia del arte de elegir un lenguaje es empezar con el problema, decidir cuáles son sus requisitos y su importancia relativa, ya que probablemente será imposible satisfacerlos a todos por igual. A continuación, se deben comparar los lenguajes disponibles con la lista de requisitos y elegir el más adecuado (o el menos insatisfactorio)."

Es posible que distintos lenguajes de programación sean apropiados para distintos aspectos del problema. Si los lenguajes o sus compiladores lo permiten, puede ser factible mezclar rutinas escritas en distintos lenguajes dentro del mismo programa.

Aunque no haya elección sobre qué lenguaje de programación utilizar, McConnell ofrece algunos consejos: "Cada lenguaje de programación tiene sus puntos fuertes y débiles. Tenga en cuenta los puntos fuertes y débiles específicos del lenguaje que esté utilizando".

Normas de codificación

Esta sección también es un requisito previo para la codificación, como señala McConnell: "Establezca las convenciones de programación antes de comenzar a programar. Es casi imposible cambiar el código para que coincida con ellas más adelante".

Como se indica al final de las convenciones de codificación, existen diferentes convenciones para distintos lenguajes de programación, por lo que puede resultar contraproducente aplicar las mismas convenciones en distintos lenguajes. Es importante tener en cuenta que no existe una convención de codificación específica para ningún lenguaje de programación. Cada organización tiene un estándar de codificación personalizado para cada tipo de proyecto de software. Por lo tanto, es imperativo que el programador elija o elabore un conjunto particular de pautas de codificación antes de comenzar el proyecto de software. Algunas convenciones de codificación son genéricas, por lo que pueden no aplicarse a todos los proyectos de software escritos con un lenguaje de programación en particular.

El uso de convenciones de codificación es particularmente importante cuando un proyecto involucra a más de un programador (ha habido proyectos con miles de programadores). Es mucho más fácil para un programador leer el código escrito por otra persona si todo el código sigue las mismas convenciones.

Para ver algunos ejemplos de malas convenciones de codificación, Roedy Green ofrece un artículo extenso (en tono irónico) sobre cómo producir código que no se puede mantener.

Comentario

Debido a las restricciones de tiempo o a los programadores entusiastas que quieren resultados inmediatos para su código, los comentarios sobre el código suelen quedar en segundo plano. Los programadores que trabajan en equipo han descubierto que es mejor dejar los comentarios atrás, ya que la codificación suele seguir ciclos o puede que más de una persona trabaje en un módulo en particular. Sin embargo, algunos comentarios pueden reducir el costo de la transferencia de conocimientos entre los desarrolladores que trabajan en el mismo módulo.

En los primeros tiempos de la informática, una práctica habitual a la hora de comentar era dejar una breve descripción de lo siguiente:

  1. Nombre del módulo
  2. Propósito del Módulo
  3. Descripción del módulo
  4. Autor original
  5. Modificaciones
  6. Autores que modificaron el código con una descripción sobre por qué fue modificado.

La "descripción del módulo" debe ser lo más breve posible, pero sin sacrificar la claridad y la exhaustividad.

Sin embargo, los dos últimos elementos han quedado obsoletos en gran medida con la llegada de los sistemas de control de revisiones. Las modificaciones y su autoría se pueden rastrear de manera confiable utilizando estas herramientas en lugar de utilizar comentarios.

Además, si se utiliza una lógica complicada, es una buena práctica dejar un comentario llamado "bloque" cerca de esa parte para que otro programador pueda entender exactamente qué está sucediendo.

Las pruebas unitarias pueden ser otra forma de mostrar cómo se pretende utilizar el código.

Convenciones de nombres

Se considera una buena práctica utilizar convenciones de nombres adecuadas. A veces, los programadores tienden a utilizar X1, Y1, etc. como variables y se olvidan de reemplazarlas por otras significativas, lo que genera confusión.

Se considera una buena práctica utilizar nombres descriptivos.

Ejemplo: una variable para tomar el peso como parámetro de un camión puede llamarse TrkWeight, TruckWeightKilograms o Truck_Weight_Kilograms, siendo TruckWeightKilograms (consulte la denominación de variables en mayúsculas y minúsculas de Pascal) la opción preferida, ya que se reconoce al instante, pero la convención de denominación no siempre es uniforme entre proyectos o empresas.

Mantenga el código simple

El código que escribe un programador debe ser simple. La lógica complicada para lograr algo simple debe mantenerse al mínimo, ya que el código puede ser modificado por otro programador en el futuro. La lógica que implementa un programador puede no tener sentido para otro. Por lo tanto, siempre mantenga el código lo más simple posible.

Portabilidad

El código del programa no debe contener valores "codificados de forma rígida" (literales) que hagan referencia a parámetros ambientales, como rutas absolutas de archivos, nombres de archivos, nombres de usuario, nombres de host, direcciones IP y URL, puertos UDP/TCP. De lo contrario, la aplicación no se ejecutará en un host que tenga un diseño diferente al previsto. Un programador cuidadoso puede parametrizar dichas variables y configurarlas para el entorno de alojamiento fuera de la propia aplicación (por ejemplo, en archivos de propiedades, en un servidor de aplicaciones o incluso en una base de datos). Compare el mantra de un "punto único de definición" (SPOD).

Como extensión, los recursos como los archivos XML también deben contener variables en lugar de valores literales; de lo contrario, la aplicación no se podrá trasladar a otro entorno sin editar los archivos XML. Por ejemplo, con aplicaciones J2EE que se ejecutan en un servidor de aplicaciones, dichos parámetros ambientales se pueden definir en el ámbito de la JVM y la aplicación debe obtener los valores desde allí.

Escalabilidad

Diseñe el código teniendo como objetivo la escalabilidad, ya que, muy a menudo, en los proyectos de software se añaden nuevas características a un proyecto que se hace cada vez más grande. Por lo tanto, la posibilidad de añadir nuevas características a una base de código de software se convierte en un método invaluable para escribir software.

Reutilización

La reutilización es un objetivo de diseño muy importante en el desarrollo de software. La reutilización reduce los costos de desarrollo y también reduce el tiempo de desarrollo si los componentes o módulos que se reutilizan ya se han probado. Muy a menudo, los proyectos de software comienzan con una línea base existente que contiene el proyecto en su versión anterior y, según el proyecto, se reutilizan muchos de los módulos y componentes de software existentes, lo que reduce el tiempo de desarrollo y prueba, aumentando así la probabilidad de entregar un proyecto de software a tiempo.

Directrices de construcción breves

Una visión general de todo lo anterior:

  1. Saber qué debe realizar el bloque de código
  2. Mantener convenciones de nombres uniformes en todas partes.
  3. Indicar una breve descripción de lo que es una variable (referencia a comentar)
  4. Errores correctos cuando ocurren.
  5. Mantenga su código simple
  6. Código de diseño con escalabilidad y reutilización en mente.

Código de desarrollo

Code building

Una buena práctica para la creación de código implica la creación y prueba de código a diario, o mejor aún, la integración continua o incluso la entrega continua.

Pruebas

Las pruebas son una parte integral del desarrollo de software que debe planificarse. También es importante que las pruebas se realicen de manera proactiva, es decir, que los casos de prueba se planifiquen antes de comenzar la codificación y que se desarrollen mientras se diseña y codifica la aplicación.

Debugging the code and correcting errors

Los programadores tienden a escribir el código completo y luego comienzan a depurar y verificar errores. Si bien este enfoque puede ahorrar tiempo en proyectos más pequeños, los más grandes y complejos tienden a tener demasiadas variables y funciones que requieren atención. Por lo tanto, es bueno depurar cada módulo una vez que haya terminado y no todo el programa. Esto ahorra tiempo a largo plazo para que uno no termine perdiendo mucho tiempo tratando de averiguar qué está mal. Las pruebas unitarias para módulos individuales y/o pruebas funcionales para servicios web y aplicaciones web pueden ayudar con esto.

Despliegue

La implementación es la etapa final del lanzamiento de una aplicación para los usuarios. Algunas prácticas recomendadas son:

  1. Mantenga la estructura de instalación simple: Los archivos y directorios deben mantenerse al mínimo. No instales nada que nunca va a ser usado.
  2. Mantenga sólo lo que se necesita: Las actividades de gestión de la configuración de software deben asegurarse de que esto se cumpla. Los recursos no utilizados ( versiones antiguas o fallidas de archivos, código fuente, interfaces, etc.) deben ser archivados en algún otro lugar para mantener a los nuevos edificios inclinados.
  3. Mantenga todo actualizado: Las actividades de gestión de la configuración de software deben asegurarse de que esto se cumpla. Para los despliegues basados en el delta, asegúrese de que las versiones de los recursos que ya están desplegados son las últimas antes de desplegar los deltas. Si no es seguro, realizar un despliegue desde cero (deletrear todo primero y luego redistribuir).
  4. Adoptar una estrategia multietapa: Dependiendo del tamaño del proyecto, a veces se necesitan más despliegues.
  5. Tener una estrategia de retroceso: Debe haber una forma de volver a la versión anterior (trabajando).
  6. Confíe en la automatización para procesos repetibles: Hay demasiado espacio para errores humanos, las implementaciones no deben ser manuales. Utilice una herramienta nativa de cada sistema operativo o, utilice un lenguaje de scripting para implementaciones multiplataforma.
  7. Re-crear el entorno de despliegue real: Considere todo (ruters, cortafuegos, servidores web, navegadores web, sistemas de archivos, etc.)
  8. No cambie los procedimientos de implementación y scripts en el vuelo y, documente tales cambios: Espere a una nueva iteración y registre esos cambios apropiadamente.
  9. Personalizar el despliegue: Los nuevos productos de software, como API, microservicios, etc., requieren consideraciones específicas para el éxito del despliegue.
  10. Reducir el riesgo de otras fases de desarrollo: Si otras actividades como la gestión de pruebas y configuración son erróneas, el despliegue seguramente fracasará.
  11. Considere la influencia que cada participante tiene: Consideraciones organizativas, sociales y gubernamentales.

Véase también

  • Mejor práctica
  • Lista de herramientas para análisis de códigos estáticos
  • Motor Industry Software Reliability Association (MISRA)
  • Garantía del software
  • Calidad del software
  • Lista de filosofías de desarrollo de software
  • La Catedral y el Bazar - libro que compara el software de código abierto de arriba hacia abajo
  • Davis 201 Principios de desarrollo del software
  • ¿Dónde está la Teoría para Ingeniería de Software?
  • No me hagas pensar (Principios de navegación intuitiva y diseño de información)

Notas

Referencias

  1. ^ McConnell, Steve (2004). Código completo. Redmond, Wash.: Microsoft Prensa. p. ISBN 978-0-7356-9125-4. OCLC 61315783.
  2. ^ Sommerville, Ian (2004). Ingeniería de software (Seventh ed.). Pearson. p. 38. ISBN 0-321-21026-3.
  3. ^ Bentley, Jon (1985). "Programming Pearls: Bumper-Sticker Computer Science". Comunicaciones de la ACM. 28 (9): 896–901. doi:10.1145/4284.315122ISSN 0001-0782. S2CID 5832776.
  4. ^ McConnell, Steve (2004). Código completo (Segunda edición). Microsoft Press. pp. 649-659. ISBN 0-7356-1967-0.
  5. ^ Weinberg, Gerald (1998). La Psicología de la Programación Informática (Silver anniversary ed.). Dorset House Publishing, Nueva York. pp. 128–132. ISBN 978-0-932633-42-2.
  6. ^ Sommerville, Ian (2004). Ingeniería de software (Seventh ed.). Pearson. pp. 12–13. ISBN 0-321-21026-3.
  7. ^ Weinberg, Gerald (1998). La Psicología de la Programación Informática (Silver anniversary ed.). Dorset House Publishing, Nueva York. pp. 15–25. ISBN 978-0-932633-42-2.
  8. ^ Hoare, C.A.R. (1972). "La calidad del software". Software: práctica y experiencia. 2 2). Wiley: 103-105. doi:10.1002/spe.4380020202.
  9. ^ Meek, Brian; Heath, Patricia (1980), Guía de buenas prácticas de programación, Ellis Horwood, Wiley, p. 14
  10. ^ McConnell, Steve (2004). Código completo (Segunda edición). Microsoft Press. p. 40. ISBN 0-7356-1967-0.
  11. ^ Sacolick, Isaac (8 de abril de 2022). "Un breve historial de la metodología ágil". Infoworld. Retrieved 6 de febrero 2023.
  12. ^ McConnell, Steve (2004). Código completo (Segunda edición). Microsoft Press. p. 36. ISBN 0-7356-1967-0.
  13. ^ Meek, Brian; Heath, Patricia (1980), Guía de buenas prácticas de programación, Ellis Horwood, Wiley, p. 15
  14. ^ Sommerville, Ian (2004). Ingeniería de software (Seventh ed.). Pearson. pp. 118–123. ISBN 0-321-21026-3.
  15. ^ Hoare, C.A.R (1981). "El viejo vestido del Emperador" (PDF). Comunicaciones de la ACM. 24 2). ACM: 75–83. doi:10.1145/358549.358561. S2CID 97895. Retrieved 25 de noviembre 2019.
  16. ^ Sommerville, Ian (2004). Ingeniería de software (Seventh ed.). Pearson. pp. 242–243. ISBN 0-321-21026-3.
  17. ^ Mayer, Herbert (1989). Programación avanzada C en el PC IBM. Libros Windcrest. p. xii (prefacio). ISBN 0830693637.
  18. ^ Meek, Brian; Heath, Patricia (1980), Guía de buenas prácticas de programación, Ellis Horwood, Wiley, p. 37
  19. ^ a b McConnell, Steve (2004). Código completo (Segunda edición). Microsoft Press. p. 70. ISBN 0-7356-1967-0.
  20. ^ Roedy Green. "código inmantenible: Glosario de Java". Retrieved 2013-11-26.
  21. ^ Múltiplo (wiki). "Las mejores prácticas". Docforge. Retrieved 2012-11-13.
  22. ^ "Single-Point-of-Definition by Ejemplo". Retrieved 2015-11-30. No repitas nada. Objetivo para un punto único de definición para cada aspecto de su aplicación [...]'.
  23. ^ "7 Aplicación Implementación Mejores Prácticas - Done Devops". dzone.com.
  24. ^ "Los siete pecados mortales del despliegue de software [LWN.net]". lwn.net.
  25. ^ blog.fortrabbit.com/multi-stage-deployment-for-website-development
  26. ^ Cruz, Victor (3 de abril de 2013). "Por qué el 30% de los implementos de App fallan". Wired – vía www.wired.com.
  27. ^ "Las reglas del despliegue de software". Archivado desde el original el 2010-05-13.
  28. ^ "Herramientas que necesitas para acelerar el despliegue a la demanda de partido". 3 de febrero de 2017.
  29. ^ Ankerholz, Amber (14 de septiembre de 2016). "DevOps and the Art of Secure Application Deployment".
  30. ^ "Organización de implementos de software a las condiciones de fracaso coinciden". Amazon Web Services. 5 de mayo de 2014.
  31. ^ "Las mejores prácticas para el despliegue libre de riesgos". TheServerSide.com.
  32. ^ Ambler, Scott. "Effective Software Deployment". Dr. Dobb's.
  33. ^ "Enterprise application deployment: The humanity of software implementation". Archivado desde el original el 2016-08-21.
  34. ^ "Tener burocracia: mejorar la contratación y la implementación de software Silencio 18F: Entrega de servicios digitales". 18f.gsa.gov14 de mayo de 2014.
  35. ^ "Un mal despliegue de software es peor que hacer nada". Intact Technology. 1 de junio de 2016.
  36. ^ Davis, Alan Mark. (1995). 201 principios del desarrollo de programas informáticos. Nueva York: McGraw-Hill. ISBN 0-07-015840-1. OCLC 31814837
  37. ^ Johnson, Pontus; Ekstedt, Mathias; Jacobson, Ivar (2012). "¿Dónde está la Teoría para la Ingeniería del Software?". IEEE Software. 29 (5): 96. doi:10.1109/MS.2012.127. ISSN 0740-7459. S2CID 38239662.
  38. ^ Krug, Steve (2014). No me hagas pensar, revisitado: un enfoque de sentido común a la usabilidad web. Bayle, Elisabeth, Straiger, Aren, Matcho, Mark (Third ed.). [San Francisco, California]. ISBN 978-0-321-96551-6 OCLC 859556499.{{cite book}}: CS1 maint: localización desaparecido editor (link)
  • Harbison, Samuel P.; Steele, Guy L. (2002). C - Manual de referencia. ISBN 978-0-13-089592-9.
  • Mejorando el Ciclo de Vida para el Desarrollo al Software Seguro de Producto, V2.0 Oct. 2008 describe los principios y prácticas de seguridad que los desarrolladores de software, probadores e integradores pueden adoptar para alcanzar los objetivos gemelos de producir sistemas de software más seguros y verificar la seguridad del software que producen.
  • Dutta, Shiv; Hook, Gary (26 de junio de 2003). "Las mejores prácticas para la programación en C". developerWorks. IBM. Archivado desde el original el 13 de julio de 2009. Retrieved 21 de enero 2010.
  • Paul Burden, coautor de las normas de codificación MISRA C y representante de PRQA en el grupo de trabajo MISRA C durante más de 10 años, discute una falacia común de codificación: "¡No necesitamos un estándar de codificación!, ¡tenemos que atrapar errores!"
Más resultados...
Te puede interesar
Tamaño del texto:
undoredo
format_boldformat_italicformat_underlinedstrikethrough_ssuperscriptsubscriptlink
save
cancelcheck_circle