Ahí van los enlaces recopilados durante la semana pasada, espero que os resulten interesantes :-)

.Net

• NCache 3.1 Open Sourced
  Kay Ewbank

Hace relativamente poco tiempo, y como parte del popular salto al open source del nuevo stack de Microsoft, se publicaron en Github las directrices o normas de codificación que deben seguirse para contribuir en el desarrollo de .NET Core. Se trata de un resumen simplificado del contenido del libro “Framework design guidelines” publicado por Krzysztof Cwalina y Brad Abrams en 2008.

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!

Ahí van los enlaces recopilados durante la semana pasada, espero que os resulten interesantes :-)

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 

Ahí van los enlaces recopilados durante los días pasados, espero que os resulten interesantes :-)

.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 

Como de costumbre, aprovecho estas primeras palabras del año para desearos de todo corazón un 2015 fabuloso en todos los aspectos. A ver si el oráculo empieza a tener razón, las cosas mejoran un poco y podemos acabar este año recién estrenado siendo un poco más felices.

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.

Por mi trabajo, suelo “husmear” en el código de muchas aplicaciones creadas por equipos de trabajo en empresas de todo tipo y nacionalidad, y os puedo asegurar que existe un denominador común en todas ellas y que seguro reconoceréis en vuestro propio código: los desarrolladores escribimos como nos viene en gana.

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.

Para su aplicación práctica en las herramientas de desarrollo de la casa, ha sido necesario retocar tanto las propias herramientas como algunos aspectos de los compiladores de los lenguajes estrella, C#, VB, F# y DuoLang.

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!



Publicado en Variable not found.