Formateo del módulo

Plataforma 1C:Enterprise >> Preguntas frecuentes >> Desarrollo

   

Formato del módulo

Nombres de procedimientos y funciones

Este artículo describe los estándares que se aplican a los nombres de procedimientos y funciones. Todas las recomendaciones enumeradas son obligatorias a menos que se indique lo contrario.

1. El nombramiento adecuado de procedimientos y funciones es muy importante porque hace que el código sea más fácil de leer. En la mayoría de los casos, un buen nombre de procedimiento combinado con nombres de parámetros adecuadamente seleccionados eliminará la necesidad de describir aún más el procedimiento. En algunas situaciones, las dificultades para seleccionar nombres para un procedimiento y/o sus parámetros revelan una arquitectura de código de programación deficiente. Lo contrario también es cierto: si es fácil encontrar un nombre “autoexplicativo”, entonces el procedimiento ha sido diseñado correctamente.

Ver también: Descripciones de procedimientos y funciones

2. Los parámetros, funciones y parámetros formales deben tener nombres basados en los términos del área temática para que el nombre aclare el propósito. Trate de hacer que los nombres sean “autoexplicativos”.
Incorrecto:

Function Check(Parameter1, Attr, TS)
Function GetAttributeArrays(BusinessTransaction, AllAttributesArray, TransactionAttributesArray)

Correcto:

Function SpecifiedObjectTypeAttribute(Object, AttributeName, ValueType)
Function FillAttributeNamesByBusinessOperation(BusinessOperation, AllAttributeNames, OperationAttributeNames)

3. Los nombres deben generarse eliminando los espacios que separan las palabras. Tenga en cuenta que cada palabra en el nombre debe estar en mayúscula. Las preposiciones y pronombres que consisten en una sola letra también se escriben en mayúscula.

Esta recomendación es opcional

4. Recomendamos que no describa los tipos de parámetros aceptados y/o valores devueltos en los nombres de procedimientos y funciones.

 

Incorrecto:

Function GetArrayOfRolesWithAddRight()
Function GetAggitionalSettingsStructure()

Correcto:

Function NamesOfRolesWithAddRight()
Function AdditionalSettings()

Esta recomendación funciona en la mayoría de las situaciones, con solo algunas excepciones cuando, sin el tipo de valor devuelto, el propósito del procedimiento o función en sí no está claro.

 

5. En general, los nombres de los procedimientos deben basarse en el infinitivo del verbo que especifica la esencia de la acción que ejecutan.

 

Incorrecto:

Procedure CounterpartyLoading()

 

Correcto:

Procedure LoadCounterparty()

 

6.1. En general, los nombres de las funciones deben basarse en una descripción del valor devuelto.

 

Incorrecto:

Function GetFullUserName()
Function CreateVendorPriceFillingParameters() 
Function DefineSessionStartDate()

Correcto:

Function FullUserName()
Function NewVendorPriceFillingParameters()
Function SessionStartDate()

6.2. Si una función está destinada a crear un objeto, recomendamos usar “New” en su nombre.

 

Incorrecto:

Function AddFormField()
Function CreateFilesCatalogItem()
Function GetCommandTable()

Correcto:

Function NewFormField()
Function NewFilesCatalogItem()
Function NewCommandTable()

6.3. Si una función verifica una condición particular, recomendamos comenzar su nombre con “Is” o usar el participio II.

 

Incorrecto:

Function CheckIfDocumentIsPosted()
Function CheckIfDocumentAttributesChanged()
Function ExternalTask()

Correcto:

Function DocumentPosted()
Function DocumentAttributedModified()
Function IsExternalTask()

6.4. Recomendamos usar infinitivos en los nombres de las funciones cuando se debe saber cómo se produjo el valor devuelto para comprender el propósito de la función. Ejemplos:

Function SelectDataByRule(Rule, UserSettings)
Function ConvertDataByRule(DataSets, ConversionParameters)

6.5. Si ejecutar una función implica principalmente realizar una acción y devolver un valor no es su objetivo principal (por ejemplo, sirve para mostrar que una acción se ha ejecutado correctamente), dichas funciones deben tener nombres basados en infinitivos, y lo mismo ocurre con los procedimientos.

 

Ejemplo:

Function AllowEditingObjectAttributes(Form)

Descripciones de procedimientos y funciones

Este artículo describe los estándares que se aplican a las descripciones de procedimientos y funciones. Todas las recomendaciones enumeradas son obligatorias a menos que se indique lo contrario.

1. Describa procedimientos y funciones agregando comentarios a los elementos respectivos. El desarrollador es libre de decidir si se deben comentar porciones específicas del código de procedimientos y funciones en función de su complejidad y singularidad.

En 1C:Enterprise versión 8.3, el texto del comentario se muestra en las descripciones emergentes de procedimientos, funciones y sus parámetros. Para obtener más información, consulte la sección “Consejos de contexto durante la entrada de texto del módulo” en el capítulo 26 “Herramientas de desarrollo” de Guía del desarrollador de 1C:Enterprise.

2. Los procedimientos y funciones que pertenecen a la interfaz del programa de los módulos deben tener comentarios. Dichos procedimientos y funciones están destinados a ser utilizados en otros subsistemas funcionales (o en otras aplicaciones) que podrían estar dentro del alcance de responsabilidad de otros desarrolladores, por lo que deben estar debidamente documentados.

Esta recomendación es opcional

3. Recomendamos que agregue comentarios a otras procedimientos y funciones (incluyendo controladores de eventos pertenecientes a módulos de formulario, módulos de objeto, módulos de conjunto de registros, módulos de administrador de valores, etc.) cuando sea necesario explicar el propósito de un procedimiento o función o las especificidades de su funcionamiento. También recomendamos que describa por qué un procedimiento o función no realiza ciertas acciones cuando se espera que se realicen.

Sin embargo, no es necesario agregar un comentario si un procedimiento o función no es difícil de entender y su propósito y funcionamiento son claros a partir de su nombre y los nombres de sus parámetros.

4. Evite comentarios que no proporcionen ninguna explicación adicional con respecto al funcionamiento de un procedimiento o función no exportable.

Ejemplos de comentarios incorrectos:

// Controlador del evento de formulario "OnOpen"
// &AtClient
Procedure OnOpen()
// Controlador del comando "Calculate"
// &AtClient 
Procedure Calculate()
// Controlador del evento "OnChange" del elemento de formulario "EditInDialogOnly"
// &AtClient
Procedure EditInDialogOnlyOnChange(Item)

En estos ejemplos, los comentarios son redundantes porque los nombres de los procedimientos implican que los procedimientos son controladores de eventos. Sus descripciones y propósitos de parámetros están disponibles en el Asistente de Sintaxis.

// La función devuelve un elemento de flujo de efectivo basado en los datos del documento
Function CashFlowItem(DocumentData)

Este comentario no proporciona ninguna información nueva sobre la función.

5. Agregue sus comentarios antes de la declaración del procedimiento o función y formatee como sigue:

5.1. Sección de descripción. Una breve descripción verbal del propósito y/o funcionamiento del procedimiento o función. Es la única sección para procedimientos sin parámetros.

Ejemplo:

// Define la disponibilidad de los roles RoleNames para el usuario actual,
// así como la disponibilidad de derechos de administrador.

5.2. Sección de parámetros. Describe parámetros de procedimientos o funciones. Omita esta sección si no hay parámetros. Anteceda la sección con la línea “Parámetros:”.

5.2.1. La descripción del parámetro comienza en una nueva línea. La línea tiene el siguiente formato: el nombre del parámetro, un guión, la lista de tipos star, un guión y la descripción del parámetro.

Ejemplo:

// Parámetros:
// RoleNames - String - nombres separados por comas de los roles cuya disponibilidad se verifica.

5.2.2. Para parámetros de tipo Estructura y Tabla de valores, agregue las descripciones de sus propiedades y columnas, cada una comenzando en una nueva línea y precedida por * (asterisco).
Ejemplo:

// Parámetros:
//   SeriesStatuses - ValueTable - una tabla de valores con las siguientes columnas:
//     * Series - CatalogRef.ItemSeries - si se especifica una serie y no se puede usar
                  con un nuevo valor de artículo en el almacén especificado, devuelve el valor pasado;
                  de lo contrario, devuelve una cadena vacía.
//     * SeriesAvailabilityStatus - Number - si las series están listadas en la sección tabular de Artículos,
                  devuelve el estado calculado; si el artículo o almacén pasado no utiliza
                  series, devuelve 0; de lo contrario, devuelve el estado pasado.
// SeriesAvailabilityParameters - Structure - ver ItemsClientServer.SeriesAvailabilityParameters

Lo mismo es válido para parámetros de tipo Array:

// Parámetros:
//   UpdateInfo - Array - contiene estructuras con las siguientes propiedades:
//     * AddressObjectCode - String  - código del objeto de dirección.
//     * Description       - String  - descripción del objeto de dirección.
//     * Index             - String  - índice del objeto de dirección.
//     * UpdateAvailable   - Boolean - muestra si hay una actualización disponible.
//

Las descripciones de arrays, estructuras y tablas de valores pueden tener descripciones anidadas. Cada nivel de anidamiento aumenta el número de asteriscos antes del nombre de la propiedad: 2 asteriscos para el primer nivel anidado, 3 para el segundo nivel anidado, y así sucesivamente.

// Parámetros:
//   UpdateInfo - Array - contiene estructuras con las siguientes propiedades:
//     * AddressObjectCode - String  - código del objeto de dirección.
//       ** RegionCode          - Number - código de región (2 caracteres).
//       ** TownCode            - Number - código de ciudad (3 caracteres).
//       ** StreetCode          - Number - código de calle (4 caracteres).
//     * Description       - String  - descripción del objeto de dirección.
//     * UpdateAvailable   - Boolean - indica si hay una actualización disponible.
//

5.2.3. Para cada parámetro, puedes especificar una o varias descripciones adicionales de tipo de parámetro, cada una comenzando en una nueva línea. Las líneas tienen el siguiente formato: un guión, una lista de tipos de parámetro star, un guión y la descripción del tipo.
Ejemplo:

// Parámetros:
//   Attributes - String - nombres de atributos, separados por comas.
//                         Ejemplo: "Código, Descripción, Padre".
//              - Structure, FixedStructure - la clave es el alias del campo en la 
//                                            estructura devuelta (que contiene el resultado);
//                                            el valor (opcional) es el nombre real del campo 
//                                            en la tabla.

//                                            Si no se define el valor, se toma el nombre del campo
//                                            de la clave.
//              - Array, FixedArray - array de nombres de atributos.

5.3. Sección de valor de retorno. Describe el contenido y el tipo del valor de retorno de una función. Omite esta sección para procedimientos. Precede la sección con la línea “Devuelve:”. La siguiente línea tiene el siguiente formato: la lista de tipos star, un guión y la descripción del valor de retorno.
Ejemplo:

// Devuelve:
// Boolean - Verdadero si al menos uno de los roles pasados está disponible para el usuario actual o el
//           usuario actual tiene derechos administrativos.

Los párrafos 5.2.2 y 5.2.3 también se aplican a la sección de valor de retorno.

5.4. Sección de ejemplo. Proporciona un ejemplo de uso de un procedimiento o función. Precede la sección con la línea “Ejemplo:”.

5.5. En escenarios raros donde varios parámetros tienen tipos adicionales, agrega la sección Opciones de llamada, que describe las opciones de llamada con varias combinaciones de tipos de parámetros (puedes describir todas las opciones de llamada disponibles o solo las más populares). Precede la sección con la línea “Opciones de llamada:”. Luego proporciona las descripciones de las opciones, cada una en una nueva línea. Las descripciones de las opciones tienen el siguiente formato:
el nombre de la función con sus parámetros entre paréntesis, un guión y una descripción de la opción de llamada.

Ejemplo:

// ...
//
// Parámetros:
// Parámetro1 - Tipo11, Tipo12 - ...
// Parámetro2 - Tipo21, Tipo22, Tipo23 - ...
//
// Opciones de llamada:
// ProcedimientoUniversal(Tipo11, Tipo21) - descripción ...
// ProcedimientoUniversal(Tipo12, Tipo22) - descripción ...
// ProcedimientoUniversal(Tipo11, Tipo23) - descripción ...
//
Procedimiento ProcedimientoUniversal(Parámetro1, Parámetro2) Exportar

5.6. Recomendamos utilizar hipervínculos para cambiar rápidamente a otros objetos de configuración, módulos, procedimientos, funciones y descripciones del asistente de sintaxis de tipos, objetos y métodos de la plataforma. En particular, utiliza hipervínculos para cambiar a funciones constructoras de estructuras.

Precede un hipervínculo con “ver”, “ver procedimiento”, “ver función” o “ver tipo”, luego proporciona un nombre. Un nombre puede ser simple (una palabra) o complejo (varias palabras separadas por puntos).

5.6.1. Encierra las descripciones de los hipervínculos entre paréntesis:

// Parámetros:
// SeriesStatuses - ValueTable - una tabla de valores con las siguientes columnas (ver función SeriesClientServer.SeriesStatuses)

5.6.2. Si toda la descripción es un hipervínculo, omite los paréntesis:

// Parámetros:
// SeriesAvailabilityParameters - Structure - ver ItemsClientServer.SeriesAvailabilityParameters

5.7. Para marcar un procedimiento o función como obsoleto, agrega “Obsoleto” a la primera línea de su descripción.
Ejemplo:

// Obsoleto. Utiliza la nueva función (ver CommonUse.RoleAvailable)
// ... 
Función RolesAvailable(NombresDeRoles) Exportar

6. Si necesita agregar un comentario a un procedimiento o una función que se utiliza con una directiva de compilación, agregue el comentario antes de la directiva de compilación. Ejemplo:

// Procedimiento: controlador del evento "OnCreateAtServer" de un formulario.
// Procesa los parámetros del formulario y completa los valores de los atributos del formulario.
// También ejecuta las siguientes acciones:
// ...
//
&AtClient
Procedimiento OnCreateAtServer(Cancelar, ProcesamientoEstándar)

Este enfoque de comentarios llama la atención primero sobre la definición de la función y la directiva de compilación, y luego sobre el comentario (que puede tener varias líneas).

7. En el texto del módulo, separe los códigos de los procedimientos y funciones con líneas vacías.

star Nota. Una lista de tipos consiste en nombres de tipos separados por comas. Un nombre de tipo puede ser simple (una palabra) o complejo (dos palabras separadas por un punto).
Ejemplo: Cadena, Estructura, CatalogoRef.Empleados.

Ejemplos de descripciones de procedimientos y funciones

Ejemplo de una función con un solo parámetro:

// Define la disponibilidad de los roles RoleNames para el usuario actual,
// así como la disponibilidad de derechos de administrador.
//
// Parámetros:
// RoleNames – Cadena – nombres de roles separados por comas cuya disponibilidad se verifica.
//
// Devuelve:
// Booleano – Verdadero si al menos uno de los roles pasados está disponible para el usuario actual o el
//           usuario actual tiene derechos de administrador.
//
// Ejemplo:
// Si RolesDisponibles(“UsarListasEnvioReportes,EnviarCorreo”) Entonces …
//
Función RolesDisponibles(RoleNames) Exportar

Ejemplo de un procedimiento sin parámetros:

// El controlador BeforeWrite de un documento incluye las siguientes acciones:
// – borrar la sección tabular de servicio si se especifica el contrato del consignador;
// – verificar si el atributo UnidadDeMedida de la sección tabular de Artículos está completo;
// – sincronizar los datos de la sección tabular de artículos con una factura de venta vinculada;
// – completar las secciones tabulares de Almacén y PedidoCliente en Artículos y Vacíos;
// – eliminar filas no completadas de la sección tabular “Números de serie”;
// – completar la variable DeleteRegisterRecords del módulo de objeto.
//
Procedimiento BeforeWrite()
FinProcedimiento

Comentarios de autoordenación para procedimientos y funciones con directivas de compilación

Puede utilizar el procesador de datos FormatProcedureComments.epf para mover los comentarios de procedimientos o funciones al área antes de la directiva de compilación.

  1. Volcar la configuración a archivos (en el menú Configuración, haga clic en Volcar archivos de configuración).
  2. Abrir el procesador de datos en el modo 1C:Enterprise, seleccionar el directorio que almacena los archivos volcados y hacer clic en Formatear.
  3. Cargar los módulos nuevamente en la configuración (en el menú Configuración, haga clic en Restaurar configuración desde archivos).

Consideraciones sobre el uso de estructuras como parámetros de procedimientos y funciones

Artículo principal: Parámetros de procedimientos y funciones 

Cuando se trabaja con procedimientos y funciones (a los que nos referiremos como funciones en adelante) que tienen parámetros del tipo Estructura, recomendamos seguir el enfoque de desarrollo descrito a continuación.

1. Además de la función que implementa la funcionalidad de la aplicación (la función que se llama), defina una función constructora para crear una estructura (el constructor de parámetros). En este caso, la función constructora no acepta ningún parámetro y solo devuelve una estructura en blanco con propiedades. El código que llama a la función inicializa la estructura con valores específicos y luego la pasa a la función que se llama.

Código de ejemplo que llama a la función:

Procedimiento OnItemChangeServer(IDFilaActual)

// Obteniendo nueva estructura de parámetros.
ParametrosRellenadoPrecio = PricingClientServer.TSRowPriceFillingParameters(); 

// Rellenando parámetros.
ParametrosRellenadoPrecio.Fecha = Objeto.Fecha;
ParametrosRellenadoPrecio.Moneda = Objeto.Moneda;

FilaActual = Objeto.Items.EncontrarPorID(IDFilaActual);

// Pasando la estructura de parámetros a la función aplicada.
PricingServer.RellenarPreciosEnTSRow(FilaActual, ParametrosRellenadoPrecio);

Ejemplo de función constructora de parámetros en el módulo PricingClientServer:

Función TSRowPriceFillingParameters() Exportar
 
 ParametrosRellenadoPrecio = Nueva Estructura;
 ParametrosRellenadoPrecio.Insertar("Fecha");
 ParametrosRellenadoPrecio.Insertar("Moneda");
 ParametrosRellenadoPrecio.Insertar("RecalcularMonto", Verdadero);
 ParametrosRellenadoPrecio.Insertar("ParámetrosRequeridos","Fecha,Moneda"); // parámetros requeridos que deben ser llenados
 Devolver ParametrosRellenadoPrecio;
 
FinFunción

Los nombres de las propiedades de la estructura corresponden a los parámetros de la función llamada. Tenga en cuenta que cualquier parámetro con valores predeterminados debe inicializarse explícitamente en esta estructura.

2. No agregue ninguna otra propiedad a la estructura de parámetros en el código de llamada. Para evitar ambigüedad y errores ocultos, todos los parámetros válidos de la función llamada deben definirse explícitamente en la función constructora de parámetros.

Parámetros de procedimientos y funciones

Este artículo describe los estándares que se aplican a los parámetros de procedimientos y funciones. Todas las recomendaciones enumeradas son obligatorias a menos que se indique lo contrario.

1. Al declarar los parámetros formales de los procedimientos y funciones (en adelante denominados funciones), siga las reglas generales de nomenclatura de variables. En particular, los nombres de los parámetros deben basarse en los términos del área temática para que el nombre del parámetro describa claramente su propósito.

2. No utilice otros parámetros de configuración (variables de módulo, atributos de formulario, etc.) en lugar de los parámetros de función.

3.1. Los parámetros de función deben ordenarse de manera razonable. Se recomienda que organice los parámetros desde los más generales hasta los más específicos.

Incorrecto:

Procedimiento RecalcularTotalDocumento(NombreCampoMonto, ObjetoDocumento, MontoIncluyeIVA = Verdadero)
Procedimiento CambiarColorCampoFormulario(Color, NombreCampo, Formulario)

Correcto:

Coloque los parámetros principales ObjetoDocumento y Formulario primero.

Procedimiento RecalcularTotalDocumento(ObjetoDocumento, NombreCampoMonto, MontoIncluyeIVA = Verdadero)
Procedimiento CambiarColorCampoFormulario(Formulario, NombreCampo, Color)

3.2. Los parámetros opcionales (aquellos que tienen valores predeterminados) deben seguir a los parámetros que no tienen valores predeterminados.

Ejemplo:

Función TasaCambioMonedaParaFecha(Moneda, Fecha = Indefinido) Exportar

4. No recomendamos declarar demasiados parámetros en funciones (evite implementar funciones con más de siete parámetros). También evite usar demasiados parámetros con valores predeterminados (recomendamos no más de tres). De lo contrario, el código que llama a la función se vuelve mucho más difícil de leer. Por ejemplo, es fácil cometer un error en el número de comas al pasar parámetros opcionales a una función.

Si necesita pasar numerosos parámetros a una función, le recomendamos que:

Incorrecto:

// Agrega un nuevo campo a un formulario e inicialízalo con valores predeterminados.
Función AgregarCampoFormulario(Nombre,
      Encabezado = Indefinido,
      ControladorCambio = "",
      ControladorInicioSelección = "",
      AnchoMargen,
      ColorFondo = Indefinido,
      ColorFondoTítulo = Indefinido,
      Padre = Indefinido,
      ImagenEncabezado = Indefinido,
      RutaDatos = Indefinido,
      CampoSoloLectura = Falso,
      VínculosParámetroElección = Indefinido)
…
FinFunción

// llamando a la función
NuevoCampo = AgregarCampoFormulario("PrecioAntiguo" + NombreColumna, NStr("es='Precio'"),,, 12, ColorFondo, ColorTítulo, NuevaCarpeta,,,Verdadero);
NuevoCampo.ColorTexto = ColoresWeb.Gris;

Correcto:

Rediseñe la lógica de la función y solo mantenga un único parámetro clave NombreCampo:

// Agrega un nuevo campo a un formulario e inicialízalo con valores predeterminados.
Función NuevoCampoFormulario(NombreCampo) 
…
FinFunción

// llamando a la función
NuevoCampo = NuevoCampoFormulario("PrecioAntiguo" + NombreColumna);
NuevoCampo.Encabezado = NStr("es='Precio'");
NuevoCampo.ColorFondo = ColorFondo;
NuevoCampo.ColorTexto = WebColors.Gris;
NuevoCampo.… = …
…

Incorrecto:

// Crea un elemento en el catálogo "Artículos"
Procedimiento CrearElementoArtículos(Descripción, ServicioProducto, UnidadMedida, PesoNeto, VerificarUnicidad = Verdadero)
…
FinProcedimiento

Correcto:

Combina los parámetros que describen los valores de los atributos del producto en una estructura llamada ValoresAtributo:

// Crea un elemento en el catálogo "Artículos"
Procedimiento CrearElementoArtículos(ValoresAtributo, VerificarUnicidad = Verdadero)
…
FinProcedimiento

5. Cuando llames a funciones, evita estructuras voluminosas, que hacen que el código sea más difícil de entender, aumentan el riesgo de errores y dificultan la depuración.

5.1. Cuando pases parámetros a una función, se recomienda que no uses llamadas anidadas de otras funciones.

Incorrecto:

EstructuraAdjuntos.Insertar(
  ArchivoAdjunto.Descripción,
  Nueva Imagen(ObtenerDesdeAlmacenamientoTemporal(
  ArchivosAdjuntos.ObtenerDatosArchivo(ArchivoAdjunto.Ref).RefDatosBinariosArchivo)));

Correcto:

Divide esas llamadas en declaraciones separadas y usa variables locales auxiliares:

DirecciónArchivoImagen = ArchivosAdjuntos.ObtenerDatosArchivo(ArchivoAdjunto.Ref).RefDatosBinariosArchivo;
DatosImagen = Nueva Imagen(ObtenerDesdeAlmacenamientoTemporal(DirecciónArchivoImagen));
EstructuraAdjuntos.Insertar(ArchivoAdjunto.Descripción, DatosImagen);

Ten en cuenta que cuando el código que contiene llamadas anidadas es compacto (es decir, no requiere que las declaraciones estén envueltas) y fácil de leer, se permiten dichas llamadas anidadas.

Ejemplo:

MostrarMensaje(NStr("es='Para realizar esta acción, debes instalar la extensión del sistema de archivos.'"));
RecalcularMontoPorTipoCambio(Monto, TasaCambioMonedaParaFecha(Moneda));

5.2. Se recomienda que no uses la construcción anidada de estructuras al llamar a funciones: Nueva Estructura(…). La declaración anidada de una estructura solo se permite cuando tiene unas pocas propiedades (apunta a un máximo de tres).

Incorrecto:

LlenarPrecios(
  Objeto.Mercancías, // Sección tabular
  , // Matriz de cadenas o estructura de filtro
  Nueva Estructura( // Parámetros de llenado
   "Fecha, Moneda, Acuerdo, CamposALlenar",
   Objeto.Fecha,
   Objeto.Moneda,
   Objeto.Acuerdo,
   "Precio, TasaIVA, TipoPrecio, FechaEntrega"
  ),
  Nueva Estructura( // Estructura de operaciones en elementos de línea modificados
   "RecalcularMonto, RecalcularMontoConIVA, RecalcularIVA, RecalcularMontoDescuentoAjustado, LimpiarDescuentoAutomático, LimpiarMontoLiquidaciónMutua",
   "CantidadPaquetes", EstructuraRecalculoMonto, EstructuraRecalculoMonto, "CantidadPaquetes", Indefinido, Indefinido
  )
 );

Correcto:

ParámetrosLlenado = Nueva Estructura; 
ParámetrosLlenado.Insertar("Fecha", Objeto.Fecha); 
ParámetrosLlenado.Insertar("Moneda", Objeto.Moneda); 
ParámetrosLlenado.Insertar("Acuerdo", Objeto.Acuerdo); 
ParámetrosLlenado.Insertar("CamposALlenar", "Precio, TasaIVA, TipoPrecio, FechaEntrega");

AccionesEnFilasModificadas = Nueva Estructura; 
AccionesEnFilasModificadas.Insertar("RecalcularMonto","CantidadPaquetes"); 
AccionesEnFilasModificadas.Insertar("RecalcularMontoConIVA", ParámetrosRecalculoMonto); 
AccionesEnFilasModificadas.Insertar("RecalcularIVA", ParámetrosRecalculoMonto); 
AccionesEnFilasModificadas.Insertar("RecalcularMontoDescuentoAjustado","CantidadPaquetes"); 
AccionesEnFilasModificadas.Insertar("LimpiarDescuentoAutomático"); 
AccionesEnFilasModificadas.Insertar("LimpiarMontoLiquidaciónMutua"); 
LlenarPrecios(Objeto.Artículos, ParámetrosLlenado, AccionesEnFilasModificadas);

Consultar también:

Reglas para nombrar variables

Este artículo describe los estándares que se aplican a los nombres de variables. Todas las recomendaciones mencionadas son obligatorias a menos que se indique lo contrario.

1. Nombra tus variables en función de los términos del área temática, de modo que el nombre de la variable describa claramente su propósito.

2. Crea nombres de variables eliminando los espacios que separan las palabras. Capitaliza cada palabra en el nombre, incluyendo preposiciones y pronombres que consisten en una sola letra.

Ejemplo:

Variable DirectoryProcessingDialog; // Diálogo para trabajar con un directorio
Variable PacksInBoxQuantity; // Número de paquetes en una caja

Ejemplos de nombres de variables incorrectos:

maxAttributes, matchTypeName, newStr

3. No comience los nombres de las variables con un guión bajo.

4. No utilice nombres de variables que consistan en un solo carácter. Los nombres de variables cortos solo están permitidos para contadores de bucles.

5. Nombre las variables que describen estados binarios (“true” o “false”) después del estado que coincide con el valor “true”.

Ejemplo:

Variable HasErrors; // Muestra si el procedimiento contiene errores.
Variable IsReusableContainer; // Muestra si un producto es un contenedor reutilizable.

Consulte también:

Estructura del módulo

Este artículo describe los estándares que se aplican a la estructura del módulo. Todas las recomendaciones enumeradas son obligatorias a menos que se indique lo contrario.

1.1. Un módulo de programa (módulo común, módulo de objeto, módulo de administrador de objetos, módulo de formulario, módulo de comando, etc.) puede tener las siguientes secciones ordenadas como se indica a continuación:

Algunas secciones solo aparecen en módulos de tipos específicos. Por ejemplo, los manejadores de eventos de los elementos de formulario solo pueden existir en módulos de formulario, mientras que la descripción de variables y las secciones de inicialización no se pueden definir en módulos comunes no globales, módulos de administrador de objetos, módulos de conjunto de registros, módulos de valor constante o módulos de sesión.

Dividir el código del módulo en secciones facilita la lectura y modificación del código para diferentes autores (desarrolladores), tanto durante el desarrollo en grupo como durante la personalización de la aplicación en proyectos de implementación específicos.

1.2. Divida las secciones grandes del módulo en subsecciones según su funcionalidad.

1.3. En las configuraciones desarrolladas para la versión de plataforma 8.2 o anterior, marque las secciones y subsecciones del módulo con comentarios (consulte la descripción del formato de comentario a continuación). No hay restricciones para los nombres de sección y subsección.

En las configuraciones desarrolladas para la versión de plataforma 8.3, las secciones y subsecciones se marcan como regiones. Los nombres de las regiones deben cumplir con el Estándar de nombres de variables.

1.4. A continuación se muestra la plantilla de sección para módulos comunes. Puede copiarla libremente para usarla en sus módulos.

Para la versión de plataforma 8.2 o anterior

////////////////////////////////////////////////////////////////////////////////
// <Encabezado del módulo: una breve descripción del módulo y cuándo se utiliza.>
// 
////////////////////////////////////////////////////////////////////////////////

////////////////////////////////////////////////////////////////////////////////
// INTERFAZ

////////////////////////////////////////////////////////////////////////////////
// PROCEDIMIENTOS Y FUNCIONES INTERNOS 

Para la versión de plataforma 8.3

////////////////////////////////////////////////////////////////////////////////
// <Encabezado del módulo: una breve descripción del módulo y cuándo se utiliza.>//
////////////////////////////////////////////////////////////////////////////////

#Region Interfaz
// Código de procedimientos y funciones
#EndRegion

#Region ProcedimientosYFuncionesInternos
// Código de procedimientos y funciones
#EndRegion

Para la versión de plataforma 8.2 o anterior

////////////////////////////////////////////////////////////////////////////////
// Actualización de la infobase

Para la versión de plataforma 8.3

#Región InfobaseUpdate
// Código de procedimientos y funciones
#EndRegion

1.5. A continuación se muestra la plantilla de sección para módulos de objetos, gestores, conjuntos de registros, procesadores de datos, informes, y otros. Puedes copiarla libremente para usarla en tus propios módulos.

Para la versión de plataforma 8.2 o anterior

////////////////////////////////////////////////////////////////////////////////
// INTERFAZ

////////////////////////////////////////////////////////////////////////////////
// MANEJADORES DE EVENTOS

////////////////////////////////////////////////////////////////////////////////
// PROCEDIMIENTOS Y FUNCIONES INTERNOS

Para la versión de plataforma 8.3

#Región Interface
// Código de procedimientos y funciones
#EndRegion

#Región EventHandlers
// Código de procedimientos y funciones
#EndRegion

#Región InternalProceduresAndFunctions
// Código de procedimientos y funciones
#EndRegion

1.6. A continuación se muestra la plantilla de sección para módulos de formularios. Puedes copiarla libremente para usarla en tus propios módulos.

Para la versión de plataforma 8.2 o anterior

////////////////////////////////////////////////////////////////////////////////
// MANEJADORES DE EVENTOS DE FORMULARIOS

////////////////////////////////////////////////////////////////////////////////
// MANEJADORES DE ELEMENTOS DE ENCABEZADO DE FORMULARIOS

////////////////////////////////////////////////////////////////////////////////
// MANEJADORES DE EVENTOS DE TABLAS DE FORMULARIOS DE LA TABLA <NOMBRE DE LA TABLA>
//

////////////////////////////////////////////////////////////////////////////////
// MANEJADORES DE COMANDOS DE FORMULARIOS

////////////////////////////////////////////////////////////////////////////////
// PROCEDIMIENTOS Y FUNCIONES INTERNOS

Para la versión de plataforma 8.3

#Región FormEventHandlers
// Código de procedimientos y funciones
#EndRegion

#Región FormHeaderItemsEventHandler
// Código de procedimientos y funciones
#EndRegion

#Región FormTableEventHandlersOf<TableName>Table
// Código de procedimientos y funciones
#EndRegion

#Región FormCommandHandlers
// Código de procedimientos y funciones
#EndRegion

#Región InternalProceduresAndFunctions
// Código de procedimientos y funciones
#EndRegion

2. Requisitos generales para las secciones de módulos de programación.

2.1. Encabezado del módulo es un comentario al comienzo mismo de un módulo. El encabezado del módulo contiene una breve descripción del módulo y las condiciones para su uso.

Ejemplo:

////////////////////////////////////////////////////////////////////////////////
// Procedimientos y funciones de cliente de propósito general para:
// – trabajar con listas en formularios;
// – trabajar con el Registro de eventos;
// – manejar acciones del usuario durante la modificación de un texto que consta
//   de múltiples líneas, como un comentario de documento;
// – diversos.
//
////////////////////////////////////////////////////////////////////////////////

Recomendamos que el encabezado de un módulo de formulario contenga la descripción de los parámetros del formulario.

2.2. Sección de descripción de variables. Nombre sus variables de acuerdo con las reglas generales de nomenclatura de variables. Para recomendaciones sobre el uso de variables, consulte Uso de variables globales en módulos.

Para cada variable, agregue un comentario que explique claramente su propósito. Recomendamos que agregue el comentario en la misma línea donde se declara la variable.
Ejemplos:

Variable AccountingCurrency Export; // Moneda utilizada para contabilidad
Variable SupportAddress Export; // Dirección de correo electrónico para enviar mensajes de error

2.3. Interfaz. Agregue procedimientos y funciones de exportación que constituyan la interfaz justo después de la descripción de variables. Estos procedimientos y funciones están destinados a ser utilizados por otros objetos de configuración o por otros programas (por ejemplo, a través de una conexión externa), por lo tanto, deben ser fácilmente visibles en un módulo.

Véase también: Descripciones de procedimientos y funciones

2.4.1 Manejadores de eventos de un formulario, comandos y elementos de formulario. En un módulo de formulario, preceda los procedimientos y funciones internos con los manejadores de eventos de formulario, así como los manejadores de eventos de comandos y elementos de formulario.

Esta recomendación es opcional

Recomendamos que agrupe los manejadores de un solo elemento de formulario juntos y los ordene dentro de estos grupos según su orden en el panel de propiedades del editor de formularios en Designer.

2.4.2. Para cada evento, especifique un procedimiento para manejarlo. Si se deben ejecutar las mismas acciones cuando ocurren eventos en diferentes elementos de formulario, haga lo siguiente:

Este es un ejemplo de implementación incorrecta:

&AtClient
Procedure ByPerformerOnChange(Item)
 FilterParameters = New Map();
 FilterParameters.Insert(“ByAuthor”, ByAuthor);
 FilterParameters.Insert(“ByPerformer”, ByPerformer);
 SetListFilter(List, FilterParameters);
EndProcedure

&AtClient
Procedure ByAuthorOnChange(Item)
 ByPerformerOnChange(Undefined);
EndProcedure

Este es un ejemplo de implementación correcta:

&AtClient
Procedure ByPerformerOnChange(Item)
 SetFilter();
EndProcedure

&AtClient
Procedure ByAuthorOnChange(Item)
 SetFilter();
EndProcedure

&AtServer
Procedure SetFilter()
 FilterParameters = New Map();
 FilterParameters.Insert(“ByAuthor”, ByAuthor);
 FilterParameters.Insert(“ByPerformer”, ByPerformer);
 SetListFilter(List, FilterParameters);
EndProcedure

Este requisito se basa en el hecho de que, lógicamente, los procedimientos que son manejadores de eventos no están destinados a ser utilizados en el código del módulo y en su lugar son llamados por la plataforma misma. Y mezclar estos dos escenarios en un solo procedimiento hace que su lógica sea innecesariamente complicada y reduce su estabilidad (ya que en este caso, el código del procedimiento debe estar atento a muchos tipos de llamadas directas desde el código, en lugar de un solo evento de la plataforma).

2.5. Manejadores de eventos de los módulos de objeto y administrador de objetos siguen a los procedimientos y funciones de exportación del módulo pero preceden a los internos.  

Esta recomendación es opcional

Recomendamos que organice los manejadores según su orden en la descripción del script de 1C:Enterprise.

2.6. Procedimientos y funciones internos del módulo que no son controladores de eventos y constituyen la implementación interna del módulo siguen a los controladores de eventos en el módulo.

Cuando un módulo común es parte de un subsistema funcional que incluye múltiples objetos de metadatos, esta sección también puede contener otros procedimientos y funciones internos de exportación destinados a ser llamados solo desde otros objetos de este subsistema.

Recomendamos agrupar los procedimientos y funciones que están interrelacionados por su naturaleza o lógica de operación juntos. No recomendamos agrupar explícitamente los procedimientos y funciones del módulo en bloques de servidor, cliente y sin contexto porque tal agrupación complica la comprensión de la lógica del módulo y distrae a los desarrolladores al llamar su atención sobre detalles de implementación.

2.7. La sección de inicialización contiene operadores que inicializan variables del módulo o un objeto (formulario). Ejemplo:

SupportAddress = "<a href=""mailto:int@1c.com"">int@1c.com</a>"; // Dirección para contactar soporte
Initialize();

Textos del módulo

Este artículo describe los estándares que se aplican al contenido del módulo. Todas las recomendaciones enumeradas son obligatorias a menos que se indique lo contrario.

1. Escriba los textos del módulo en inglés (no use la variante en ruso del script).

Esta recomendación es opcional

2. Los módulos de programa no deben contener procedimientos o funciones no utilizados.

3. Los módulos de programa no deben contener bloques de código que estén comentados o de alguna manera relacionados con el proceso de desarrollo (código de depuración, marcas auxiliares) o con los desarrolladores específicos de este código. Dichos fragmentos deben eliminarse después de completar la depuración o refactorización.

Incorrecto:

Procedure BeforeDelete(Cancel)
//    If True Then
//        Message("Mensaje de depuración");
//    EndIf;
EndProcedure

También incorrecto:

Procedure BeforeDelete(Cancel)
    If True Then
        // Johnson: completar esto
    EndIf;
EndProcedure

Correcto: después de completar la depuración o refactorización, elimine el controlador BeforeDelete del código.

4. El texto del módulo se formatea siguiendo la regla de que debe haber un solo operador por línea. Se permiten múltiples operadores solo para operadores de asignación del mismo tipo:

InitialIndex = 0; Index = 0; Result = 0;

5. El texto del módulo debe estar estructurado utilizando una sintaxis con sangría. La tabulación se utiliza para crear sangrías (no use espacios, de modo que cuando el número de caracteres en la tabulación cambie, se preserve la alineación del texto).

El tamaño de la tabulación es estándar (4 caracteres).

5.1. Solo los siguientes elementos deben comenzar en la posición más a la izquierda:

5.2. Los procedimientos BeginTransaction y CommitTransaction no se consideran paréntesis de operadores, por lo tanto, el texto entre ellos no tiene sangría.

6. Todas las líneas más largas de 120 caracteres deben ser divididas. Recomendamos no crear líneas más largas de 120 caracteres excepto cuando no sea posible dividirlas (por ejemplo, el código define una constante de cadena larga que se muestra sin dividir en una ventana de mensaje usando el objeto UserMessage).

7.1. Los textos del módulo pueden contener comentarios. Los comentarios deben ser lo suficientemente claros para describir cómo funciona el módulo o el operador. El texto del comentario debe seguir las reglas del idioma inglés, usar un estilo empresarial apropiado, no ser emocional y no contener palabras que no estén relacionadas con las funciones del programa. 

7.2. Los comentarios más cortos se agregan al final de la cadena comentada:

ErrorsFound.Columns.Add(“Número”); // por razones de compatibilidad

Comentarios más largos o comentarios que describen un bloque de código van antes del código comentado en una línea individual.

7.3. Los comentarios más largos deben comenzar con una letra mayúscula y terminar con un punto. El texto se alinea con el borde izquierdo del código comentado. Debe haber un espacio que separe los caracteres “//” del comentario y el texto del comentario.

// Inicializando variables para cálculos
// que se realizan más adelante en el módulo.
CurrentDate = CommonUse.GetWorkDate();
CurrentYear = Year(CurrentDate);
CurrentMonth = Month(CurrentDate);
CurrentWeek = WeekOfYear(CurrentDate);
CurrentDay = Day(CurrentDate);

7.4. Puede dividir procedimientos y funciones grandes en regiones plegables. Los nombres de las regiones deben cumplir con el estándar de Reglas de nombramiento de variables.

Ver también

Escribir registros de registro

Este artículo describe las normas que se aplican al orden de escritura de registros de registro. Todas las recomendaciones enumeradas son obligatorias a menos que se indique lo contrario.

1. Recomendamos no utilizar la escritura explícita de conjuntos de registros de registro (con el método Write) en los controladores de publicación de documentos. La escritura debe realizarse implícitamente por la plataforma durante la finalización de la ejecución del controlador de publicación.

Si ignora esta recomendación, la publicación paralela de documentos por parte de múltiples usuarios podría causar bloqueos.

2. Los escenarios en los que los algoritmos ejecutados antes de la finalización de la ejecución del controlador de publicación requieren datos almacenados en registros son una excepción a esta regla.

Ver también:

   

Tagged

Axial ERP ofrece un abanico de soluciones robustas para gestión y automatización de procesos empresariales, caracterizadas por su simplicidad de uso y su capacidad para brindar una experiencia de gestión empresarial completamente integrada.

Facebook Linkedin

Menú

Contacto

info@axial-erp.co

(+57) 601 5898710

Bogotá Colombia | Estados Unidos

© 2022-2024 Axial Solutions LLC. Todos los derechos reservados. Todas las demás marcas comerciales y derechos de autor pertenecen a sus respectivos dueños.