domingo, 28 de diciembre de 2014
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
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,
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
Por supuesto, las comprobaciones atienden al camel casing, es decir el nombre del método
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.
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!
[Actualizado 30/12]
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
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.
Hay
6 comentarios, ¡participa tú también!
Etiquetas: calidad, inocentadas, novedades, visualstudio
martes, 23 de diciembre de 2014
Estimados amigos, en esta ocasión escribo sólo para desearos unas magníficas fiestas en la mejor compañía posible y, por si nos nos vemos más hasta el año que viene, desearos también un 2015 espectacular y en el que se cumplan todos vuestros sueños.
¡Nos seguimos viendo por aquí!
Publicado en Variable not found.
¡Nos seguimos viendo por aquí!
Publicado en Variable not found.
martes, 16 de diciembre de 2014
Como ya hemos visto por aquí en alguna ocasión, hace tiempo que MVC soporta controladores asíncronos, permitiendo la implementación de acciones muy eficientes desde el punto de vista de la utilización de los recursos del servidor.
Sin embargo, en cuanto pretendíamos llevar a los action filters la misma filosofía nos encontrábamos con que la infraestructura no estaba preparada, es decir, no teníamos una forma clara de introducir llamadas asíncronas en el cuerpo de los filtros. Como consecuencia, todas las tareas que se realizaban en su interior eran puramente síncronas y dejaban bloqueados los hilos destinados a procesar peticiones mientras se completaban las operaciones, lo cual es especialmente un despilfarro cuando se trata de tareas de entrada/salida.
Afortunadamente esto parece que va a terminar con ASP.NET Core MVC, que soportará ya esta solicitada característica. Pero ojo, que Core MVC está aún en desarrollo, por lo que todo lo que cuento a continuación puede cambiar.
Pero empecemos desde el principio, viendo qué ha cambiado por abajo para que sea posible crear filtros con código asíncrono en su interior. Quizás sea una lectura un poco densa, pero creo que es interesante para comprender cómo funcionan las cosas por dentro.
Sin embargo, en cuanto pretendíamos llevar a los action filters la misma filosofía nos encontrábamos con que la infraestructura no estaba preparada, es decir, no teníamos una forma clara de introducir llamadas asíncronas en el cuerpo de los filtros. Como consecuencia, todas las tareas que se realizaban en su interior eran puramente síncronas y dejaban bloqueados los hilos destinados a procesar peticiones mientras se completaban las operaciones, lo cual es especialmente un despilfarro cuando se trata de tareas de entrada/salida.
Afortunadamente esto parece que va a terminar con ASP.NET Core MVC, que soportará ya esta solicitada característica. Pero ojo, que Core MVC está aún en desarrollo, por lo que todo lo que cuento a continuación puede cambiar.
Pero empecemos desde el principio, viendo qué ha cambiado por abajo para que sea posible crear filtros con código asíncrono en su interior. Quizás sea una lectura un poco densa, pero creo que es interesante para comprender cómo funcionan las cosas por dentro.
lunes, 15 de diciembre de 2014
Ahí van los enlaces recopilados durante la semana pasada, espero que os resulten interesantes :-)
ASP.NET
- How to Choose the Best Way to Pass Multiple Models in ASP.NET MVC
Snesh Prajapati - Razor views pre-compilation with ASP.NET 5 and MVC 6
Filip Woj - Running ASP.NET on a Raspberry Pi with Mono and OWIN
Jan Tielens - ASP.NET vNext Project Creation using Yeoman
Shayne Boyer
martes, 9 de diciembre de 2014
Ahí van los enlaces recopilados durante la semana pasada, espero que os resulten interesantes :-)
.Net
- Creating multi-target NuGet Packages with vNext
Rick Strahl - Modification of .NET expressions
Ivan Yakimov - Introducing .NET Core
Immo Landwerth - 10 Extremely Useful .NET Extension Methods
Jonathan Danylko - Getting ready for the future with the Microsoft .NET Portability Analyzer
Scott Hanselman
miércoles, 3 de diciembre de 2014
Aunque aún en beta e inmersa en un intenso proceso de desarrollo, la próxima versión de ASP.NET MVC está tomando forma en los hornos de Microsoft, y, sin ser definitivas, ya se pueden ver cuáles serán las novedades principales que la acompañarán.
En futuros posts iremos entrando en mayor detalle, pero de momento vamos a echar un vistazo desde una cierta distancia para tener la idea general sobre dónde estamos y la evolución que vamos a encontrar en las nuevas versiones de tecnologías y plataformas, de forma que podamos ver en qué nos afectará como desarrolladores y, en definitiva, para qué tenemos que irnos preparando.
En futuros posts iremos entrando en mayor detalle, pero de momento vamos a echar un vistazo desde una cierta distancia para tener la idea general sobre dónde estamos y la evolución que vamos a encontrar en las nuevas versiones de tecnologías y plataformas, de forma que podamos ver en qué nos afectará como desarrolladores y, en definitiva, para qué tenemos que irnos preparando.
Disclaimer: estamos aún en una fase en la que algunas cosas pueden cambiar y aún no existe información exhaustiva de muchos detalles, por lo que pueden existir ausencias o imprecisiones. Pero bueno, digo yo que el grueso será más o menos correcto ;-)