.Net
- NCache 3.1 Open Sourced
Kay Ewbank
Publicado por José M. Aguilar a las 9:15 a. m.
Etiquetas: enlaces
Aunque creo que este mismo documento o versiones anteriores lo he leído en otras ocasiones, la verdad es que sigue resultándome muy interesante porque me recuerda normas y convenciones que conviene tener en cuenta al desarrollar marcos de trabajo y componentes. No hay que olvidar que estas directrices han sido refinadas y mejoradas con los años, acumulando ya la experiencia de muchos años y muchos desarrolladores que han trabajado en .NET framework, así que se trata de una base de conocimiento nada despreciable. De hecho, estas pautas son las bases del diseño de frameworks dentro de la propia Microsoft.
Y como a menudo me encuentro con equipos que no tienen guías de estilo ni convenciones de codificación formalizadas, he pensado que quizás sería interesante traducirlas para que puedan ser usadas como punto de partida para crear sus propias normas y, en cualquier caso, siempre dan buenas ideas que podemos aplicar en el día a día para hacer mejor nuestros componentes.
Es una lectura cortita, ¡que aproveche!
Eventos
- [Quedada CartujaDotNet] Arrancando el año
Sevilla, 20 Feb. - dotNet Spain Conference
Madrid, 27-28 Feb
.Net
- C# Performance Mistakes – Top Problems Solved in December
Andreas Grabner - Write C# on a Mac like a Champ!
Sam Basu - Anti Forgery Tokens with AngularJS and ASP.NET Web API
Phil Fresle - We're moving to GitHub!
Kasey Uhlenh
.Net
- API review process for .NET Core
Immo Landweth - .NET Code Contracts are now OSS
Greg Duncan - Introducing Semantic Types in .Net
Matt Perdeck - Node.js Meets .NET – Edge.js
Keyhole Software - Create an instance of a class without calling a constructor
Ben Dornis - C# - Fast Memory Copy Method with x86 Assembly Usage
Oleksandr Karpov
Y también como parte de la tradición, dedicaremos este post a repasar qué entradas fueron las diez más visitadas en el pasado año, que más o menos da una idea de los intereses que nos han movido a todos durante la pasada temporada.
Publicado por José M. Aguilar a las 8:47 a. m.
Etiquetas: autobombo, blogging, variablenotfound, variablenotfound.com
No es poco frecuente ver aplicaciones con faltas de ortografía que un niño de primaria calificaría como graves. Y notad que no hablo sólo de las etiquetas, mensajes y otros elementos visuales que van a parar a los atónitos ojos de nuestros usuarios, sino también de lo que hay por detrás, en el código fuente.
A nivel de código, las denominaciones internas en clases, métodos o variables, textos en comentarios o incluso los mensajes en check-ins en el control de código fuente, son habitualmente terribles. Claro, sabemos que eso no lo va a leer nadie, o al menos nadie de fuera de nuestro entorno, y bajamos la guardia hasta límites que rozan la ilegalidad. Mezclamos idiomas sin ningún criterio (¿quién no ha escrito alguna vez un método
GetFacturas()
, obtenerResources
() o una variable lineasCount
en su base de código?), cometemos atropellos ortográficos, gramaticales y otros tipos de aberración de forma impune, escudados en que no hay que prestar atención a esos detalles porque es sólo código.Y lo peor es que esta actitud de desidia es contagiosa. Cuando entras en un proyecto donde todo está escrito sin ningún tipo de miramiento, lo normal es que continúes en esa línea, haciendo que la barbarie sea cada vez mayor y, a su vez, más contagiosa en el futuro. Y cuando comiences otro proyecto, llevarás la costumbre de hacerlo así y continuarás extendiendo esta práctica ad eternum.
Pero, ah, amigos artesanos del código, esto se va a acabar.
Las próximas versiones de Visual Studio corregirán drásticamente esta tendencia, incluyendo la revisión ortográfica como parte del proceso de compilación. Además, como comentó S. Somasegar en una reciente entrevista,
“esta característica no podrá ser deshabilitada; en caso contrario ya sabemos lo que ocurriría, y va en contra de la firme apuesta de Microsoft hacia un mundo que se comunique mejor”Y la cosa va muy en serio. Para dar mayor formalidad a esta necesaria iniciativa, Microsoft ha firmado un acuerdo con distintas academias responsables de definir y actualizar la mayoría de idiomas del mundo, como la National Commission on Language and Script Work (国家语言文字工作委员会) de China, la Real Academia Española (RAE), Academy of the Arabic Language (مجمع اللغة العربية), la Royal Galician Academy, o Council for German Orthography (Rat für deutsche Rechtschreibung) por citar sólo algunas. De estas instituciones obtendrá los diccionarios actualizados que serán utilizados por las herramientas del gigante de Redmond para comprobar que estamos escribiendo como debemos. En el caso del inglés es distinto porque no existe un organismo regulador, pero se atenderán a las guías oficiales publicadas por los países donde es la lengua oficial.
En Visual Studio tendremos disponibles propiedades a nivel de proyecto y de cada archivo (de código, recursos, diseñadores, etc.) en el que indicaremos el idioma en el que debe realizarse la comprobación.
Por supuesto, también ha sido actualizado intellisense para alternativas a las palabras que vayamos escribiendo e incluso un menú de sinónimos, de la misma forma que Microsoft Word:
Para los casos en que el idioma pueda cambiar dentro del propio archivo o incluso en distintas secciones de éste, se han añadido directivas
#pragma
que pueden usarse en cualquier punto. Por ejemplo, en el siguiente código se han detectado dos errores de compilación para la porción escrita en español, en un comentario y en el nombre de un método:Por supuesto, las comprobaciones atienden al camel casing, es decir el nombre del método
ObtenerFactura()
se entenderá correcto, mientras que Obtenerfactura()
no lo será. Otra ventaja colateral de esta característica es que dejaremos de utilizar nombres de variable sin sentido como “s”, “xyz”, tendiendo a que realmente se refleje su intencionalidad como “saldo” o “coordenadasTridimensionales”. Se está estimando, sin embargo, excluir las variables de tipo índice obvias como la típica “i” en un bucle for
por razones históricas.Las mismas directivas y propiedades se aplicarán en las comprobaciones de cadenas de texto, recursos (.resx) y diseñadores de la aplicación. De esta forma, podremos estar seguros de que los textos que lanzamos a los usuarios habrán superado un nivel mínimo de calidad, que falta hace en muchas aplicaciones:
En fin, creo que es una iniciativa absolutamente necesaria para mejorar la calidad interna de nuestro código y, como extensión, de nuestras aplicaciones, y me gustaría felicitar a Microsoft por haber tomado esta controvertida decisión. Seguro que traerá mucha polémica, pero estoy convencido de que es por el bien de la humanidad.
Aunque en principio esta nueva característica sólo estará disponible para Visual Studio 2015, no se descarta la creación de extensiones para todas las versiones de Visual Studio, comenzando en la 2005. Está previsto incluso su introducción en el proyecto Omnisharp para poder aplicarlo en entornos de desarrollo más allá de Visual Studio, lo que abriría su uso a otras plataformas como Mac o Linux, y de la posibilidad de desarrollar plugins oficiales para Git, Mercurial, Subversion, TFS y sistemas de integración continua que permitan automatizar estas comprobaciones.
Se avecina un año maravilloso donde los sistemas de control de código fuente podrán rechazar un commit o check-in por tener faltas de ortografía, o en el que en nuestra mesa, junto a clásicos como C Programming language o Code Complete , podremos encontrar el diccionario de la real academia de la lengua española.
¡Feliz escritura de código!
Nota para despistadillos: obviamente no es real, se trata simplemente de una broma del Día de los Inocentes. Así que tranquilos, podemos seguir dando patadas al diccionario impunemente en nuestro código :-DDD
Publicado en Variable not found.
Publicado por José M. Aguilar a las 12:05 a. m.
Etiquetas: calidad, inocentadas, novedades, visualstudio