Compartir a través de

Legibilidad del código

Convenciones de nomenclatura

Convenciones de nomenclatura generales

Esta sección describe las convenciones de nomenclatura "camel case" y "Pascal case". Si ya está familiarizado con esos términos, puede seguir adelante.

Notación camello

Debe usar camel case para controles y variables. Camel case comienza con un prefijo en minúscula, elimina todos los espacios de los nombres de objetos o variables y escribe en mayúscula la primera letra de cada palabra después de la primera. Por ejemplo, un control de entrada de texto podría denominarse txtUserEmailAddress.

Notación Pascal

Debe utilizar Pascal case para el origen de datos. El caso de Pascal a veces se conoce como "notación camel superior". Al igual que la notación camel, elimina todos los espacios y pone en mayúscula la primera letra de las palabras. Sin embargo, a diferencia de camel case, Pascal case también escribe con mayúscula la primera palabra. Por ejemplo, un origen de datos común en PowerApps es el conector de usuarios de Microsoft Office 365, que en su código se denomina Office365Users.

Nombres de pantalla

Los nombres de pantalla deben reflejar el propósito de la pantalla, para que sea más fácil navegar a través de aplicaciones complejas Power Apps Studio.

Lo que es menos obvio es que los lectores de pantalla leen los nombres de pantalla en voz alta, lo que es necesario para los usuarios que tienen necesidades de accesibilidad visual. Por lo tanto, es imperativo que utilice un lenguaje sencillo para nombrar sus pantallas y que los nombres incluyan espacios y no abreviaturas. Además, le recomendamos que termine el nombre con la palabra "Pantalla", para que se entienda el contexto cuando se anuncie el nombre.

Estos son algunos buenos ejemplos:

  • Home_Screen o Home Screen
  • Search_Screen o Search Screen

Captura de pantalla que muestra una lista de nombres de pantalla que siguen el patrón descrito

Estos nombres de pantalla de ejemplo son menos comprensibles:

  • Home
  • LoaderScreen
  • EmpProfDetails
  • Thrive Help

Nombres de controles

Todos los nombres de control en el lienzo deben usar camel case. Deben comenzar con un descriptor de tipo de tres caracteres, seguido del propósito del control. Este enfoque ayuda a identificar el tipo de control y facilita la creación de fórmulas y la búsqueda. Por ejemplo, lblUserName indica que el control es una etiqueta.

La siguiente tabla muestra las abreviaturas de controles comunes.

Nombre del control Abreviatura
Notificación bdg
Button btn
Control de cámara cam
Canvas can
Card crd
Gráficos chr
Casilla de verificación chk
Colección col
Cuadro combinado cmb
Componente cmp
Contenedor con
Fechas dte
Desplegable drp
Formulario frm
Galería galón
Grupo grupo
Encabezado hdr
Texto Html htm
Icon ico
Image img
Botón de información Información de
Label lbl
Vincular enlace
Cuadro de lista lista
Micrófono mic
Microsoft Stream cadena
Forma de sección de página s
Entrada manuscrita pen
Ventana de Power BI pbi
Barra de progreso pbar
Rating rtg
Editor de texto enriquecido rte
Formas (rectángulo, círculo, etc.) shp
Slider sld
Lista de pestañas tbl
Table tbl
Entrada de texto txt
Temporizador tmr
Control de alternancia tgl
Video vid

La lista detallada de controles y sus propiedades se describen en Referencia de controles.

Nota

Los nombres de los controles deben ser únicos en una aplicación. Si un control se reutiliza en varias pantallas, el nombre corto del control debe tener un sufijo. Por ejemplo galBottomNavMenuHS, donde "HS" significa "Pantalla de inicio". Este enfoque facilita la referencia al control en fórmulas entre pantallas.

Estos son algunos malos ejemplos:

  • zipcode
  • Next

Cuando nombras constantemente tus controles, tu aplicación está más limpia en la vista de navegación y tu código también está más limpio.

Captura de pantalla de la vista de navegación que muestra los nombres de los controles siguiendo el patrón

Nombres del origen de datos

Cuando agrega un origen de datos a su aplicación, el nombre no se puede cambiar en la aplicación Power Apps. El nombre se hereda del conector de origen o de las entidades de datos que se derivan de la conexión.

Estos son algunos ejemplos:

  • Nombre heredado del conector de origen: El conector de usuarios de Office 365 se denomina Office365Users en su código.
  • Entidades de datos derivadas de la conexión: Una lista de Microsoft SharePoint llamada Employees se devuelve desde el conector SharePoint. Por lo tanto, el nombre de la fuente de datos en su código es Empleados. La misma aplicación Power Apps también puede usar el mismo conector de SharePoint para tener acceso a una lista de SharePoint denominada Contractors. En este caso, el nombre de la fuente de datos en el código es Contractors.

Para obtener más información sobre conectores y conexiones, consulte Descripción general de los conectores de la aplicación de lienzo para Power Apps.

Conectores de acciones estándar

En los conectores de acción estándar que exponen funciones, como LinkedIn, el nombre del origen de datos y sus operaciones utilizan notación Pascal. Por ejemplo, la fuente de datos de LinkedIn se denomina LinkedIn y tiene una operación denominada ListCompanies.

ClearCollect(
    colCompanies,
    LinkedIn.ListCompanies()
)

Conectores personalizados

Conectores personalizados que se utilizan para conectarse a interfaces de programación de aplicaciones (API) personalizadas, como servicios o API de línea de negocio que pueda haber creado su empresa. Pueden ser creados por cualquier creador en su entorno. Recomendamos la notación Pascal para el nombre del origen de datos y sus operaciones. Solo tenga en cuenta que el nombre del conector personalizado y la forma en que aparece en PowerApps pueden diferir.

Considere este ejemplo de un conector personalizado denominado MS Auction Item Bid API.

Captura de pantalla de un conector denominado API de oferta de artículo de subasta de MS

Pero cuando crea una conexión desde este conector y la agrega a su aplicación PowerApps como fuente de datos, aparece como AuctionItemBidAPI.

Captura de pantalla de un conector que muestra que el nombre es AuctionItemBidAPI

Para descubrir el motivo, puede buscar dentro del archivo OpenAPI un atributo de título que contenga el texto Auction Item Bid API.

"info": {
    "version": "v1",
    "title": "Auction Item Bid API"
},

Power Apps elimina todos los espacios de este valor de atributo y lo utiliza como el nombre de su fuente de datos.

Propina

Le recomendamos que cambie el valor de este atributo a un nombre en Pascal case como AuctionItemBidAPI y lo utilice como el nombre de su conexión personalizada. De esa forma no habrá confusión. Cambie este valor antes de importar el archivo OpenAPI para crear el conector personalizado.

Nota

Si utiliza la opción Crear desde un espacio en blanco en lugar de importar un archivo OpenAPI existente, PowerApps le solicitará el nombre del conector personalizado. Este nombre se utilizará como nombre del conector personalizado y como valor del atributo de título dentro del archivo OpenAPI . Asegúrese de utilizar un nombre en PascalCase como AuctionItemBidAPI para mantener las cosas consistentes y simples.

Tablas de datos de Excel

PowerApps utiliza DataTables en Microsoft Excel para conectarse a datos en hojas de cálculo de Excel. Tenga en cuenta estos puntos al crear documentos de Excel como fuentes de datos:

  • Asigne nombres descriptivos a sus Tablas de datos. El nombre está en el código que escribes para conectarte a la aplicación de Power Apps.
  • Utilice una DataTable por hoja de trabajo.
  • Asigne el mismo nombre a la tabla de datos y a la hoja de trabajo.
  • Utilice nombres de columnas descriptivos en las tablas de datos.
  • Utilice notación Pascal. Cada palabra del nombre de DataTable debe comenzar con una letra mayúscula, como por ejemplo EmployeeLeaveRequests.

Objetos sin tipo y dinámicos

Nombres de variable

Las convenciones de nomenclatura para variables en aplicaciones de lienzo son importantes para mantener la legibilidad, la coherencia y la claridad en sus proyectos de Power Apps. Si bien no se aplica un estándar estricto, adoptar una convención de nomenclatura coherente en su aplicación de lienzo puede facilitarle a usted y a otros colaboradores la comprensión, el uso y la administración de las variables.

  • Utilice camel case, donde la primera letra de cada palabra está en mayúscula excepto la primera palabra.
  • Elija nombres significativos y descriptivos que describan claramente el propósito o contenido de la variable. Evite nombres demasiado genéricos como temp o var1. En su lugar, utilice nombres descriptivos como userEmail o totalAmount.
  • Considere usar prefijos o sufijos para indicar el tipo de variable. Por ejemplo:
    • strUserName para una variable de texto/cadena
    • numTotalAmount para una variable numérica
    • boolIsEnabled para una variable booleana
    • locVarName para variables locales/variables de contexto
    • gblVarLoginUser para variables globales
  • Decida si sus variables deben nombrarse en singular o plural y respete esa convención. Por ejemplo, utilice de manera consistente userCount o usuarios.
  • Evite el uso de palabras reservadas o nombres que puedan entrar en conflicto con funciones de Power Apps o palabras clave. Consulte la documentación de Power Apps para obtener una lista de palabras reservadas.
  • Considere la posibilidad de utilizar prefijos que proporcionen contexto sobre el uso o alcance de la variable. Por ejemplo:
    • frm para variables de formularios
    • col para recopilaciones
    • var para variables de propósito general
  • Evite los caracteres especiales. Mantenga los nombres alfanuméricos y evite caracteres especiales o espacios. Limítese a letras y números.

Power Apps permite que las variables de contexto y las variables globales compartan los mismos nombres Esto puede causar confusión porque sus fórmulas usan variables de contexto de forma predeterminada a menos que se use el operador de desambiguación .

Evite esta situación siguiendo estas convenciones:

  • Prefije las variables de contexto con loc.
  • Prefije las variables globales con gbl.
  • El nombre después del prefijo debe indicar la intención/propósito de la variable. Se pueden usar varias palabras y no es necesario que estén separadas por caracteres especiales, como espacios o guiones bajos, si la primera letra de cada palabra está en mayúscula.
  • Utilice notación CamelCase. Comience los nombres de sus variables con un prefijo en letras minúsculas y luego escriba en mayúscula la primera letra de cada palabra del nombre.

Estos ejemplos siguen estándares y convenciones:

  • Variable global:gblFocusedBorderColor

  • Variable de contexto:locSuccessMessage

  • Variable de ámbito:scpRadius

Estos ejemplos no siguen los estándares y son más difíciles de entender:

  • dSub
  • rstFlds
  • hideNxtBtn
  • ttlOppCt
  • cFV
  • cQId

Evite nombres de variables cortos y crípticos como EID. Use EmployeeId en su lugar.

Cuando hay muchas variables en una aplicación, puede simplemente escribir el prefijo en la barra de fórmulas para ver una lista de las variables disponibles. Si sigue estas pautas para nombrar sus variables, podrá encontrarlas fácilmente en la barra de fórmulas a medida que desarrolle su aplicación. En última instancia, este enfoque conduce a un desarrollo de aplicaciones más rápido.

Nombres de colección

  • Sea descriptivo del contenido de la colección. Piensa en lo que contiene la colección y/o cómo se utiliza, y luego nómbrala en consecuencia.
  • Las colecciones deben tener el prefijo con col.
  • El nombre después del prefijo debe indicar la intención o propósito de la colección. Se pueden usar varias palabras y no es necesario que estén separadas por espacios o guiones bajos, si la primera letra de cada palabra está en mayúsculas.
  • Utilice notación CamelCase. Comience los nombres de su colección con un prefijo col en minúscula y luego escriba en mayúscula la primera letra de cada palabra del nombre.

Estos ejemplos siguen las convenciones de nombres de colecciones:

  • colMenuItems
  • colThriveApps

Estos ejemplos no siguen las convenciones de nombres de colecciones:

  • orderscoll
  • tempCollection

Propina

Cuando hay muchas colecciones en la aplicación, puedes simplemente escribir el prefijo en la barra de fórmulas para ver una lista de las colecciones disponibles. En cuanto a las variables, si sigues estas pautas para nombrar tus colecciones, podrás encontrarlas muy fácilmente en la barra de fórmulas a medida que desarrolles tu aplicación. En última instancia, este enfoque conduce a un desarrollo de aplicaciones más rápido.

Comentarios y documentación

Mientras escribe código para su aplicación, enfatice la importancia de realizar comentarios completos. Estos comentarios no solo le servirán de guía cuando vuelva a visitar la aplicación meses después, sino que también supondrán un gesto de gratitud hacia el próximo desarrollador que colabore en el proyecto.

Hay dos tipos principales de comentarios para mejorar la claridad del código: Power Apps admite dos estilos de comentarios: comentarios de línea, indicados por barras dobles (//) para comentarios de una sola línea, y comentarios de bloque entre /* y */ para anotaciones de varias líneas.

Comentarios en línea

Agregar una doble barra diagonal (//) a cualquier línea de código en PowerApps designa el resto de la línea (incluido //) como un comentario.

Utilice comentarios de línea para explicar la funcionalidad del código siguiente. También pueden servir para deshabilitar temporalmente una línea de código, lo que los hace beneficiosos para fines de prueba.

Este ejemplo muestra el uso de comentarios de línea.

// ClearCollect function populates the Expenses2 collection with sample data
ClearCollect(
    Expenses2,
    // Entry 1: Client hosted meet and greet
    {
        Title: "Client hosted meet and greet:",
        ID: "4"
        // additional properties  
    }
)

Comentarios de bloque

El texto incluido entre /* y */ se reconoce como un comentario de bloque. A diferencia de los comentarios de línea que se aplican a una sola línea, los comentarios de bloque pueden abarcar varias líneas.

Los comentarios de bloque son útiles para explicaciones de varias líneas, como documentar el encabezado de un módulo de código. También facilitan la desactivación temporal de varias líneas de código durante las pruebas o la depuración.

Para una organización óptima del código, es recomendable agregar comentarios después de utilizar la función Formatear texto. Esto es beneficioso si sus comentarios preceden a un bloque de código.

/*
    Patch Operation to Insert Data:
    - Inserts a new employee record into the 'Employee' entity.
    - Adds corresponding department details to the 'Department' entity.
    Note: Ensure that foreign key relationships and dependencies are maintained for data integrity.
*/
Patch(
    Employee,
    Defaults(Employee),
    {
        FirstName: "John",
        LastName: "Doe",
        Position: "Software Developer"
    }
)

La función Formatear texto sigue estas reglas para los comentarios existentes:

  1. Si una propiedad comienza con un comentario de bloque, se le agregará la siguiente línea de código.
  2. Si una propiedad comienza con un comentario de línea, no se le agregará la siguiente línea de código. De lo contrario, el código queda comentado.
  3. Los comentarios de línea y bloque en otras partes de la propiedad se agregarán a la línea de código anterior.

No se preocupe por agregar demasiados comentarios o comentarios que sean demasiado largos. Todos los comentarios se eliminan cuando PowerApps crea el paquete de la aplicación cliente. Por lo tanto, no afectarán el tamaño del paquete ni ralentizarán los tiempos de descarga o carga de la aplicación.

Diseñador de aplicaciones moderno con comentarios.

En Power Apps, se considera la mejor práctica para los creadores utilizar de manera efectiva las funciones de comentarios tanto en Power Apps Studio como en el diseñador de aplicaciones moderno.

Para una participación óptima en Power Apps Studio, se recomienda a los creadores agregar comentarios utilizando los siguientes métodos:

  1. Haga clic derecho en los puntos suspensivos ("...") de cualquier elemento en la vista de árbol.
  2. Haga clic derecho en un componente en el área del lienzo.
  3. Seleccione el botón "Comentarios" situado en la barra de comandos de la esquina superior derecha de la pantalla.

Al mencionar a colegas en los comentarios, se recomienda utilizar el símbolo "@" seguido de su nombre. Esto genera un correo electrónico de notificación para el colega etiquetado, lo que garantiza un acceso rápido al comentario. En los casos en que un usuario etiquetado no tenga acceso a la aplicación, se le solicitará al creador que comparta la aplicación con esta persona.

Una captura de pantalla de una aplicación de gastos que muestra a una persona @ mencionada en el comentario

Sangría y formato

En Power Apps, la sangría y el formato son cruciales para mantener una estructura clara y organizada en su aplicación. Seguir las mejores prácticas mejora la legibilidad de sus fórmulas y controles.

Barra de fórmulas

Sangría

Aunque Power Apps no impone una sangría estricta, puede usar espacios para separar visualmente diferentes secciones de sus fórmulas. Presione la barra espaciadora varias veces para crear un efecto de sangría.

Saltos de línea

Puede dividir fórmulas largas en varias líneas para mejorar la legibilidad. Presione Intro para crear un salto de línea dentro de la barra de fórmulas.

Utilice el comando Formatear texto

El comando "Formatear texto" en la barra de fórmulas está diseñado para aplicar sangría, espaciado y saltos de línea a su código de Power Apps. Utilice el comando "Formatear texto" para establecer un estilo de codificación uniforme en toda su aplicación de lienzo, lo que garantiza un proceso de desarrollo más eficiente y resistente a errores.

Captura de pantalla del Power Apps Studio con el comando Formatear texto resaltado

Siguiente paso

Optimización de código