Red de conocimiento informático - Conocimiento de la instalación - ¿Alguien conoce las especificaciones de programación de los programas en lenguaje C? ¿Puede resumirlas?

¿Alguien conoce las especificaciones de programación de los programas en lenguaje C? ¿Puede resumirlas?

1 Introducción

1.1 Propósito de la escritura

En el proceso de desarrollo de software, la carga de trabajo de codificación es considerable y las personas involucradas en la programación en el mismo proyecto pueden Tienen su propia experiencia y hábitos de programación, y los diferentes estilos de códigos de programa hacen que el trabajo de mantenimiento sea complicado y difícil. Para mejorar la legibilidad del código, la estabilidad del sistema y reducir el costo de mantenimiento y actualizaciones, esta especificación está escrita especialmente para unificar el trabajo de programación de los desarrolladores.

1.2 Objetos aplicables

Esta especificación se aplica a todos los desarrolladores, incluidos los desarrolladores de aplicaciones, web y bases de datos, y los probadores de programas relacionados.

1.3 Estándares de referencia

GB/T 11457 Terminología de ingeniería de software

GB 8566 Especificaciones de desarrollo de software informático

GB 8567 Desarrollo de productos de software informático Guía de documentación

2. Requisitos de escritura

2.1 Principio de legibilidad de las reglas generales del código. Este es el indicador preferido para evaluar la calidad del programa. Es mejor garantizar la legibilidad del programa sin algunas habilidades y no sacrificar la legibilidad. el programa debido a la búsqueda excesiva de habilidades. Principio de independencia funcional. Cada bloque de programa solo completa una función independiente. A su vez, cada función independiente solo se completa dentro de un bloque de programa, con el menor acoplamiento y la mayor cohesión posible. Las descripciones rápidas deben ser breves y evitar la ambigüedad. Los mensajes de aviso o advertencia deben ser orientativos y pueden indicar con precisión a los usuarios la causa del error y los métodos de recuperación. Los cuadros de diálogo de mensajes y advertencias deben utilizar convenciones estándar. La definición de teclas de acceso directo debe ajustarse a los hábitos operativos del usuario. Cuando un programa necesita procesarse o esperar mucho tiempo, se debe mostrar una barra de progreso y se le debe solicitar al usuario que espere. Algunas operaciones confidenciales, como la eliminación, deben solicitar confirmación al usuario antes de su ejecución.

2.2 Reglas de nomenclatura para variables, funciones, procedimientos, controles, etc.

2.2.1 Nomenclatura de variables

La nomenclatura de variables adopta [Alcance][Tipo de datos] Las reglas de [Nombre de definición automática] están definidas y siguen la nomenclatura húngara. Es necesario ver el nombre de la variable para ver intuitivamente su alcance y tipo de datos.

Reglas de nomenclatura húngaras:

a Array

b BOOL (int) Boolean (entero)

by Unsigned Char (Byte) carácter sin signo (byte)

c Carácter de carácter (byte)

cb Recuento de bytes número de bytes

cr Valor de referencia de color valor de color (referencia)

cx Recuento de x (corto) Conjunto de x (entero corto)

dw DWORD (largo sin signo) Palabra doble (entero largo sin signo)

f Banderas (generalmente valores de bits múltiples) bandera (generalmente un valor de varios dígitos)

fn Función función

g_ global global

h Identificador de identificador

i Entero entero

l Entero largo largo

lp Puntero largo puntero largo

m_ Miembro de datos de una clase miembro de datos de una clase

n Short int entero corto

p Puntero puntero

s Cadena cadena

sz Cadena terminada en cero Cadena que termina en 0

tm Texto reglas de texto métrico

u Unsigned int entero sin signo

ul Unsigned long (ULONG) unsigned long entero

w WORD (unsigned short) unsigned Short entero

x,y x , coordenadas y (cortas)

Valor de coordenadas/entero corto

v void alcance vacío:

Ejemplo de prefijo de alcance

Alcance global g_ g_Servers

Variable miembro m_ m_pDoc

No hay tipo de datos strName en el ámbito local

Lista de prefijos comunes de VC

Ejemplo de descripción del tipo de prefijo

ch char Carácter de 8 bits chGrade

ch TCHAR Carácter de tipo UNICODE de 16 bits chName

b BOOL Variable booleana bEnabled

n int tipo entero (su tamaño lo determina el sistema operativo) nLength

n UINT entero sin signo (su tamaño lo determina el sistema operativo) nLength

w WORD Entero sin signo de 16 bits wPos

l LONG Entero con signo de 32 bits lOffset

dw DWORD Entero sin signo de 32 bits dwRange

p * Puntero del módulo de memoria, variable de puntero pDoc

l p FAR* Puntero largo lpDoc

lpsz LPSTR puntero de cadena de 32 bits lpszName

lpsz LPCSTR puntero de cadena constante de 32 bits lpszName

lpsz LPCTSTR puntero constante de tipo UNICODE de 32 bits lpszName

h handle Identificador de objetos de Windows hWnd

lpfn (*fn)() Puntero de función de devolución de llamada Puntero lejano de devolución de llamada a

Función de DEVOLUCIÓN DE LLAMADA lpfnAbort

2.2.2 Funciones y procedimientos Denominación

El cuerpo del nombre de una función o procedimiento debe estar en mayúsculas y minúsculas y debe ser lo suficientemente largo para describir su propósito. Además, el nombre de la función debe comenzar con un verbo, como InitNameArray o CloseDialog. Para términos largos o de uso frecuente, se recomienda utilizar abreviaturas estándar para racionalizar la longitud del nombre. En términos generales, los nombres de variables de más de 32 caracteres son difíciles de leer en un monitor VGA. Cuando utilice abreviaturas, asegúrese de que sean coherentes en toda la solicitud. En un proyecto, si usa Cnt en un momento y Count en otro, generará confusión innecesaria.

Para funciones autoescritas, si es una función clave del sistema, la información de la función debe indicarse arriba de la parte de implementación de la función, en el siguiente formato:

/ /====== ============================================ =====

// Nombre de la función: InsureHasOutputInfo

// Descripción de la función: Garantizar la información de salida adecuada

// Parámetro de entrada: nProductID: producto correspondiente ID

// Parámetro de salida: void

// Fecha de creación: 00-2-21

// Fecha de modificación: 00-2-21

// Autor: ***

// Notas adicionales:

//================== ===== =================================

2.2.3 Usuario- tipos definidos

En un proyecto grande con muchos tipos definidos por el usuario, a menudo es necesario darle a cada tipo su propio prefijo de tres caracteres. Si estos prefijos comienzan con "u", es fácil identificar rápidamente estos tipos cuando se trabaja con un tipo definido por el usuario. Por ejemplo, ucli se puede utilizar como prefijo para una variable de tipo de cliente definida por el usuario.

Nota: Para variables no generales, agregue comentarios al definirlas y coloque la definición de la variable al principio tanto como sea posible.

2.2.4 Controlar la denominación

Los objetos deben nombrarse con prefijos coherentes para que a las personas les resulte más fácil identificar el tipo de objeto.

Lista de nombres de definiciones de macros comunes de VC

Rango de ejemplo de símbolo de tipo de prefijo

IDR_ identifica el tipo compartido por múltiples recursos IDR_MAINFRAME 1~0x6FFF

p >

IDD_ Recurso de diálogo (Diálogo) IDD_SPELL_CHECK 1~ 0x6FFF

HIDD_ Ayuda contextual basada en diálogo HIDD_SPELL_CHECK 0x20001~0x26FF

IDB_ Recurso de mapa de bits (mapa de bits) IDB_COMPANY_LOGO 1 ~0x6FFF

IDC_ Recurso de cursor (Cursor) IDC_PENCIL 1~0x6FFF

IDI_ Recurso de icono (Icono) IDI_NOTEPAD 1~0x6FFF

ID_, IDM_ barra de herramientas o menú Elemento de comando de columna ID_TOOLS_SPELLING 0x8000 ~0xDFFF

HID_ Ayuda contextual del comando HID_TOOLS_SPELLING 0x18000~0x1DFFF

IDP_ Recurso de texto del mensaje del cuadro de mensaje IDP_INVALID_PARTNO 8~0xDFFF

HIDP_ Cuadro de mensaje Ayuda contextual HIDP_INVALID_PARTNO 0x30008~0x3DFFF

IDS_ Recurso de cadena (String) IDS_COPYRIGHT 1~0x7FFF

IDC_ Recurso de control en el cuadro de diálogo IDC_RECALC 8~0xDFFF

2.3 Reglas del código fuente

2.3.1 Convención de estilo: use formato sangrado para guardar la estructura jerárquica del programa. Es necesario ver intuitivamente estructuras jerárquicas como bucles y juicios.

Cada bloque de funciones anidado utiliza una sangría TAB (se puede establecer en 4 espacios). Las llaves deben colocarse en la siguiente línea de la declaración condicional y deben colocarse en una línea separada para facilitar la coincidencia. estar en una línea separada y las extensiones posteriores deben comentarse en la mayoría de los casos.

Por ejemplo:

if(condición1)

{

while(condición2)

{

…. .

…..

}//finalizar mientras(condición2)

}//finalizar si (condición1)

o

si(condición1){

mientras(condición2){

….

….

}/ /end while(condición2)

}//end if(conditionl)

2.3.2 Se deben utilizar espacios antes y después del operador.

2.3.3 Se debe agregar un espacio después de la coma que separa el subíndice del array y los parámetros de la función.

2.3.4 El uso de declaraciones go to está estrictamente prohibido.

2.3.5 Sólo se pueden utilizar sentencias SQL estándar para operaciones de bases de datos. Las palabras clave deben estar en mayúsculas (como SELECT, WHERE, etc.) y los elementos de datos (tablas, campos, vistas, etc.) debe escribirse de acuerdo con el diccionario de datos.

2.3.6 El código del programa debe tener suficientes funciones de procesamiento tolerante a fallas.

Utilice uniformemente el formato de lanzamiento de C++ para posibles excepciones:

pruebe

{

//Código que puede causar excepciones

throw t; //Lanzar excepción manualmente

}

catch(type_1 e) // type_1 es el definidor de tipo, como int, CException, _com_error

{

// manejo de excepciones de tipo type_1

}

catch(type_2 e)

{

//manejo de excepciones de tipo type_2

}

2.3.7 La estructura del código del programa debe ser clara en niveles y las líneas en blanco deben usarse apropiadamente para la segmentación.

El control de versiones del proyecto 2.3.8 debe ser estricto. El formato de versión es .me.ae.yy.mmdd, donde: [me] representa el número de versión principal [ae] representa la menor; número de versión; [yy. mmdd] representa la fecha de creación de la versión. La versión superior debe intentar ser compatible con el uso, datos o protocolos de la versión inferior.

2.4 Reglas de nomenclatura para archivos

2.4.1 Cree las carpetas correspondientes de acuerdo con la estructura especificada por el diseño del sistema y cree subcarpetas según sea necesario.

2.4.2 Los nombres de carpetas y archivos deben poder expresar su significado tanto como sea posible. Intente utilizar nombres en inglés y absolutamente ningún carácter chino.

2.4.3 Los nombres de archivos generalmente usan el formato "xxx_yyy.ext", xxx (3-4 letras) representa clasificación, yyy (número personalizado de letras) representa operaciones (como "/example/exp_edit. htm ”)

\

¡Lo copié del documento de la empresa! ¡Compruebe usted mismo si funciona para usted!