¡Hola a todos! Hay mucha información sobre las diferentes funciones de C#. Sobre varios trucos y mejores prácticas en este idioma. Quiero contarte algunos consejos igualmente útiles, pero menos populares, para trabajar con este lenguaje. 1. Los métodos "Task/Task<T>" no asíncronos no deberían devolver un valor nulo Devolver nulo desde un método Task/Task<T> no asíncrono provocará una NullReferenceException en tiempo de ejecución. Este problema se puede evitar devolviendo Task.FromResult<T>(null) en su lugar. Mal ejemplo: { ; } Task< > ( ) public object GetFooAsync return null // Noncompliant Buen ejemplo: { Task.FromResult< >( ); } Task< > ( ) public object GetFooAsync return object null 2. Las cadenas no deben concatenarse usando '+' en un bucle StringBuilder es más eficiente que la concatenación de cadenas, especialmente cuando el operador se repite una y otra vez como en bucles. Mal ejemplo: str = ; ( i = ; i < arrayOfStrings.Length ; ++i) { str = str + arrayOfStrings[i]; } string "" for int 0 Buen ejemplo: StringBuilder bld = StringBuilder(); ( i = ; i < arrayOfStrings.Length; ++i) { bld.Append(arrayOfStrings[i]); } str = bld.ToString(); new for int 0 string 3. Se deben preferir los métodos basados en compensaciones de cadenas para encontrar subcadenas a partir de compensaciones. La búsqueda de una subcadena determinada a partir de un desplazamiento específico se puede lograr mediante dicho código: str.Substring(startIndex).IndexOf(char1). Esto funciona bien, pero crea una nueva cadena para cada llamada al método Substring. Cuando esto se hace en un bucle, se crean muchas cadenas de forma gratuita, lo que puede provocar problemas de rendimiento si str es grande. Para evitar problemas de rendimiento, string.Substring(startIndex) no debe encadenarse con los siguientes métodos: Índice de IndexOfAny ÚltimoÍndiceDe LastIndexOfAny Para cada uno de estos métodos, hay disponible otro método con un parámetro adicional para especificar un desplazamiento. El uso de estos métodos da el mismo resultado y evita la creación de instancias de String adicionales. Mal ejemplo: str.Substring(StartIndex).IndexOf(char1); // Noncompliant; a new string is going to be created by "Substring" Buen ejemplo: str.IndexOf(char1, startIndex); 4. Las colecciones no deben pasarse como argumentos a sus propios métodos. Pasar una colección como argumento al propio método de la colección es un error (se pretendía algún otro argumento) o simplemente un código sin sentido. Además, dado que algunos métodos requieren que el argumento no se modifique durante la ejecución, pasar una colección a sí misma puede provocar un comportamiento inesperado. Malos ejemplos: list = List< >(); list.AddRange(list); list.Concat(list); list.Union(list); list.Except(list); list.Intersect(list); list.SequenceEqual(list); = HashSet< >(); .UnionWith( ); .ExceptWith( ); .IntersectWith( ); .IsProperSubsetOf( ); .IsProperSupersetOf( ); .IsSubsetOf( ); .IsSupersetOf( ); .Overlaps( ); .SetEquals( ); .SymmetricExceptWith( ); var new int // Noncompliant // Noncompliant // Noncompliant; always returns list // Noncompliant; always empty // Noncompliant; always list // Noncompliant; always true var set new int set set // Noncompliant; no changes set set // Noncompliant; always empty set set // Noncompliant; no changes set set // Noncompliant; always false set set // Noncompliant; always false set set // Noncompliant; always true set set // Noncompliant; always true set set // Noncompliant; always true set set // Noncompliant; always true set set // Noncompliant; always empty 5. Las matrices y colecciones vacías deben devolverse en lugar de nulo Devolver nulo en lugar de una matriz o colección real obliga a las personas que llaman al método a probar explícitamente la nulidad, haciéndolos más complejos y menos legibles. Además, en muchos casos, null se usa como sinónimo de vacío. Malos ejemplos: { ; } { ; } Result[] ( ) public GetResults return null // Noncompliant IEnumerable<Result> ( ) public GetResults return null // Noncompliant Buenos ejemplos: { Result[ ]; } { Enumerable.Empty<Result>(); } Result[] ( ) public GetResults return new 0 IEnumerable<Result> ( ) public GetResults return 6. Los resultados de la división de enteros no deben asignarse a variables de punto flotante Cuando la división se realiza en enteros, el resultado siempre será un entero. Puede asignar ese resultado a un doble, flotante o decimal con conversión de tipo automática, pero al comenzar como un int, es probable que el resultado no sea el esperado. Si el resultado de la división int se asigna a una variable de coma flotante, se habrá perdido la precisión antes de la asignación. En su lugar, al menos un operando debe convertirse o promoverse al tipo final antes de que se lleve a cabo la operación. Ejemplos: dec = / ; dec = ( ) / ; decimal 3 2 // Noncompliant decimal decimal 3 2 7. Los recursos compartidos no deben usarse para bloquear Los recursos compartidos no deben usarse para el bloqueo, ya que aumenta la posibilidad de interbloqueos. Cualquier otro subproceso podría adquirir (o intentar adquirir) el mismo bloqueo para otro propósito no relacionado. En su lugar, se debe usar una instancia de objeto dedicada para cada recurso compartido, para evitar interbloqueos o bloqueos de contención. Los siguientes objetos se consideran recursos compartidos: este un objeto de tipo un literal de cadena una instancia de cadena 8. Los subprocesos no deben bloquear objetos con identidad débil Un subproceso que adquiere un bloqueo en un objeto al que se puede acceder a través de los límites del dominio de la aplicación corre el riesgo de ser bloqueado por otro subproceso en un dominio de aplicación diferente. Se dice que los objetos a los que se puede acceder a través de los límites del dominio de la aplicación tienen una identidad débil. Los tipos con identidad débil son: MarshalByRefObjeto ExecutionEngineException OutOfMemoryException StackOverflowException Cuerda Información de miembro Información de parámetros Hilo 9. No se debe usar "Thread.Resume" ni "Thread.Suspend" Thread.Suspend y Thread.Resume pueden dar resultados impredecibles, y ambos métodos han quedado obsoletos. De hecho, si Thread.Suspend no se usa con mucho cuidado, un subproceso puede suspenderse mientras se mantiene un candado, lo que lleva a un interbloqueo. Se deben utilizar otros mecanismos de sincronización más seguros, como Monitor, Mutex y Semaphore. 10. Las excepciones no deben volver a lanzarse explícitamente Al volver a lanzar una excepción, debe hacerlo simplemente llamando a throw; y no throw exc;, porque el seguimiento de la pila se restablece con la segunda sintaxis, lo que dificulta mucho la depuración. Ejemplos: {} (ExceptionType1 exc) { Console.WriteLine(exc); exc; } (ExceptionType2 exc) { Console.WriteLine(exc); ; } (ExceptionType3 exc) { Exception( , exc); } try catch throw // Noncompliant; stacktrace is reset catch throw // Compliant catch throw new "My custom message" // Compliant; stack trace preserved 11. No se deben lanzar excepciones de métodos inesperados Se espera que algunos métodos se llamen con precaución, pero se espera que otros, como ToString, "simplemente funcionen". Lanzar una excepción de dicho método es probable que rompa el código de las personas que llaman de forma inesperada. El problema ocurre cuando se lanza una excepción de cualquiera de los siguientes: Accesores de eventos Objeto.Equals IEquatable.Equals Obtener código hash Encadenar constructores estáticos IDisposable.Dispose operador ==, !=, <, >, <=, >= operadores de conversión implícitos Mal ejemplo: { ( .IsNullOrEmpty(Name)) { ArgumentException( ); } } ( ) public override string ToString if string throw new "..." // Noncompliant 12. Las excepciones generales nunca deben lanzarse Lanzar excepciones generales como Exception, SystemException, ApplicationException, IndexOutOfRangeException, NullReferenceException, OutOfMemoryException y ExecutionEngineException evita que los métodos de llamada manejen excepciones verdaderas generadas por el sistema de manera diferente a los errores generados por la aplicación. 13. No se deben lanzar excepciones en bloques finalmente. Lanzar una excepción desde dentro de un bloque finalmente enmascarará cualquier excepción que se haya lanzado previamente en el bloque try o catch, y el mensaje de excepción enmascarado y el seguimiento de la pila se perderán. 14. Los tipos de excepción deben ser "públicos" El objetivo de tener tipos de excepción personalizados es transmitir más información de la que está disponible en los tipos estándar. Pero los tipos de excepción personalizados deben ser públicos para que funcionen. Si un método arroja una excepción no pública, lo mejor que puede hacer en el lado de la persona que llama es capturar la base pública más cercana de la clase. Es decir, pierde toda la información personalizada que creó para pasar el tipo de excepción. 15. Los destructores no deben lanzar excepciones Si Finalize o una anulación de Finalize genera una excepción, y el tiempo de ejecución no está alojado en una aplicación que anula la política predeterminada, el tiempo de ejecución finaliza el proceso inmediatamente sin una limpieza correcta (finalmente, los bloques y los finalizadores no se ejecutan). Este comportamiento garantiza la integridad del proceso si el finalizador no puede liberar o destruir recursos. Mal ejemplo: { ~MyClass() { NotImplementedException(); } } class MyClass throw new // Noncompliant 16. Los "IDisposables" creados en una instrucción "using" no deben devolverse Por lo general, querrá usar using para crear una variable IDisposable local; activará la eliminación del objeto cuando el control pase fuera del alcance del bloque. La excepción a esta regla es cuando su método devuelve ese IDisposable. En ese caso, el uso de desecha el objeto antes de que la persona que llama pueda usarlo, lo que probablemente provoque excepciones en el tiempo de ejecución. Por lo tanto, debe eliminar el uso o evitar devolver el IDisposable. Mal ejemplo: { ( fs = File.Create(path)) { bytes = Encoding.UTF8.GetBytes(text); fs.Write(bytes, , bytes.Length); fs; } } FileStream ( ) public WriteToFile path, text string string using var // Noncompliant var 0 return 17. "operator==" no debe sobrecargarse en los tipos de referencia Se espera que el uso de == para comparar objetos haga una comparación de referencia. Es decir, se espera que devuelva verdadero si y solo si son la misma instancia de objeto. Sobrecargar al operador para que haga cualquier otra cosa conducirá inevitablemente a la introducción de errores por parte de las personas que llaman. Por otro lado, sobrecargarlo para hacer exactamente eso no tiene sentido; eso es lo que == hace por defecto. 18. "Equals(Object)" y "GetHashCode()" deben anularse en pares Existe un contrato entre Equals(objeto) y GetHashCode(): si dos objetos son iguales según el método Equals(objeto), llamar a GetHashCode() en cada uno de ellos debe arrojar el mismo resultado. Si este no es el caso, muchas colecciones no manejarán correctamente las instancias de clase. Para cumplir con el contrato, Equals(object) y GetHashCode() deben heredarse o anularse. 19. "GetHashCode" no debe hacer referencia a campos mutables GetHashCode se utiliza para archivar un objeto en un diccionario o tabla Hash. Si GetHashCode usa campos que no son de solo lectura y esos campos cambian después de almacenar el objeto, el objeto se archiva de forma incorrecta en Hashtable de inmediato. Cualquier prueba posterior para ver si el objeto está en Hashtable arrojará un falso negativo. Mal ejemplo: age; name; { hash = ; hash += .age.GetHashCode(); hash += .name.GetHashCode(); hash; } public int public string ( ) public override int GetHashCode int 12 this // Noncompliant this // Noncompliant return Buen ejemplo: DateTime birthday; name; { hash = ; hash += .birthday.GetHashCode(); hash; } public readonly public string ( ) public override int GetHashCode int 12 this return 20. Las clases "abstractas" no deberían tener constructores "públicos" Dado que las clases abstractas no se pueden instanciar, no tiene sentido que tengan constructores públicos o internos. Si hay una lógica de inicialización básica que debe ejecutarse cuando se crea una instancia de clase extendida, puede ponerla en un constructor, pero hacer que ese constructor sea privado o protegido. 21. La herencia de tipos no debe ser recursiva La recursión es aceptable en los métodos, en los que puede salir de ella. Pero con los tipos de clase, terminas con un código que se compilará pero no se ejecutará si intentas instanciar la clase. Mal ejemplo: < > { } < > : < < < >>> { } c2 = C2< >(); class C1 T class C2 T C1 C2 C2 T // Noncompliant var new int 22. No se debe usar "nuevo Guid ()" Cuando se usa la sintaxis new Guid() (es decir, creación de instancias sin parámetros), debe ser que se desea una de estas tres cosas: Un GUID vacío, en cuyo caso Guid.Empty es más claro. Un GUID generado aleatoriamente, en cuyo caso se debe usar Guid.NewGuid(). Un nuevo GUID con una inicialización específica, en cuyo caso falta el parámetro de inicialización. 23. "GC.Collect" no debe llamarse Llamar a GC.Collect rara vez es necesario y puede afectar significativamente el rendimiento de la aplicación. Esto se debe a que activa una operación de bloqueo que examina para limpiarlos. Además, no tiene control sobre cuándo se ejecutará realmente esta limpieza de bloqueo. todos los objetos en la memoria Como regla general, las consecuencias de llamar a este método superan con creces los beneficios, a menos que tal vez haya desencadenado algún evento único en la ejecución de su programa que causó la muerte de muchos objetos de larga duración. 24. Las secciones de código no deben comentarse Los programadores no deben comentar el código, ya que infla los programas y reduce la legibilidad. El código no utilizado debe eliminarse y puede recuperarse del historial de control de código fuente si es necesario. 25. No se debe usar la declaración "goto" goto es una instrucción de flujo de control no estructurada. Hace que el código sea menos legible y mantenible. En su lugar, se deben utilizar declaraciones de flujo de control estructurado como if, for, while, continue o break. PD ¡Gracias por leer! ¡Más consejos próximamente! Un agradecimiento especial a SonarQube y sus reglas - https://www.sonarqube.org/
