docs: updated some markdown files

docs/development-rules/sections/code-style.md

@@ -4,23 +4,28 @@
 
 Dependiendo del lenguaje, se deberá utilizar la convención de nombres por defecto del mismo. Algunos ejemplos son:
 
-| Lenguaje | Convención de nombres |
-| ----- | ----- |
-| Javascript, Typescript, Java | [camelCase](https://en.wikipedia.org/wiki/Camel_case) |
-| Python | snake\_case y camelCase ([ver](https://peps.python.org/pep-0008/#naming-conventions)) |
-| Ruby | snake\_case y camelCase (ver guía de ruby y guía de RoR)  |
-| SQL | [snake\_case](https://en.wikipedia.org/wiki/Snake_case) |
-| MongoDB | camelCase con [variaciones](https://www.mongodb.com/docs/manual/reference/limits/#naming-restrictions) |
+| Lenguaje                     | Convención de nombres                                                                                                    |
+| ---------------------------- | ------------------------------------------------------------------------------------------------------------------------ |
+| Javascript, Typescript, Java | [camelCase](https://en.wikipedia.org/wiki/Camel_case)                                                                    |
+| Python                       | snake\_case y camelCase ([ver](https://peps.python.org/pep-0008/#naming-conventions))                                    |
+| Ruby                         | snake\_case y camelCase (ver guía de ruby y guía de RoR)                                                                 |
+| SQL                          | [snake\_case](https://en.wikipedia.org/wiki/Snake_case)                                                                  |
+| MongoDB                      | camelCase con [variaciones](https://www.mongodb.com/docs/manual/reference/limits/#naming-restrictions)                   |
+| C#                           | PascalCase con [variaciones](https://learn.microsoft.com/en-us/dotnet/csharp/fundamentals/coding-style/identifier-names) |
 
 ## Lenguaje de marcado para comentarios
 
 Dependiendo del lenguaje, se deberá documentar el código con el formato por defecto del mismo. Algunos ejemplos son:
 
-| Lenguaje               | Convención de nombres                                                                 |
-| ---------------------- | ------------------------------------------------------------------------------------- |
-| Javascript, Typescript | [JSDoc](https://jsdoc.app)                                                            |
-| Java                   | [Javadoc](https://docs.oracle.com/javase/8/docs/technotes/tools/windows/javadoc.html) |
-| Python                 | [Docstring](https://peps.python.org/pep-0008/#documentation-strings)                  |
-| Ruby                   | [RDoc](https://github.com/ruby/rdoc)                                                  |
+| Lenguaje               | Formato                                                                                                |
+| ---------------------- | ------------------------------------------------------------------------------------------------------ |
+| Javascript, Typescript | [JSDoc](https://jsdoc.app)                                                                             |
+| Java                   | [Javadoc](https://docs.oracle.com/javase/8/docs/technotes/tools/windows/javadoc.html)                  |
+| Python                 | [Docstring](https://peps.python.org/pep-0008/#documentation-strings)                                   |
+| Ruby                   | [RDoc](https://github.com/ruby/rdoc)                                                                   |
+| C#                     | [XML Docs](https://learn.microsoft.com/en-us/dotnet/csharp/language-reference/xmldoc/recommended-tags) |
 
-**NOTA:** El uso de este tipo de comentarios será obligatorio para clases, interfaces y funciones. Para las funciones, se deberán documentar también los tipos de parámetros y el tipo de retorno si aplica (incluyendo manejo de excepciones)
\ No newline at end of file
+**NOTA:** El uso de este tipo de comentarios será obligatorio para clases, interfaces y funciones. Para las funciones, se deberán documentar también los tipos de parámetros y el tipo de retorno si aplica (incluyendo manejo de excepciones)
+
+* volver al [inicio](/README.md)
+* volver a las [normas de desarrollo](/docs/development-rules/README.md)
\ No newline at end of file

docs/development-rules/sections/tools-and-frameworks.md

@@ -3,7 +3,7 @@
 El uso de diferentes herramientas y frameworks será determinado para cada proyecto, en conjunto con los miembros del equipo, a continuación se presentan algunas recomendaciones generales.
 
 ### Recomendaciones generales
-* Tener compatibilidad total con el sistema operativo *GNU/Linux* (para facilitar su contenerización y orquestación).
+* Tener compatibilidad total con el sistema operativo *GNU/Linux* (para facilitar su contenedorización y orquestación).
 
 ## Back end