Manual Para Nombramiento y Mejores Prácticas en Visual.NET y ASP.NET

Manual Para Nombramiento y Mejores Prácticas en Visual.NET y ASP.NET.

www.gruposys.com email: [email protected]

Sistemas y Servicios De

Control Eléctrico

http://www.gruposys.com/

Tabla de contenido.

1. Naming Conventions......................................................................11.1. Pascal case........................................................................................................11.2. Camel case........................................................................................................11.3. Uppercase..........................................................................................................11.4. Local Variables.................................................................................................11.5. Namespaces.....................................................................................................11.6. Assemblies.........................................................................................................11.7. Class Naming Guidelines.............................................................................21.8. Classes and structure...................................................................................21.9. Collection classes............................................................................................21.10. Delegacion de clases....................................................................................21.11. Excepción de clases......................................................................................21.12. Atributos.............................................................................................................31.13. Unsealed Classes............................................................................................31.14. Base Classes for Implementing Abstractions.......................................31.15. Interfaces:..........................................................................................................31.16. Abstract Types and Interfaces...................................................................41.17. Enumeración:...................................................................................................41.18. Funciones y subs.............................................................................................41.19. Propiedades publicas * variables de miembros..................................41.20. Parametros:.......................................................................................................41.21. Passing Parameters........................................................................................51.22. Property Design...............................................................................................51.23. Constructor Design.........................................................................................51.24. Event Design.....................................................................................................51.25. Field Design......................................................................................................51.26. Operator Overloads........................................................................................61.27. Conversion Operators...................................................................................61.28. Protected Members........................................................................................71.29. Events and Callbacks....................................................................................72. Buenas practicas Visual.NET.........................................................82.1. Evita escribir métodos muy largos..........................................................82.2. El nombre del método debe de describir lo que el método realiza.............................................................................................................................82.3. Un método solo debe de realizar un trabajo........................................82.4. Usa los tipos (alias) específicos de c# o VB.NET, mas que los tipos definidos en el sistema de namespace...................................................92.5. Siempre observa los valores inesperados.............................................92.6. No realice numeraciones difíciles en el código.................................102.7. Comoquiera usar constantes no es tan recomendable.................102.8. Convertir las cadenas en lowercase o uppercase antes de comparar......................................................................................................................10

Manual Para Nombramiento y Mejores Prácticas en Visual.NET

y ASP.NET.

2.9. Evita usar variables de miembros..........................................................112.10. usar enum donde se requiere..................................................................112.11. No realizar las variables de miembro públicas o protegidas.......122.12. El manejador del evento no deberá contener el código para realizar la acción requerida..................................................................................122.13. No realizar por programación el clickeo de un botón para ejecutar la misma acción que has escrito en el evento al clickear el botón.............................................................................................................................122.14. Nunca dificultes un camino o el manejo de un nombre en el código............................................................................................................................122.15. Nunca asumas que tu código se correrá desde el driver “c:”.....122.16. En la aplicación de encendido, realizar algún tipo de “auto-chequeo”......................................................................................................................122.17. si el archivo de la configuración requerida no es encontrado.. . .122.18. Si algún valor equivocado es encontrado en el archivo de configuración..............................................................................................................122.19. El mensaje de error deberá de ayudar al usuario a resolver el problema......................................................................................................................122.20. Cuando se muestre un mensaje de error............................................132.21. Mostrar mensajes cortos y amistosos para el usuario...................132.22. No tener mas de una clase en un solo archivo.................................132.23. Tener tu propia firma para cada uno de los tipos de archivo......132.24. Evita tener archivos muy largos.............................................................132.25. Evita métodos y propiedades publicas.................................................132.26. Evita pasar muchos parámetros a un método..................................132.27. Si tienes un método que regresa una colección...............................132.28. Usar el archive AssemblyInfo...................................................................142.29. Organiza de manera lógica todos tus archivos en carpetas apropiadas...................................................................................................................142.30. Asegúrate de que tienes una buena clase de acceso....................142.31. Si estas abriendo conexiones a la base de datos.............................142.32. Declarar variables tan cercas como sea posible de donde se usara por primera ves.............................................................................................142.33. Usar la clase StringBuilder........................................................................142.34. Si tu comando tiene varias interacciones...........................................152.35. Considera las clases abiertas sin miembros virtuales o protegidos...................................................................................................................152.36. Considera el hacer clases abstractas base.........................................152.37. Considera la colocación de la clase base............................................162.38. Por definición las clases base son usadas..........................................162.39. Evita nombrar la clase bases...................................................................162.40. No provean abstracciones.........................................................................162.41. Escojan cuidadosamente entre una clase abstracta y una interfase.......................................................................................................................162.42. Probar una alternativa para los miembro............................................162.43. Evita hacer argumentos caros.................................................................162.44. Seguir las reglas de comandos para los Pointers cuando se diseñen estos.............................................................................................................16

Documento Confidencial. 3


y ASP.NET.

2.45. Evitar usar parámetros apagados o de referencia..........................162.46. No pasar los tipos de referencia por referencia................................162.47. No usar métodos expuestos.....................................................................162.48. No ser consistente en el nombramiento de parámetros...............172.49. Crear propiedades de solo lectura.........................................................172.50. Proveer valores sensibles predeterminados......................................172.51. Permitir que las propiedades sean acomodadas..............................172.52. Mantener el valor anterior si una propiedad nos regresa una excepción....................................................................................................................172.53. Evitar que se regresen excepciones para las propiedades de los compradores..............................................................................................................172.54. usar la terminología de aumento para eventos excepto FIRE o trigger...........................................................................................................................172.55. Usar System.EventHandler<T>..............................................................172.56. considerar usar una clase derivada de System.EventArgs...........172.57. No proveer campos que sean públicos o protegidos......................182.58. No utilizar campos constantes para constantes que nunca cambiaran....................................................................................................................182.59. Utilizar campos estáticos públicos.........................................................182.60. No asignar instancias de tipos mutables a campos de solo lectura...........................................................................................................................182.61. No proveer un operador de conversión................................................182.62. No definir operadores de conversión fuera del dominio de tipos.

182.63. No proveer un operador de conversión implícito.............................182.64. No mostrar excepciones para pruebas implícitas............................182.65. Considerar utilizar las llamadas de retorno........................................182.66. Considerar utilizar eventos.......................................................................182.67. Preferir eventos sobre las llamadas de regreso................................192.68. Evitar utilizar llamadas de regreso en performance-sensitive APIs. 193. ASP.NET........................................................................................203.1. Desactivar la sesión cuando no se este usando...............................203.2. El modelo in-proc de manejo de sesiones...........................................203.3. Minimizar la cantidad y complejidad de los datos guardados en una sesión...................................................................................................................203.4. Usar la transferencia de servidores para re direccional entre paginas.........................................................................................................................203.5. Escoger el mejor estado de satisfacción por sesión........................203.6. Evitar los viajes redondos hacia el codigo-servidor.........................203.7. Usar paginas IsPostBack............................................................................203.8. Usar los controles de servidor en las circunstancias apropiadas

203.9. Salvar los controles de servidor..............................................................213.10. Buffering es una opción predeterminada............................................213.11. No delegar excepciones en el código...................................................213.12. Usar el almacenaje temprano en VB.NET y en el código de Jscript............................................................................................................................21



y ASP.NET.

3.13. Puerto de llamadas intensivas COM......................................................213.14. Libera los objetos COM o los recursos nativos..................................223.15. Utilizar los servidores SQL .......................................................................223.16. Usar la clase SQLDataReader..................................................................223.17. Datagrid...........................................................................................................223.18. Desactivar el modo de ajustes antes de desplegar la aplicación.

223.19. Para aplicación que confíen extensibilidad a una fuente externa

223.20. Enumerar en las colecciones es algunas veces mas caro que indicar el acceso en un lazo.................................................................................223.21. Jscript.NET........................................................................................................223.22. Realizar un pre hornada de compilación.............................................233.23. Evitar hacer cambios a páginas o a asambleas................................233.24. El archivo de configuración esta configurado para permitir el más amplio juego de rasgos................................................................................233.25. Codificar-solicitudes/respuestas- los prediseñados son UTF-8 codificados..................................................................................................................233.26. Estado de sesión- por default se encuentra encendido.................233.27. Estado de observación................................................................................233.28. AutoEventWireup- apagalo.AutoEventWireup...................................233.29. Para una eficiente eliminación de fallas..............................................234. Bibliografía:..................................................................................24



y ASP.NET.

1. Naming ConventionsEl esquema de nombramiento facilita el desarrollo de librerías para los marcos de .NET.Al crear grupos jerárquicos con tipos de nombres de una forma consistente. Se espera que los desarrolladores de librerías usen la siguiente guía cuando creen los nombres para sus Namespaces.

1.1. Pascal case

La primera letra en el identificador y la primera letra de cada una de las palabras contenidas deben de ser mayúscula. Puedes usar Pascal Case como identificadores para palabras de tres o más letras. Por ejemplo:BackColor.

1.2. Camel case

La primer letra de un identificador es minúscula y la primer letra de casa palabra subsecuentemente encadenada será mayúscula. Por ejemplo backColor

1.3. Uppercase

Todas las letras en el identificador son mayúsculas. Usa esta regla solo para identificadores que consistan en dos o pocas letras. Por ejemplo:System.IO System.Web.UI

1.4. Local Variables

Prefijo privado o variable local con el estilo de notación húngaro.Usar Camel case como regla general, o Uppercase para una palabra muy pequeña.Ejemplo:strFirstName, dsetEmployees

1.5. Namespaces

Caso pascal, Usar el nombre de la compañía CompanyName. TechnolgyName como base. Si no cuenta con una compañía, use su nombre o sus iniciales. Nótese que cualquier acrónimo de mas de 3 letras debe de ser un caso pascal (Xml en lugar de XML).Porque?: esta medida trabaja con .NET y simplifica su lectura, al utilizar el nombre de la compañía o su nombre evita la posibilidad de que existan dos Namespace con el mismo nombre.Ejemplo.AppliedIS.TimeCard.BusinessRulesIrritatedVowel.ControllersPeteBrown.DotNetTraining.InheritanceDemo PeteBrown.DotNetTraining.Xml

1.6. Assemblies

Si la asamblea contiene un solo espacio en el nombre o tiene una entrada que la contiene en el namespace raíz, nombrar la asamblea con el nombre del namespacePorque? Esta medida trabaja con .NET y es fácil de leer. Pero lo mas importante es que mantiene el nombre del assembly y del namespace alineados, haciendo



y ASP.NET.

realmente fácil la identificación de que es en particular cada assembly y cual assambly necesitas para referenciar a cada clase Ejemplo:AppliedIS.TimeCard.BusinessRules.dllIrritatedVowel.Controllers.dll

1.7. Class Naming Guidelines

Use un sustantivo o una frase para nombrar la clase.No usar prefijos como C para “C”lass en el nombre de la clase.No usar el carácter para subrayar.(_)

1.8. Classes and structure.

Caso pascal, no subraya o administra "C" ni "Cls"., las clases pueden empezar con "i" solo si la letra que le sigue no esta en mayúscula de otra forma parecería una interfase , las clases no deben de tener el mismo nombre que el namaspace en el cual están ubicadas. Cualquier acrónimo de mas de tres letras debe de ser caso pascal, no todas deben de ser mayúsculas, trata de evitar abreviaciones y tratar de siempre usar sustantivosPorque?: esta medida trabaja con .NET y simplifica su lectura.Ejemplo:WidgetInstanceManagerXmlDocumentMainFormDocumentFormHeaderControlCustomerListDataSet

1.9. Collection classes

Seguir la estructura de nombramiento, pero agregarle la palabra Collecton al final del nombre.Porque?: esta medida trabaja con .NET y simplifica su lectura.Ejemplo:WidgetCollection

1.10. Delegacion de clases.

Seguir la estructura de nombramiento, pero agregarle la palabra Delegate al final del nombre.Porque?: esta medida trabaja con .NET y simplifica su lectura.Ejemplo:WidgetCallbackDelegate

1.11. Excepción de clases.

Seguir la estructura de nombramiento, pero agregar la palabra Exception al final del nombre.Porque?: esta medida trabaja con .NET y simplifica su lectura.Ejemplo:InvalidTransactionException



y ASP.NET.

1.12. Atributos.

Seguir la estructura de nombramiento, pero agregarle Attribute al final del nombre Porque?: esta medida trabaja con .NET y simplifica su lectura.Ejemplo:WebServiceAttribute

1.13. Unsealed Classes

Una clase abierta permite que otras clases puedan heredar desde esta. Muchos de los otros mecanismos de extensibilidad, como los protectores y los miembros virtuales, requieren que las clases sean abiertas. Estos mecanismos adicionales agregar poderosas formas de agregar o personalizar los tipos de funcionalidades, pero no sin un costo significativo. Una clase abierta puede ser usada en muchos escenarios de desarrollo, incluso sin los mecanismos de extensibilidad.

1.14. Base Classes for Implementing Abstractions

Las clases base para implementar abstracciones son clases que fueron diseñadas para asistir a los desarrolladores en la implementación de clases abstractas e interfaces. Estas proveen algunos de los detalles de implementación para abstracciones y en algunos casos pueden llegar a ser utilizadas sin herencia. Por ejemplo, Collection puede ser usada para crear una colección o puede ser heredada para definir un tipo mas fuerte de clase Collection.El siguiente ejemplo de código demuestra el uso de la clase Collection para crear un tipo mas fuerte de objeto de la clase Collection.public class PointManager : IEnumerable{ Collection<Point> pointCollection = new Collection<Point>();

public void AddPoint(Point p) { pointCollection.Add(p); } public bool RemovePoint(Point p) { return pointCollection.Remove(p); } public IEnumerator GetEnumerator() { return pointCollection.GetEnumerator(); }}

1.15. Interfaces:

Seguir la estructura de nombramiento, pero empezar el nombre con "I" y poner la letra que le sigue en mayúscula. Porque? Esta medida trabaja con .NET y simplifica su lectura. También ayuda a distinguir entre clases e interfaces donde pudiera haber una equivocación, esto evita que existan equivocaciones con los nombres, es algo común tener IFoo y una clase llamada Foo que implemente IFoo. Ejemplo:IWidget.



y ASP.NET.

1.16. Abstract Types and Interfaces

Los tipos abstractos e interfaces son ambos mecanismos para especificar abstracciones programadas. Una abstracción especifica un contacto que los herederos o implementadotes deben de agregarle. Los tipos abstractos tienen la opción de proveer detalles de implementación; las interfaces no pueden proveer ningún detalle de implantación.

1.17. Enumeración:

Seguir la estructura de nombramiento, NO agregar "Enum" al final del nombre, si la enumeración representa un grupo de bitwise flags, terminar el nombre con plural. Porque?: esta medida trabaja con .NET y simplifica su lectura.Ejemplo:SearchOptions (bitwise flags)AcceptRejectRule (normal enum)

1.18. Funciones y subs

Caso pascal, no subraya excepto en el comando del evento. Trata de evitar abreviaciones, muchos programadores tienen el mal hábito de abreviar todo, esto debería de ser corregido.Las funciones y subs deben de diferenciarse por mas casos para ser usados en lenguajes insensibles como Visual Basic .NETPorque?: esta medida trabaja con .NET y simplifica su lectura.Ejemplo:VB: Public Sub DoSomething(...)C#: public void DoSomething(...)

1.19. Propiedades publicas * variables de miembros

Caso pascal, tratar de no usar abreviaciones, los miembros deben de diferir para reconocer por mas de un caso utilizable en lenguajes de insensibilidad de casos como en lenguajes como visual Basic .NETPorque?: esta medida trabaja con .NET y simplifica su lectura.Ejemplo:VB: Public Property RecordID As IntegerC#: public int RecordID

1.20. Parametros:

Caso Camel. Tratar de evitar las abreviaciones. Los parámetros deben de diferir en mas casos para ser usados en casos insensibles en lenguajes como visual Basic .NETPorque?: esta medida trabaja con .NET y simplifica su lectura.Ejemplo:VB: ByRef recordID As IntegerC#: ref int recordID• Pointer Parameters Los pointers son avanzadas formas de programación que solo deberían de ser usadas en situaciones críticas. Los pointers permiten acceso lógico a la memoria.

1.21. Passing Parameters

Los métodos de parámetro, pueden ser pasador por valor, referencia o como nuestros parámetros, cuando un parámetro es pasado por valor, el método obtiene una copia de los datos del que mando llamar al parámetro y esta copia no puede



y ASP.NET.

ser modificada. Cuando un parámetro es pasado por referencia el método obtiene un pointer para el que mando llamar al parámetro, estos datos son compartidos con el que realizo el llamado. Si el método realiza cambios a un parámetro referenciado los cambios son hechos a los datos de que lo mando llamar, cuando se usa un parámetro referenciado el estado inicial del dato puede ser usado por el método. Un parámetro apagado es similar a uno referenciado excepto que un parámetro apagado es usado exclusivamente para devolver los datos del que realizo el llamado, mientras que los parámetros referenciados pueden ser usados para pasar datos al método también puede ser usado para recibir datos del método.

1.22. Property Design

En general los métodos representan acciones y las propiedades representan datos. Las propiedades son usadas como campos, significando que las propiedades no deben de ser computacionalmente complejas o producir efectos secundarios.

1.23. Constructor Design

Los constructores son métodos especiales usados para inicializar tipos y crear instancias de tipos. Un tipo de constructor es usado para inicializar datos estadios en un tipo. Un tipo de constructor es llamado por el lenguaje común del runtime (CLR) antes de que este tipo de constructor sea creado. Los tipos de constructores son estáticos y no pueden tomar parámetros. Una instancia del constructor es usada para crear tipos de instancias. Estas pueden tomar parámetros pero no es requerido que hagan esto. Una instancia de constructor sin parámetros es llamada como un constructor default.

1.24. Event Design

Los eventos son mecanismos que permiten aplicaciones específicas de código para ejecutar cuando ocurra una acción. Los eventos pasan incluso antes de que la acción asociada suceda (pre-eventos) o después de que la acción ocurra (post-event) por ejemplo cuando un usuario da clic en una ventana un post-event se ejecuta permitiendo a algún método especifico ser ejecutado. Un manejador de eventos esta atado al método para ser ejecutado cuando el sistema ejecuta un evento. El manejador de eventos es agregado al evento entonces eso permite invocar el método cuando el evento se ejecute. Los eventos pueden tener datos específicos.La firma del método manejador de eventos es idéntica a la firma del delegador de eventos. La firma del manejador de eventos sigue los siguientes características.El dato de regreso es Void.El primer parámetro es llamado Sander y su tipo es de objeto. Este es el objeto que ejecuta el evento.El Segundo parámetro es nombrado e y su tipo es EventArgs o algún derivado de la clase EventArgs. Este es el evento que especifica el dato.El método toma exactamente dos parámetros.

1.25. Field Design

Campos de datos asociados a objetos. En la basta mayoría de los escenarios cualquier campo no estático en una librería no debe de ser visible para los desarrolladores.

1.26. Operator Overloads

El operador de sobrecargas permite que los tipos sean combinados y comparados usando operadores tales como "+", "-", "=" y "!=". al añadir un operador de sobrecargas a un tipo tu permites a los desarrolladores usar el tipo aunque haya



y ASP.NET.

sido construido en un tipo mas primitivo. El operador de sobre cargas solo debe de ser hecho cuando el significado de la operación puede ser intuida por el tipo, el operador de sobrecargas no debe de ser usado para proveer atajos para operadores no intuitivos.La siguiente tabla contiene una lista de operadores simbólicos y su correspondiente método alternativo y el nombre del operador.

C# operator symbol Name of alternative method Name of operator Not defined ToXxx or FromXxx op_ImplicitNot defined ToXxx or FromXxx op_Explicit+ (binary) Add op_Addition- (binary) Subtract op_Subtraction* (binary) Multiply op_Multiply/ Divide op_Division% Mod op_Modulus^ Xor op_ExclusiveOr& (binary) BitwiseAnd op_BitwiseAnd| BitwiseOr op_BitwiseOr&& And op_LogicalAnd|| Or op_LogicalOr= Assign op_Assign<< LeftShift op_LeftShift>> RightShift op_RightShiftNot defined LeftShift op_SignedRightShiftNot defined RightShift op_UnsignedRightShift== Equals op_Equality> CompareTo op_GreaterThan< CompareTo op_LessThan!= Equals op_Inequality>= CompareTo op_GreaterThanOrEqual<= CompareTo op_LessThanOrEqual*= Multiply op_MultiplicationAssignment-= Subtract op_SubtractionAssignment^= Xor op_ExclusiveOrAssignment<<= LeftShift op_LeftShiftAssignment%= Mod op_ModulusAssignment+= Add op_AdditionAssignment&= BitwiseAnd op_BitwiseAndAssignment|= BitwiseOr op_BitwiseOrAssignment, Comma op_Comma/= Divide op_DivisionAssignment-- Decrement op_Decrement++ Increment op_Increment- (unary) Negate op_UnaryNegation+ (unary) Plus op_UnaryPlus~ OnesComplement op_OnesComplement

1.27. Conversion Operators

Conversión de operadores, convertir un objeto desde un tipo a otro tipo, los operadores de conversión pueden ser implícitos o explícitos. Los implícitos no requieren que sea un tipo específico para su llamado en el código fuente para realizar la conversión. Los operadores de conversión explicita requieren que el tipo de ejecutador este presente en el código fuente para realizar la conversión.



y ASP.NET.

1.28. Protected Members

Miembros protegidos en clases abiertas les da a los desarrolladores una forma de personalizar las clases. Por ejemplo los métodos que ejecutan eventos son comúnmente definidos al tener visibilidad protegida para permitir a las clases derivadas procesos adicionales antes o después de que el evento se ejecute.

1.29. Events and Callbacks

Un evento de llamado de regreso es un método que es automáticamente invocado por un delegador cuando una operación o actividad se completa. Por ejemplo, uno de los diseños asincrónicos utiliza AsyncCallback delegando específicamente el código que ejecute cuando una operación asincrónica se complete. Este tipo de diseños es usado en el método BeginWrite, el cual usa las llamadas de regreso para procesar el resultado de una operación de escritura asincrónica. Los eventos son mecanismos similares a las llamadas de regreso, los eventos permiten a los usuarios especificar el código a ejecutar bajo una condición especifica, usualmente envuelven un estado de cambio o el inicio o fin de una actividad. Los eventos son mas fáciles de usar que las llamadas de regreso por que la sintaxis del lenguaje y las herramientas provén una experiencia de código uniforme para reconocer y manejar eventos. También los eventos son manejados por delegadotes llamados manejadores de eventos que tienen una firma bien definida.



y ASP.NET.

2. Buenas practicas Visual.NET

2.1. Evita escribir métodos muy largos.

Un método típicamente debe tener entre 1-25 líneas de código. Si un método tiene mas de 25 líneas de código, debes de considerar reconstruirlo en diferentes métodos.

2.2. El nombre del método debe de describir lo que el método realiza.

No utilizar nombres confusos. Si el nombre del método es obvio no abra necesidad de realizar documentación para explicar que es lo que realiza el método.

Correcto:

void SavePhoneNumber ( string phoneNumber ){// Salva el numero de teléfono.}

incorrecto:

// Este método salvara el numero de teléfono.void SaveDetails ( string phoneNumber ){// salva el numero de teléfono.}

2.3. Un método solo debe de realizar un trabajo.

No combinen mas de un trabajo en un solo método , incluso si estos trabajos son muy pequeños .

Correcto: // Salva la dirección.SaveAddress ( address );

// Envía un Email al supervisor para informarle que la dirección a sido actualizada.SendEmail ( address, email );

void SaveAddress ( string address ){// Salva la dirección.// ...}

void SendEmail ( string address, string email ){



y ASP.NET.

// envía un email para informar al supervisor que la dirección ha sido cambiada.// ...}

Incorrecto:

// Salva la dirección y manda un email al supervisor para informar //que la dirección a sido actualizada.SaveAddress ( address, email );void SaveAddress ( string address, string email ){// Trabajo 1.// Salvar la dirección.// ...

// Trabajo 2.// envía un email para informar al supervisor que la dirección a cambiado.// ...}

2.4. Usa los tipos (alias) específicos de c# o VB.NET, mas que los tipos definidos en el sistema de namespace.

int age; (not Int16)string name; (not String)object contactInfo; (not Object)

Algunos desarrolladores prefieren usar los tipos mas comunes en el sistema de tipos que especificar alias para los lenguajes.

2.5. Siempre observa los valores inesperados.

por ejemplo, si estas usando un parámetro con dos posibles valores, nunca asumas que si uno no concuerda entonces el otro valor es la única posibilidad.

Correcto:If ( memberType == eMemberTypes.Registered ){// Usuario registrado… hacer algo…}else if ( memberType == eMemberTypes.Guest ){// Usuario invitado... hacer algo…}else{// Usuario inesperado tipo. Lanza una excepción throw new Exception (“Un expected value “ + memberType.ToString() + “’.”)

// si nosotros introducimos un nuevo usuario type en el futuro, //nosotros podremos fácilmente encontrar el problema.



y ASP.NET.

}

Incorrecto:If ( memberType == eMemberTypes.Registered ){// Usuario registrado… hacer algo…}else{// Usuario invitado... hacer algo…

// si nosotros introducimos otro usuario Type en el futuro el código //fallara y esto no será notado.

}

2.6. No realice numeraciones difíciles en el código.

Usar constantes en su lugar, declarar constantes al iniciar el archivo y utilizarlas en el código.

2.7. Comoquiera usar constantes no es tan recomendable.

Debes de usar las constantes que están en el archivo de configuración o en la base de datos estas tu puedes cambiarlas después, declararlas como constantes solo si estas seguro que el valor nunca será cambiado. No realizar cadenas complejas. Utilizar los recursos del sistema

2.8. Convertir las cadenas en lowercase o uppercase antes de comparar.

Esto asegurara que la cadena encaje incluso si la cadena esta siendo comparada en un caso diferente.

if ( name.ToLower() == “john” ){//…}Use String.Empty instead of “”

Correcto:If ( name == String.Empty ){// Has algo}

Incorrecto:If ( name == “” ){// Has algo}

2.9. Evita usar variables de miembros.



y ASP.NET.

Declarar variables locales cuando sea necesario y pasarla a otro método en lugar de compartir una variable miembro entre varios métodos. Si compartes las variables de miembro entre métodos, será difícil ver que método cambia el valor y cuando.

2.10. usar enum donde se requiere.

No utilizar números o cadenas para indicar valores discretos.

Correcto: enum MailType{Html,PlainText,Attachment}void SendMail (string message, MailType mailType){switch ( mailType ){case MailType.Html:// Realizar algobreak;case MailType.PlainText:// Realizar algobreak;case MailType.Attachment:// Realizar algobreak;default:// Realizar algobreak;}}

Incorrecto: void SendMail (string message, string mailType){switch ( mailType ){case "Html":// Realizar algobreak;case "PlainText":// Realizar algobreak;case "Attachment":// hacer algo.break;default:// Realizar algo.break;}}



y ASP.NET.

2.11. No realizar las variables de miembro públicas o protegidas.

Mantenerlas privadas y exponer propiedades publicas/protegidas.

2.12. El manejador del evento no deberá contener el código para realizar la acción requerida.

Entonces llamar a otro método del manejador de eventos.

2.13. No realizar por programación el clickeo de un botón para ejecutar la misma acción que has escrito en el evento al clickear el botón.

Mejor llama al mismo método que es llamado por el manejador del evento click.

2.14. Nunca dificultes un camino o el manejo de un nombre en el código.

Obtén el camino de la aplicación programada y usa caminos relativos.

2.15. Nunca asumas que tu código se correrá desde el driver “c:”

No puedes saber si algunos usuarios lo corren desde alguna red o desde “z:”

2.16. En la aplicación de encendido, realizar algún tipo de “auto-chequeo”.

Asegurarse que todos los archivos requeridos y las dependencias están disponibles en las locaciones esperadas. Checar la conexión con la base de datos al realizar el auto-chequeo, mostrar un mensaje amistoso al usuario en caso de algún problema.

2.17. si el archivo de la configuración requerida no es encontrado.

La aplicación deberá de poder crear uno con los valores predeterminados.

2.18. Si algún valor equivocado es encontrado en el archivo de configuración

la aplicación deberá de lanzar un error o mostrar un mensaje y deberá de decirle al usuario cuales son los valores correctos.

2.19. El mensaje de error deberá de ayudar al usuario a resolver el problema



y ASP.NET.

Nunca mostrar un mensaje de error que diga “error en la aplicación” “existe un error” etc. En lugar de esto mostrar un mensaje específico como “error al actualizar la base de datos, por favor asegúrese de que su Usuario y Contraseña son correctos”.

2.20. Cuando se muestre un mensaje de error

Acompañado del mensaje que muestre el error el mensaje también debe decir que debe de realizar el usuario para resolver el problema. En lugar de un mensaje como “error al actualizar la base de datos” sugiera que es lo que el usuario debe de hacer “error al actualizar la base de datos, por favor asegúrese de que su Usuario y Contraseña son correctos”

2.21. Mostrar mensajes cortos y amistosos para el usuario.

Pero guardar el error actual con toda la información posible, esto ayudara a diagnosticar problemas.

2.22. No tener mas de una clase en un solo archivo.

2.23. Tener tu propia firma para cada uno de los tipos de archivo

En visual Studio. Puedes incluir el nombre de tu compañía, información de derechos de autor etc. Puedes ver o editar el archivo de firmas en la carpeta c:\Program Files\Microsoft VisualStudio8\Common7\IDE\ItemTemplatesCache\CSharp\1033.

2.24. Evita tener archivos muy largos

si un solo archivo tiene mas de 1000 líneas de código, es un buen candidato para la reconstrucción. Divídelos lógicamente en dos o mas clases

2.25. Evita métodos y propiedades publicas

Amenos que estas de verdad necesiten ser accedidas de fuera de estas clases. Usa “internas” si estas son accedidas solo con la misma asamblea.

2.26. Evita pasar muchos parámetros a un método.

Si se tiene mas de 4-5 parámetros es un buen candidato para definir una clase o estructura.

2.27. Si tienes un método que regresa una colección

Regresando una colección bacía en lugar de nula, si no tienes datos de regreso. Por ejemplo si tienes un método regresando una ArrayList, siempre regresa una ArrayList ,si no tienes datos de regreso, entonces regresa un ArrayList con 0 datos,



y ASP.NET.

esto lo ara mas fácil para la aplicación de llamada, solo checar el “contador” en ves de realizar un chequeo adicional para null.

2.28. Usar el archive AssemblyInfo

Para llenar información como el numero de versión, descripción, nombre de la compañía, derechos de autos etc.

2.29. Organiza de manera lógica todos tus archivos en carpetas apropiadas.

Usa dos niveles de descendencia. Puedes tener hasta 10 carpetas en la carpeta raíz y cada carpeta puede tener hasta 5 sub carpetas. Si tienes muchas carpetas que no se pueden acomodar en los 2 niveles de descendencia, tal vez necesites reconstruirlo en múltiples asambleas.

2.30. Asegúrate de que tienes una buena clase de acceso

La cual puede ser configurada para errores, advertencias o rastros de acceso. Si la configuras para registrar errores solo deberá de registrar errores, pero si la configuras para registrar rastros deberá de registrar todo (errores, advertencias y rastros). Tu clase de acceso deberá de estar escrita de tal forma que en el futuro puedas cambiar fácilmente el acceso a acceso de eventos de Windows, SQL Server, o cuentas de correo electrónico, administrador o a un archivo etc. sin realizar ningún cambio en ninguna parte de la aplicación. Usa la clase de registro extensivamente a través del código para grabar errores, advertencias y rastros de eventos, mensajes que puedan ayudar a resolver problemas.

2.31. Si estas abriendo conexiones a la base de datos

Archivos del sistema etc., siempre ciérralos en el bloque final . Esto asegurara que si algún evento o excepción sucede después de abrir la conexión será cerrada con seguridad en el bloque final

2.32. Declarar variables tan cercas como sea posible de donde se usara por primera ves.

Usa una variable de declaración por línea

2.33. Usar la clase StringBuilder

en lugar de encadenar cuando tienes que manipular cadena de objetos. Los objetos encadenados trabajan en una forma rara en .NET. cada ves que tu usas una cadena es descartada la cadena de objetos vieja y recreando una nueva cadena de objetos. Lo que es una operación relativamente cara.

Considera el siguiente ejemplo:

public string ComposeMessage (string[] lines)



y ASP.NET.

{ string message = String.Empty;

for (int i = 0; i < lines.Length; i++) { message += lines [i]; }

return message;}

En el ejemplo pasado, parece que solo estamos utilizando la cadena al objeto “mensaje”. Pero lo que esta sucediendo es en realidad que la cadena del objeto descarto cada una de las interacciones y recreando y atendiendo la línea hasta esto.

2.34. Si tu comando tiene varias interacciones

entonces es una buena idea usar la clase StringBuilder en lugar de encadenar objetos.Analiza el ejemplo donde el objeto encadenado es remplazado con StringBuilder.

public string ComposeMessage (string[] lines){ StringBuilder message = new StringBuilder();

for (int i = 0; i < lines.Length; i++) { message.Append( lines[i] ); }

return message.ToString();}

2.35. Considera las clases abiertas sin miembros virtuales o protegidos.

Como una gran forma para proveer extensibilidad a esquemas sin costo y de mucho valor.

2.36. Considera el hacer clases abstractas base

Incluso si estas no contienen ningún miembro abstracto. Esto claramente comunica solo al usuario para el cual esta diseñado que la clase sea heredada.

2.37. Considera la colocación de la clase base

en un Namespace separado del escenario separado APIs

2.38. Por definición las clases base son usadas.



y ASP.NET.

para extensiones avanzadas de escenarios y no son de gran interés para la mayoría de los usuarios.

2.39. Evita nombrar la clase bases

Con los sufijos base si la clase será usada en APIs públicos.

2.40. No provean abstracciones

Amenos que estas estén probadas por los desarrolladores que concretaron la implementación y los APIs que utilizan la abstracción.

2.41. Escojan cuidadosamente entre una clase abstracta y una interfase

Cuando diseñen una abstracción consideren proveer pruebas referenciadas para concretar la implementación de las abstracciones. Estas pruebas deben de permitir a los usuarios probar correctamente cualquiera de sus implementaciones.

2.42. Probar una alternativa para los miembro

Que toman argumentos de los pointers, como los pointer no son copiladores-Cls.

2.43. Evita hacer argumentos caros.

chocando los argumentos de los pointers.

2.44. Seguir las reglas de comandos para los Pointers cuando se diseñen estos.

2.45. Evitar usar parámetros apagados o de referencia.

2.46. No pasar los tipos de referencia por referencia.

2.47. No usar métodos expuestos.

públicamente que tomen pointer, series de pointer o series multidimensionales como parámetros.

2.48. No ser consistente en el nombramiento de parámetros

cuando se anulen miembros o se implementen los miembros de las interfaces.

2.49. Crear propiedades de solo lectura



y ASP.NET.

si el que realiza el llamado no esta habilitado para realizar cambios en los valores de las propiedades.

2.50. Proveer valores sensibles predeterminados

para todas las propiedades, asegurando que estos no resulten en un diseño ineficiente.

2.51. Permitir que las propiedades sean acomodadas

en el orden de los eventos si estos resultan en un estado temporal inválido para objetos.

2.52. Mantener el valor anterior si una propiedad nos regresa una excepción.

2.53. Evitar que se regresen excepciones para las propiedades de los compradores.

2.54. usar la terminología de aumento para eventos excepto FIRE o trigger.

2.55. Usar System.EventHandler<T>.

en lugar de usar la creación manual de nuevas delegaciones para ser usadas como manejador de eventos

2.56. considerar usar una clase derivada de System.EventArgs

como el argumento del evento, amenos que estés absolutamente seguro que el evento no acarreara ningún dato para el método manejador de datos, en tal caso tu puedes usar System.EventArgs directamente.



y ASP.NET.

2.57. No proveer campos que sean públicos o protegidos.

2.58. No utilizar campos constantes para constantes que nunca cambiaran.

2.59. Utilizar campos estáticos públicos

solo lectura para instancias de objetos predefinidas.

2.60. No asignar instancias de tipos mutables a campos de solo lectura.

2.61. No proveer un operador de conversión

en tal caso que la conversión no este claramente esperada por el usuario final.

2.62. No definir operadores de conversión fuera del dominio de tipos.

2.63. No proveer un operador de conversión implícito.

si la conversión es potencialmente incomprendida.

2.64. No mostrar excepciones para pruebas implícitas.

2.65. Considerar utilizar las llamadas de retorno

para permitir a los usuarios proveer de código personalizado para ser ejecutado por el Framework.

2.66. Considerar utilizar eventos.

Para permitir al usuario personalizar el comportamiento del FrameWork son la necesidad de que el usuario entienda la orientación del objeto.



y ASP.NET.

2.67. Preferir eventos sobre las llamadas de regreso

Así como estas están más familiarizadas a un rango de desarrollo e integración con el estado de complejidad de visual Studio.

2.68. Evitar utilizar llamadas de regreso en performance-sensitive APIs.



y ASP.NET.

3. ASP.NET

Los siguientes son algunos de los consejos para crear una buena aplicación en ASP.NET.

3.1. Desactivar la sesión cuando no se este usando.

Esto puede ser hecho en el nivel de la aplicación en el archivo “configuración de la maquina” o a un nivel de pagina.

3.2. El modelo in-proc de manejo de sesiones.

Es la mas rápida de las tres opciones. La opción SQL tiene el golpe mas alto de rendimiento.

3.3. Minimizar la cantidad y complejidad de los datos guardados en una sesión.

Entre mas largos y complejos sean los datos el costo para seriarlos será mas costoso (para SQL servers y para la opción de estados de servidores)

3.4. Usar la transferencia de servidores para re direccional entre paginas

En la misma aplicación esto evitara la redirección innecesaria de los clientes.

3.5. Escoger el mejor estado de satisfacción por sesión

En el proceso es la opción mas rápida.

3.6. Evitar los viajes redondos hacia el codigo-servidor

Como la validación de usuarios de entrada puede ser manejado por el mismo cliente.

3.7. Usar paginas IsPostBack.

Para evitar procesos in necesarios en un viaje redondo.

3.8. Usar los controles de servidor en las circunstancias apropiadas

Incluso aunque estas sean muy fáciles de implementar son muy caras por los recursos del servidor, algunas veces es mas fácil usar simple interpretación o almacenaje de datos.ç



y ASP.NET.

3.9. Salvar los controles de servidor.

observar el estado del servidor solo cuando sea necesario.

3.10. Buffering es una opción predeterminada.

Apagarla disminuirá el funcionamiento. No codificar cadenas para respuestas del buffering. La escritura hará que automáticamente se almacene cualquier respuesta sin la necesidad de que el usuario lo haga. Utiliza múltiples respuestas. Escribirlas es mejor que crear cadenas por encadenamiento especialmente si las cadenas son largas.

3.11. No delegar excepciones en el código.

Las excepciones reducen el funcionamiento. No coger la excepción por si misma antes de manejar la condición.

// considerando cambiar esto...try { result = 100 / num;}catch (Exception e) { result = 0;}// to this...if (num != 0) result = 100 / num;else result = 0;

3.12. Usar el almacenaje temprano en VB.NET y en el código de Jscript.

Permite opciones estrictas en la pagina directamente para asegurar que el tipo seguro de programación se sigue.

3.13. Puerto de llamadas intensivas COM.

Componentes para manejar código mientras se realiza interoperabilidad se trata de evitar muchas llamadas. El costo de ordenar los datos en rangos es relativamente barato hasta el mas caro como lo es el encadenamiento, un tipo común de datos cambiado por aplicaciones web puede ser caro por que las cadenas en CLR estas en unicode pero COM o los métodos nativos tal vez requieran otro tipo de datos de código.

3.14. Libera los objetos COM o los recursos nativos.

tan pronto como el uso termine. Esto almacenara otra petición para utilizarlos para reducir el funcionamiento de las peticiones, tanto como tener el GC liberando en un punto tardío.



y ASP.NET.

3.15. Utilizar los servidores SQL .

para almacenar procedimientos para acceso a los archivos.

3.16. Usar la clase SQLDataReader.

para un rápido reenvió de cursores de datos.

3.17. Datagrid.

es una forma rápida de mostrar los datos, pero alenta la aplicación. La otra alternativa la cual es mas rápida es la interpretaron de los datos para casos simples. Pero esto es difícil de mantener, una solución mediana puede ser un control de repetición el cual es ligero, eficiente, personalizadle y programable

3.18. Desactivar el modo de ajustes antes de desplegar la aplicación.

3.19. Para aplicación que confíen extensibilidad a una fuente externa

Considerar permisos de multiprocesadores de computadoras, el modelo de proceso de ASP.NET ayuda a habilitar escalabilidad para distribuir trabajo para diversos procesos, uno de cada uno CPU. Si la aplicación esta usando una base de datos de servidores lenta o llamadas de objetos COM que accedan a recursos externos la aplicación web puede ser una buena solución.

3.20. Enumerar en las colecciones es algunas veces mas caro que indicar el acceso en un lazo.

Esto es por que el CLR puede ser algunas veces optimizar una serie de índices y limites de chequeo en lazos, pero no puede detectarlos en cada uno de los tipos de código.

3.21. Jscript.NET

Permite métodos dentro de métodos para implementar esto en CLR requieres maquinas mas experimentada las cuales pueden ser mucho mas lentas entonces evita que muevan métodos innecesarios para que tengan solo los métodos necesarios de la pagina.

3.22. Realizar un pre hornada de compilación.

para archivar esto solicita una página del sitio.

3.23. Evitar hacer cambios a páginas o a asambleas.



y ASP.NET.

que estén en el directorio raíz de la aplicación. Una página cambiada solo recopilara la pagina, cualquier cambio en el directorio raíz resultara en una recopilación de toda la aplicación.

3.24. El archivo de configuración esta configurado para permitir el más amplio juego de rasgos.

Para un funcionamiento de empuje es mejor afinarlo a los requerimientos algunos puntos clave son:

3.25. Codificar-solicitudes/respuestas- los prediseñados son UTF-8 codificados.

Si el sitio complementa ASCII cambia de opción a ASCII codificador.

3.26. Estado de sesión- por default se encuentra encendido.

Si el estado de sesión no esta mantenido el estado deberá de ser cambiado a Apagado.

3.27. Estado de observación

Por default esta encendido, apágalo si no esta siendo utilizado, si el estado de observación esta siendo utilizado entonces existen diferentes niveles de seguridad que necesitas considerar los cuales pueden tener un impacto en el funcionamiento de la aplicación.

3.28. AutoEventWireup- apagalo.AutoEventWireup.

Significa que la pagina no tratara ni encajara el nombre de los métodos a eventos y tampoco los recibirá, en cambio si la aplicación escribe deseos para recibirlos, estos necesitan anular los métodos en la clase base. Realizando esto la página recibirla señales de funcionamiento por no tener que realizar el trabajo extra pero lo dejara en la página autor.

3.29. Para una eficiente eliminación de fallas

Usar rastreador de rasgos de ASP.NET para ajustar en lugar de responder o escribir.



y ASP.NET.

4. Bibliografía:www.msdn.com

Naming Convention:

Design Guidelines for Class Library Developers, MSDN.http://msdn2.microsoft.com/en-us/library/czefa0ke(vs.71).aspxAccesado el 13 de julio del 2007.

Type Design Guidelines, MSDN.http://msdn2.microsoft.com/en-us/library/ms229036(VS.80).aspxAccesado el 13 de julio del 2007.

Naming Conventions for .NET / C# Projects, Akadia AG.

http://www.akadia.com/services/naming_conventions.htmlAccesado el 13 de julio del 2007.

Mejores Prácticas Visual.NET:C# Coding Standards and Best Programming Practices, dotnetspiderhttp://www.dotnetspider.com/tutorials/BestPractices.aspxAccesado el 13 de julio del 2007.

Mejores Prácticas ASP.NETASP.NET General Referente, MSDN.http://msdn2.microsoft.com/en-us/library/ms644556.aspxAccesado el 13 de julio del 2007.

Naming Guidelines, MSDN, Accesado.http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpgenref/html/cpconnamingguidelines.aspAccesado el 13 de julio del 2007.



y ASP.NET.

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpgenref/html/cpconnamingguidelines.asp

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpgenref/html/cpconnamingguidelines.asp

http://msdn2.microsoft.com/en-us/library/ms644556.aspx

http://www.dotnetspider.com/tutorials/BestPractices.aspx

http://www.akadia.com/services/naming_conventions.html

http://msdn2.microsoft.com/en-us/library/ms229036(VS.80).aspx

http://msdn2.microsoft.com/en-us/library/czefa0ke(vs.71).aspx

http://www.msdn.com/

Manual Para Nombramiento y Mejores Prácticas en Visual.NET y ASP.NET

Documents

Transcript of Manual Para Nombramiento y Mejores Prácticas en Visual.NET y ASP.NET