convencion de codigo c#

5/26/2018 Convencion de Codigo C#

1/24

Gua de estilo de programacin en C#.

Esta gua te ayudara a escribir tus

programas de C# mas legibles siguiendo

un estilo unificado.

GUA DE

ESTILOS DEC#

scar lvarez Guerras

http://geeks/blogs/oalvarez


2/24

Oscar Alvarez Guerrashttp://geeks.ms/blogs/oalvarez 1

Contenido1. INTRODUCCIN ......................................................................................................................... 2

2. GUA DE ESTILO C# .................................................................................................................... 3

2.1. RECOMENDACIONES GENERALES ...................................................................................... 3

2.1.1. Encapsulacin y Ocultacin ............................................................................................. 3

2.1.2. Comentarios .................................................................................................................... 3

2.1.3. Sangras, espacios y lneas en blanco .......................................................................... 6

2.1.4. Uso de las llaves .......................................................................................................... 7

2.1.5. Cdigo sin finalizar ...................................................................................................... 7

2.1.6. Conversin de tipos ..................................................................................................... 8

2.2. CONVENCIN DE NOMBRES .............................................................................................. 8

2.2.1. Variables y objetos ...................................................................................................... 8

2.2.2. Formularios e Interfaces ............................................................................................. 9

2.2.3. Controles Windows ..................................................................................................... 9

2.2.4. Excepciones ............................................................................................................... 10

2.3. GUA DE ESTILO ................................................................................................................ 11

2.3.1. Ficheros ..................................................................................................................... 11

2.3.2. Sentencias condicionales y de iteracin.................................................................... 12

2.3.3. Variables y objetos .................................................................................................... 14

2.3.4. Propiedades ............................................................................................................... 15

2.3.5. Operadores ................................................................................................................ 15

2.3.6. Regiones .................................................................................................................... 15

2.3.7. Mtodos .................................................................................................................... 16

2.3.8. Clases ......................................................................................................................... 17

2.3.9. Interfaces ................................................................................................................... 18

2.4. OTRAS RECOMENDACIONES ............................................................................................ 19

2.5. MEJORA DE LA EFICIENCIA ............................................................................................... 20

APNDICE A: NOMENCLATURA DE ESPACIOS DE NOMBRES ...................................................... 21

APNDICE B: EXCEPCIONES ......................................................................................................... 22

APNDICE C: COMPATIBILIDAD CON OTROS LENGUAJES .NET................................................... 23

C.1. USO DE MAYSCULAS Y MINSCULAS ............................................................................ 23

C.2. NOMBRES Y PALABRAS RESERVADAS .............................................................................. 23


3/24


1. INTRODUCCIN

Esta gua tiene como finalidad proporcionar un conjunto de reglas que nos ayuden aescribir programas en C# con buen estilo. Un cdigo escrito con buen estilo, encualquier lenguaje, es aquel que tiene las siguientes propiedades:

Est organizado

Es fcil de leer

Es fcil de mantener

Es fcil detectar errores en l

Es eficiente

Observando estas reglas, se puede concluir que el objetivo ltimo del estilo de

programacin es, bsicamente la buena comunicacin en el sentido ms amplio,siendo el interlocutor de esa comunicacin otras personas que lean el cdigo, losusuarios del programa o las herramientas con las que el cdigo se relaciona (editoresde texto, compiladores u otras herramientas colaterales como trazadores odepuradores) o incluso, los manuales del propio software desarrollado.Las recomendaciones y normas expuestas en esta gua, obtenidas a partir deestndares, experiencias personales y necesidades de los sistemas en la comunidadde desarrolladores de C#, no pretenden formar un conjunto inflexible de estndares decodificacin, aunque deben seguirse en la medida de lo posible, proponiendomodificaciones o sugerencias en los casos que se considere oportuno.Inicialmente, esta gua est orientada a programadores C#, pero la mayor parte de susprincipios y reglas se usan a menudo en otros lenguajes de programacin.


4/24


2. GUA DE ESTILO C#

2.1. RECOMENDACIONES GENERALES

Los principios de esta seccin sirven para aumentar la legibilidad del cdigo y facilitar

su mantenimiento. Nos debemos olvidar que todo el software debe mantener unaestructura homognea y claramente diferenciada.

2.1.1. Encapsulacin y Ocultacin

La encapsulacin y ocultacin de informacin ayudan a organizar mejor el cdigo yevitan el acoplamiento entre funciones.La encapsulacin permite agrupar elementos afines del programa. Los subprogramasafines se agrupan en ficheros (unidades), y los datos en grupos lgicos (estructuras dedatos).Ocultacin de informacin: Un subprograma no necesita saber lo siguiente:

La fuente de los parmetros que se le pasan como entrada.

Para qu servirn sus salidas.

Qu subprogramas se activaron antes que l.

Qu subprogramas se activarn despus que l.

Cmo estn implementados internamente otros subprogramas.

Para conseguir esto se deben seguir las siguientes reglas:

Declarar las variables y tipos como locales a los subprogramas que los utilizan.

Si queremos evitar cambios indeseados en parmetros, pasarlos por valor.

Un procedimiento slo debe modificar los parmetros pasados en su llamada.

2.1.2. Comentarios

2.1.2.1. Recomendaciones generales

Los comentarios dan informacin sobre lo que hace el cdigo en el caso que no seafcil comprenderlo con una lectura rpida. Se usan para aadir informacin o paraaclarar secciones de cdigo. No se usan para describir el programa, se aaden juntoa la definicin de clases, variables, propiedades, mtodos, etc. para explicar supropsito, y al comienzo de algunas secciones de cdigo, especialmente complicadas,para explicar su funcionamiento.Los comentarios se pueden escribir en diferentes estilos dependiendo de su longitud y

su propsito. En cualquier caso seguiremos las siguientes reglas generales:

Los comentarios en general se escriben en lneas que no contienen cdigoy antes del cdigo que queremos clarificar. Esta regla se aplica siempre si elcomentario tiene ms de una lnea.

Slo en dos casos se permite poner en la misma lnea un comentario y unainstruccin: comentarios a una definicin de variable, que explica la finalidadde esta variable, y un comentario para indicar final de una estructura dellenguaje.


5/24


2.1.2.2. Documentacin XML. Etiquetas recomendadas

En C#, es posible documentar el cdigo de un programa mediante XML (C# es elnico lenguaje de programacin de Visual Studio .NET con esta caracterstica)comenzando el comentario con ///.La documentacin debe estar en XML bien formado. Si el XML no est bien formado,se generar un error de advertencia y el archivo de documentacin incluir uncomentario que mencione el error encontrado.Etiquetas bsicas recomendadas:

: se utiliza para describir brevemente un tipo o un miembro de tipo.El texto de esta etiqueta es la nica fuente de informacin sobre el tipo enIntelliSense.

Descripcin

: se utiliza para agregar informacin sobre un tipo, de modo quecompleta la informacin especificada con . Descripcindetallada

: se debe utilizar en el comentario de una declaracin de mtodo paradescribir uno de los parmetros del mtodo.

Descripcin

: se debe utilizar en el comentario de una declaracin de mtodopara describir el valor devuelto.

Descripcin

:proporciona un modo de indicar que una palabra es un parmetro.El archivo XML se puede procesar de manera que aplique formato a esteparmetro de algn modo diferente.

: permite especificar las excepciones que se pueden iniciar. Estaetiqueta se aplica a una definicin de mtodo.

Descripcin

: permite describir una propiedad. Al agregar una propiedad a travsdel asistente para cdigo se crear una etiqueta para la nuevapropiedad. A continuacin, se debe agregar manualmente una etiqueta que describa el valor que representa la propiedad.

Descripcin del valor de la propiedad


6/24


2.1.2.3. Tipos de Comentarios

Con todo esto se pueden definir los siguientes tipos de comentarios:

Comentarios de clase: Usados en la definicin de una clase. Opcionalmentepuede contener informacin acerca de la versin.

Ejemplo:

/// Descripcin genrica de la clase/// Descripcin detallada de la clase

Comentarios de variables: En el caso de que una variable requieracomentario ste deber aparecer al estilo XML. Si nicamente sonaclaraciones, se realizarn en la misma lnea en que se declara la variable ysern muy breves.

Ejemplo: /// Descripcin breve de la variable

private int iNumPruebas; // Contador pruebas realizadas

Comentarios de mtodos: Usados en la definicin de los mtodos,

simplemente describen su funcionalidad.

Ejemplo:

/// Descripcin breve del mtodo/// Descripcin detallada del mtodo/// Descripcin parmetro 1/// Informacin valor de retorno/// Descripcin excep1

Comentarios cortos: Se usan para describir funcionalidades o datos. Debensituarse en la lnea inmediatamente anterior a la funcionalidad que se va adescribir. Tambin se usan para indicar el final de una estructura. En caso de

utilizar este tipo de comentario, seguir las siguientes reglas:

o Utilizar uno o ms tabuladores para separar la instruccin y elcomentario.

o Si aparece ms de un comentario en un bloque de cdigo o bloque dedatos, todos comienzan y terminan a la misma altura de tabulacin.

Ejemplo:// Obtenemos el menor de los datosfor ()

{

} // Fin del FOR

2.1.2.4. Otras recomendaciones

Otras recomendaciones sobre el uso de comentarios son:

Cuando modifique el cdigo, mantenga siempre actualizados los comentarioscircundantes.

Despus de la implementacin, quite todos los comentarios temporales oinnecesarios para evitar cualquier confusin en la fase de mantenimiento.

Use los comentarios para explicar el propsito del cdigo. No los use como sifueran traducciones interlineales.

Realice los comentarios con un estilo uniforme en toda la aplicacin.


7/24


2.1.3. Sangras, espacios y lneas en blanco

Los espacios en blanco facilitan la lectura y el mantenimiento de los programas. Losespacios en blanco que se pueden utilizar son: las sangras, los caracteres espacio ylas lneas en blanco.

2.1.3.1. Sangras

El sangrado se utiliza para mostrar la estructura lgica del cdigo. El sangrado ptimoes el formado por cuatro espacios. Es un compromiso entre una estructuracinlegible y la posibilidad de que alguna lnea (con varios sangrados) del cdigo supere elancho de una lnea de una hoja de papel o del monitor.El sangrado se debe realizar con tabulaciones, por tanto se debe fijar ste en cuatrocaracteres. Es la opcin por defecto del entorno Visual Studio .NET.

2.1.3.2. Caracteres espacio

Los espacios en blanco sirven para facilitar la lectura de los elementos que forman unaexpresin. Los espacios en blanco se utilizan en los casos siguientes:

Las variables y los operadores de una expresin deben estar separados por unelemento en blanco.

Ejemplo: Espaciado de operadoresfMedia = iSuma / iCuenta;

Las listas de definicin de variables y las listas de parmetros de una funcinse debe separar por un espacio en blanco.

Ejemplo: Lista de parmetros

AbrirBusqueda (iTarjeta, iMovil);

2.1.3.3. Lneas en blanco

Se utilizan para separar prrafos o secciones del cdigo. Cuando leemos unprograma entendemos que un fragmento de cdigo entre dos lneas en blanco formaun conjunto con una cierta relacin lgicaVeamos como separar secciones o prrafos en un programa:

Las secciones que forman un programa se separan con al menos una lnea enblanco (declaracin de constantes, declaracin de variables, mtodos,).

Dentro de un subprograma se separan con una lnea en blanco los fragmentosde instrucciones muy relacionadas entre s (por ejemplo, conjunto de

instrucciones que realizan una operacin).


8/24


2.1.4. Uso de las llavesLa forma que tiene C# de agrupar instrucciones en bloques es utilizar las llaves {}. Sucolocacin se debe hacer en lneas reservadas para cada una de ellas, sin ningunaotra instruccin en la lnea. Ambas deben ir en la misma columna que la instruccinque la precede.

Ejemplo:for (iContador = 0; iContador < iNumIteraciones;iContador++){

}

Se permiten algunas excepciones a esta norma en las sentencias condicionales y derepeticin donde la llave de apertura puede estar al final de la sentencia de control odonde tras la llave de cierre se permiten sentencias condicionales.

Ejemplo: llave al final de la sentenciaif (iContador == 0){

}else {

}Ejemplo: sentencias tras la llave de cierredo{

} while (iEstado != iResultOk)

Se debe evitar en la medida de lo posible omitir las llaves, incluso en aquellos bloquesque encierran una nica sentencia.

Ejemplo: llaves en bloques con sentencias nicasif (iContador == 0){iResultado = RET_OK;}

2.1.5. Cdigo sin finalizar

Siempre que partes de la funcionalidad no se implementen, queden inacabadas o seaprevisible concluirlas en un futuro, es conveniente documentarlo de modo que seafcilmente localizable.Con esta finalidad, el entorno de desarrollo de C# mantiene un listado de tareaspendientes que se pueden obtener directamente de los comentarios de cdigo. As,cuando se deba completar cualquier tipo de cdigo se documentar con //TODO:ms la descripcin de la funcionalidad pendiente, y sta aparecer en el editor detareas cuando se muestren todas o las de comentario.

Ejemplo: documentacin de cdigo sin finalizarprivate void CalcularBalance (){

// TODO: Calcular el Balance de la cuenta}


9/24


2.1.6. Conversin de tipos

Cuando sea necesario convertir datos de un tipo a otro, es aconsejable que stas sehagan de modo explcito, aunque muchas de ellas las realice el compiladorautomticamente (implcito).

Ejemplo: conversin explcitalong lValor = 3000;int iValor = (int) lValor;

2.2. CONVENCIN DE NOMBRES

Los identificadores que dan nombre a la aplicacin, clases, mtodos, variables, tipos,etc. han de colaborar en la autodocumentacin del programa, aportando informacinsobre el cometido que llevan a cabo (el qu y no el cmo). Para elegir los nombres sedeben seguir las siguientes recomendaciones generales

Elegir nombres comprensibles y en relacin con la tarea que corresponda alobjeto nombrado.

Utilice palabras completas siempre que sea posible. Las abreviaturas puedenadoptar muchas formas y en consecuencia, pueden resultar confusas. En elcaso en que sea estrictamente necesario usarlas, elija las abreviaturasadecuadamente.

Cuando se trabaje con siglas o acrnimos, stos deben mantener todos suscaracteres es maysculas.

Ejemplo: Uso siglas o acrnimosint GenararHTML (...)

Utilizar prefijos definidos para cada uno de los elementos.

2.2.1. Variables y objetos

La notacin hngara es un sistema usado normalmente en la comunidad dedesarrolladores para crear nombres cuando se programa en Windows. Consiste enprefijos en minsculas que se aaden a los nombres de las variables y que indican sutipo. El resto del nombre indica, lo ms claramente posible, la finalidad del elemento.

Prefi jo Tipo y Signif icado Ejemplos

b Booleano (bool) bool bNombre;ch Carcter (char) char chNombre;

s Cadena de texto(string)

string sNombre;

bt 1 byte (byte) BYTE btNombre;

i Entero con signo (int) int iNombre;

sh (short) short shNombre;

l Entero largo (long) long lNombre;

db (double) double dbNombre;

f (float) float fNombre;

d (decimal) decimal dNombre ;

dt (DateTime) DateTime dtNombre;s t Estructuras (struct) struct stNombre {};


10/24


e Enumeraciones (enum) enum eNombre {};

o Objeto o instancia deuna clase

Raiz oRaiz;

ds (DataSet) DataSet dsNombre;

dt (DataTable) DataTable dtNombre;

dr (DataRow) DataRow drNombre;dc (DataColum) DataColum dcNombre;

dv (DataView) DataView dvNombre;

drd (DataReader) DataReaderdrdNombre;

ht (Hashtable) Hashtable htNombre;

Adems de estos tipos estndar, existen otros prefijos que usan junto a stos para expresar

condiciones excepcionales.

u Tipos primitivos sinsigno (unsigned)

uint uiNombre;

p Puntero a objeto(unsafe code)

int* piNombre;

arr Arrays int[] arriNombre;

2.2.2. Formularios e Interfaces


I Nombres de interfaces interface

INombreInterfazForm Formulario class

FNombreFormulario

2.2.3. Controles WindowsDel mismo modo que con las variables y objetos se notarn del siguiente modo:


lbl Label lblNombrelnk LinkLabel lnkNombre

btn Button btnNombretxt TextBox txtNombre

mnm MainMenu mnmNombre

chk CheckBox chkNombrerdb RadioButton rdbNombre

grp GroupBox grpNombrepct PictureBox pctNombre

pnl Panel pnlNombre

dg DataGrid dgNombrelsb ListBox lsbNombre

cmb ComboBox cmbNombre

lsv ListView lsvNombretrv TreeView trvNombre


11/24


tbc TabControl tbcNombreprg ProgressBar prgNombre

rtb RichTextBox rtbNombreimg ImageList imgNombre

stb StatusBar stbNombre

Ntese que los controles se nombran con sus tres letras ms significativas en minsculas.

2.2.4. Excepciones

Para las propiedades y las clases genricas no se aplican estas reglas:

Tipo y Signif icado Ejemplos

Propiedades string Nombre;

Nombres de clases genricas class CNombreClase


12/24


2.3. GUA DE ESTILO

2.3.1. Ficheros

Por norma general un fichero debe contener una nica clase. Slo se incluirn ms

cuando sea estrictamente necesario.Las lneas de cdigo no deben exceder de los 80 caracteres, incluyendo lastabulaciones y los comentarios en lnea. Las lneas largas deben ser separadas envarios renglones, de modo que al imprimir el cdigo sea legible. Cuando esto ocurra lasegunda lnea y las posteriores se deben indentar segn las circunstancias de cadalnea.

Ejemplo: Cadena de texto larga

MessageBox.Show(Esto es un ejemplo de lnea larga que se debe

indentar en la segunda lnea);

Ejemplo: Sentencia condicionalif ( ( (iEstado == Estado.A) && (iFase == Fase.F1) ) ||

( (iEstado == Estado.B) && (iFase == Fase.F2) ) ){}

Otro aspecto importante es la indentacin del cdigo. Esto depende de laconfiguracin de los distintos editores que se usen. En la medida de lo posible se debeindentar mediante tabuladores de 4 caracteres, como se define en el apartado deSangra.La estructura genrica de los ficheros ser

Sentencias using

Definicin del namespace

Declaracin de la clase

Variables o campos

Delegados y eventos

Propiedades

Mtodos

La organizacin interna de los campos y los mtodos en funcin de su mbito deacceso ser:

Pblicos

Protegidos

Privados


13/24


2.3.2. Sentencias condicionales y de iteracin

2.3.2.1. Sentencia IF

a la seccin ifelse van siempre en una lnea sangrada. Aunque est permitido, no serecomienda omitir las llaves cuando se englobe una nica sentencia.

Ejemplo: sin llaves (no recomendado)if (iValor1 < iValor2)

iValor1=0;else

iValor1=1;Ejemplo: con llaves

if (iValor1 < iValor2){

iValor1=0;}else {

iValor1=1;}

Los if anidados deben seguir una secuencia de sangrado lgica.Ejemplo: con llaves

if (iValor1 < iValor2){

iValor1=0;}else if (iValor1 < iValor3){

iValor1=1;}else {

iValor=2;}

2.3.2.2. Sentencia SWITCH

Los valores asociados a la sentencia switch irn en lnea aparte sangrada. El bloque desentencias asociado comenzar en otra lnea aparte y tambin sangrada. Todos los bloques desentencias pertenecientes al case comenzarn en la misma columna. Cada bloque case sedeber separar del siguiente con una lnea en blanco cuando englobe muchas lneas de cdigo.

Ejemplo: Uso de switchswitch (iValor){

case Valor.Uno:sTexto = Valor A;

break;case Valor.Dos:

sTexto = Valor B;

break;default:

sTexto = Valor desconocido;

}

Cuando la discriminacin se realice sobre tipos numricos ser obligatorio encapsulartodos los valores posibles en enumeraciones que se autocomenten.

Ejemplo: Uso de case


14/24


switch (iValor){

case Valor.Uno: /// Nunca case 1: !!!sTexto = Valor A;

break;

}

Es recomendable comentar el caso en que una sentencia case caiga dentro de otra, de modo

que las dos ejecuten el mismo cdigo

Ejemplo: Uso de case con mismo cdigoswitch (iValor){

case Valor.Uno:: /// Valores impares case Valor.Tres:sTexto = Valor impar;

break;

}

Del mismo modo, cuando una sentencia case no tenga cdigo asociado por el motivo que sea,

se debe comentar este motivo.

Ejemplo: Uso de case sin cdigoswitch (iTipo){

case Tipo.Redondo:/// Futura ampliacin sin implementarbreak;

case Tipo.Cuadrado:

break;

}

2.3.2.3. Sentencias de iteracin

Las sentencias pertenecientes a estructuras de iteracin o repeticin (for, while, dowhile y

foreach) van siempre en una nueva sangrada y con su cdigo indentado. Del mismo modo que

las sentencias condicionales, se debe evitar la omisin de las llaves.

Ejemplo: for sin llaves

for (iContador=0;... ;...)iSuma += iTipo;

Ejemplo: for con llavesfor (iContador=0;... ;...)

{iSuma += iTipo;

}


15/24


2.3.3. Variables y objetos

Todas las variables debern tener nombres significativos. Los nombres que formen una

variable comenzarn en maysculas y no tendrn ningn carcter de separacin (notacin

Pascal). Al nombre de la variable se le debe anteponer siempre y sin excepcin alguna su tipo

segn el convenio de nombres.

Ejemplo: variables correctasint iValor;string sTextoError;CCuadrado oCuadrado;

Ejemplo: variables incorrectasint Valor;

string sTextoerror;string stextoerror;

Las variables deben declararse siempre al principio de las clases o mtodos, una por

lnea, con comentarios si se estima oportuno e inicializndolas segn convenga

Ejemplo: declaraciones correctasprivate float CalcularRaizCuadrada (int iValor){

// Variables auxiliaresfloat fResultado;string sTexto = ;

bool bExacto = false;

CRaiz oRaiz;

}

Los nombres de variables booleanas deben ser lo suficientemente claros como paraexpresar el valor que encierran ante una pregunta.

Ejemplo: variables booleanasprivate bool bFinalizado;if (bFinalizado){}

En la medida de lo posible se deben evitar las variables pblicas y convertirlas enprivadas o protegidas con su propiedad de acceso a ellas.

2.3.3.1. Constantes

Todas las cantidades que permanezcan constantes deben nombrarse con const. Este tipo de

constantes respetarn las normas comunes de las variables.

Ejemplo: uso de constantes

public const int iValor = 10;


16/24


2.3.4. Propiedades

Para la notacin de una propiedad se usar el mismo nombre que la variable sobre la que

acta sin la nomenclatura del tipo.

Ejemplo: definicin de atributos de clasesclass CPoligono{private int iNumLados;public int NumLados

{get{

return iNumlados;}set{

iNumlados = value;}

}}

2.3.5. Operadores

Cuando se usen operadores, principalmente cuando tomen dos parmetros, se deber dejar

un espacio antes y otro despus del operador.

Ejemplo: uso de operadores

iNumPruebas += 5;

Es recomendable el uso de parntesis para eliminar las ambigedades que puedan

surgir por desconocimiento de las prioridades de los operadores.

Ejemplo: uso de parntesis es operadoresiResultado = (iDato1 * iDato2) / iDato3

2.3.6. Regiones

La sentencia #region permite especificar un bloque de cdigo que se puede expandiro contraer cuando se utiliza la caracterstica de esquematizacin del editor de cdigo

de Visual Studio.Dentro de un fichero se deben especificar las siguientes regiones:

Clase: Como ya se ha comentado, es conveniente que exista una nica clasepor fichero. En el caso de que esto no se pueda cumplir hay que definir unaregin por cada clase.

Ejemplo: regin a nivel de clase#region Clase Balance...#endregion


17/24


Variables: Debe englobar todas las variables definidas

Ejemplo: regin a nivel de variables#region Variables...#endregion

Delegados y Eventos: Si existen delegados y/o eventos se englobarn dentrode una misma regin.

Ejemplo: regin a nivel de delegados y/o eventos

#region Delegados y Eventos...#endregion

Propiedades: Sobre las propiedades que existan.

Ejemplo: regin a nivel de propiedades#region Propiedades...#endregion

Constructores: Si se han definido constructores personalizados

Ejemplo: regin a nivel de constructores#region Constructores...#endregion

Mtodos: Se englobarn todos los mtodos

Ejemplo: regin a nivel de mtodos#region Mtodos...

#endregion

Si alguno de los elementos no se encuentran definidos, se debe eliminar la regincorrespondiente.

2.3.7. Mtodos

En los mtodos se debe seguir el estndar verbo-sustantivo para asignar los nombres, donde

el verbo ha de estar en infinitivo. Se debern utilizar al menos dos palabras segn el mtodo

Pascal. Adems debe ser lo suficientemente significativo como para describir la accin que

realiza.


18/24


Ejemplo: uso del estndar verbo-sustantivopublic int CalcularEdad ()private int CalcularNomina ()

Hay que evitar usar nombres imprecisos o que permitan interpretaciones subjetivas

Ejemplo: nombre impreciso o ambiguopublic int AnalizarEsto ()

Si la lista de parmetros no cabe en una nica lnea, las siguientes deben estar indentadas

hasta la posicin en que comienza la lista de parmetros en la primera lnea

Ejemplo:

private void CalcularReducciones (int iTipo, bool bCeuta,string sTexto){

}

En los mtodos que devuelvan valores debe haber una nica sentencia return al final de la

misma, con un valor que se haya ido rellenando en el cuerpo del mtodo. Incluso si no se

devuelve ningn valor, es una buena prctica introducir al final un return sin datos

Ejemplo: uso de returnbool GetTipo (){

int iTipo; iTipo = Tipo.A; iTipo = Tipo.B;

return iTipo;}

Cuando se realicen sobrecargas de mtodos, todos deben llevar a cabo una funcin similar.

2.3.8. ClasesLos nombres de las clases deben seguir los conceptos bsicos de las funciones, anteponiendo

al nombre el prefijo correspondiente definido en el convenio de nombres de clases e interfaces

Ejemplo: nombres de clasesclass RaizCuadrada{

}

Como ya se ha comentado, en la medida de lo posible se debe respetar el que haya una nica

clase por archivo, cuyo nombre ser el propio de la clase.

Ejemplo: nombres de ficherosRaizCuadrada.csclass RaizCuadrada{}


19/24


2.3.9. InterfacesPara la creacin de interfaces se deben aplicar las mismas normas descritas para las clases,

aplicando su prefijo.

Ejemplo: definicin de interfaz

interface INuevoInterfaz{

}


20/24


2.4. OTRAS RECOMENDACIONES

Otras recomendaciones de inters son:

Est terminantemente prohibido el uso de goto, este comando derrumba los

principios bsicos de los lenguajes estructurados provocando saltos quedificultan la claridad y el mantenimiento del cdigo.

No se debe abusar de las sentencias de salida break, cont inue o exit,documentando su uso cuando se considere oportuno.

Cuando sea necesario el anidamiento de sentencias condicionales o derepeticin, ste no debe superar los cuatro niv eles. Si se requieren ms sedebe considerar la agrupacin en funciones.

Siempre que sea posible se debe reutilizar cdigo existente, ya sean libreras

o clases.

[] Hay siempre una sutil razn por la que los programadores siempre quieren desechar el

cdigo y empezar de nuevo. La razn es que piensan que el viejo cdigo es una ruina. Y aqu

est la observacin interesante: probablemente estn equivocados. La razn por la que piensan

que el viejo cdigo es una ruina es por una ley capital y fundamental de la programacin: Es

ms difcil leer cdigo que escribirlo.

El idioma de generacin de los nombres ser siempre el mismo, definido apriori.


21/24


2.5. MEJORA DE LA EFICIENCIA

Recordar que el cdigo debe ser mantenido.

Si la eficiencia del programa no es crtica sustituir instrucciones rpidas porinstrucciones comprensibles.

Si la eficiencia es importante (sistemas crticos o de tiempo real) y es necesarioutilizar expresiones no comprensibles y muy complicadas pero rpidas, aadircomentarios que ayuden a comprender el cdigo.

Reducir al mnimo las operaciones de entrada / salida.

Usar los operadores: ++, --, +=, -= , etc...

Cuando se pasan estructuras grandes a un subprograma, hacerlo porreferencia. Esto evita manipular datos sobre la pila y hace la ejecucin msrpida.

Evitar el abuso de las comparaciones con cadenas de texto. Expresiones deltipo sValor == abc son muy lentas. Es preferible usar el mtodo Equals(sValor.Equals(abc)) o las comparaciones por tamao si se quiere detectar sila cadena est vaca (sValor.Lenght == 0).


22/24


APNDICE A: NOMENCLATURA DE ESPACIOS DE NOMBRES

Es particularmente importante disear correctamente los nombres de los espacios denombres, para evitar el riesgo de hacer uso de un espacio de nombres idntico al queutiliza otra persona.

Si dos espacios de nombres con el mismo nombre se instalan en el mismo equipo, se

producir un conflicto de espacios. Microsoft recomienda utilizar nombres de espacios

que utilicen el esquema su ..


23/24


APNDICE B: EXCEPCIONES

Para el manejo de las excepciones se debe emplear el mecanismo propio dellenguaje: try -> catch -> finally.Es conveniente seguir un orden lgico y homogneo en la recogida de los errores. De

este modo, las excepciones en el bloque catch se capturarn en este orden: Excepciones de operacin

Excepciones especficas

Excepciones personalizadas

Excepciones genricas

Con el fin de homogeneizar los diferentes mensajes de cara a una estandarizacin de todos

ellos, se generar un documento XML en el que se especificarn los mensajes de error que se

pueden producir para un tratamiento mas genrico de la informacin capturada dentro de lasexcepciones.


24/24


APNDICE C: COMPATIBILIDAD CON OTROS LENGUAJES .NET

Para hacer que nuestro cdigo sea compatible con otros leguajes .NET se deben teneren cuenta los siguientes puntos.

C.1. USO DE MAYSCULAS Y MINSCULAS

Se debe tener cuidado con la distincin entre maysculas y minsculas. C# s lasdiferencia, por lo que es perfectamente vlido que dos nombres se diferenciennicamente porque algunas letras del primer nombre estn en maysculas, mientrasque las correspondientes del segundo estn en minsculas. Esto cobra importanciacuando los ensamblados son llamados desde otros lenguajes .NET, como VisualBasic, que no distingue entre maysculas y minsculas.De este modo, aunque no es aconsejable, si utiliza nombres que se diferenciannicamente por el uso de maysculas y minsculas, es importante hacerlo slo ensituaciones en las que ambos nombres no sean visibles fuera de la unidad delensamblado. De lo contrario, impedir que un cdigo escrito en VB .NET sea capaz deacceder correctamente a su unidad.

C.2. NOMBRES Y PALABRAS RESERVADAS

Es importante que los nombres no coincidan con palabras reservadas. Si coincide conlas C#, con total seguridad obtendr un error de sintaxis. Sin embargo, dado queexiste la posibilidad de que sus clases sean utilizadas desde cdigo escrito en otroslenguajes, es importante no utilizar palabras reservadas de stos.En general las palabras reservadas de C++ son muy similares a las palabrasreservadas de C#, por lo que una confusin entre ellas es poco probable.Por otro lado, es ms probable tener problemas con VB .NET, que tiene muchas ms palabras

reservadas que C#, y no podemos confiar en el estilo de nombres Pascal debido a que VB .NETno distingue entre maysculas y minsculas.

convencion de codigo c#

Documents