#Opinion – We have a winner in the eternal Tabs vs Spaces question! And I also have the formula to revert this …

Hola ! Hoy es viernes, así que toca repasar temas importantes para el fin de semana. Si eres programador, desarrollador o Developer, seguramente en algún momento fuiste parte de la eterna discusión ¿Debemos usar Tabs o Spaces? Como dice el refrán popular: para gustos colores, y aquí aplica más que nunca. Solemos utilizar herramientas para […]

ng4iJjZ

Hello!

Today is Friday, so it’s time to review important topics for the weekend. If you are a developer, for sur at some point on your career you were part of the eternal discussion

Should we use tabs or spaces?

As the popular saying goes: for tastes choose colors, and here applies more than ever. We usually use tools to maintain a coherent code style between all the members of a team, but it is never necessary to change the default settings of Visual Studio.

salary_graph-1-1024x731

No more words here. The average of salaries for programmers using spaces is $59.140, while the average for programmers using tabs is $43.750.

It is best to read the complete analysis that is done in StackOverflow (see references). And this also does not mean that if you change tabs to spaces your payroll will multiply automatically by 1.3518. However, this can serve as a prop to make a decision as a team and:

  • Define a coherent policy of programming styles in the Spaces vs tabs
  • Ask for a consistent pay increase to a developer using spaces

You can also take a step further and:

  • Create a company like Amazon, Microsoft or Facebook and hire 2 million of programmers
  • Pay exorbitant salaries
  • Define as company policy the use of Tabs
  • Encourage programmers to participate in the StackOverflow survey
  • Review the survey results and laugh until you stop! While you pet your Angora cat with your brandy glass on the other hand

Happy Coding!

Greetings @ Toronto

El Bruno

References

Advertisements

#Opinion – Tabs vs Spaces, han ganado los Spaces! Y como dar vuelta esta tendencia …

ng4iJjZ

Hola !

Hoy es viernes, así que toca repasar temas importantes para el fin de semana. Si eres programador, desarrollador o Developer, seguramente en algún momento fuiste parte de la eterna discusión

¿Debemos usar Tabs o Spaces?

Como dice el refrán popular: para gustos colores, y aquí aplica más que nunca. Solemos utilizar herramientas para mantener un Code Style coherente entre todos los integrantes de un equipo, pero nunca falta el que cambia la configuración por defecto de Visual Studio.

Clipboard01

Esto parece trivial hasta que al momento de hacer un Commit, vemos un conjunto como miles de cambios. Esta acción dispara alarmas por todos lados y al final llegamos a la eterna discusión Tabs vs Spaces.

Pues bien, el equipo de encuestas de StackOverflow ha demostrado que los programadores que usan Spaces ganan más dinero que los programadores que usan Tabs.

salary_graph-1-1024x731

Poco más se puede decir al respecto. La media de salarios para los programadores que usan Spaces es de $59,140, mientras que la media para los programadores que usan Tabs es de $43,750.

Lo mejor es leer el análisis completo que se hace en StackOverflow (link). Y esto tampoco quiere decir que si cambias de Tabs a Spaces tu nomina se multiplicara automáticamente por 1.3518. Eso sí, esto puede servir como puntal para tomar una decisión como equipo y

  • Definir una política coherente de estilos de programación en lo referido a Spaces vs Tabs
  • Pedir un aumento de sueldo coherente a un Developer que usa Spaces

También puedes dar un paso más y:

  • Fundar una empresa como Amazon, Microsoft o Facebook y contratar 2 millones de programadores
  • Pagar sueldos exorbitantes
  • Definir como política de empresa el uso de Tabs
  • Incentivar a los programadores para que participen en la encuesta de StackOverflow
  • Revisar los resultados de la encuesta y reir hasta no parar! Mientras acaricias tu gato de angora con tu copa de brandy en la otra mano

Happy Coding!

Saludos @ Toronto

El Bruno
References

#VS2017 – Code Style configuration in Visual Studio 2017 IDE

Hello!

A few months ago, before the official launch of Visual Studio 2017, one of the cool IDE innovations was the chance to define code style configurations to be applied in the IDE while we are coding apps. These configurations were stored in files named “.editorconfig”, and of course, the best way to learn on these files is navigating EditorConfig.org.

The interesting thing about the model is that, when we copy this file into a folder, the settings of it are applied for all the files and sub folders. If we want to have a special configuration in any sub folder, we must create another file in that location with the changes we need. The best introduction to this topic can be found in this .Net Team post (link).

Well, today in one of the sessions of Visual Studio live, I find that we can also configure these options directly from the IDE.

Important: The changes that are defined here apply to all projects that we edit with Visual Studio, not for a special solution or project.

The options can be edited in the “text editor//Code Style” section and you can see the different code editing rules.

 

Clipboard01

If for example, we define that the non-use of “this” is marked as an Error for local fields, we will be able to get a behavior in the Code Editor as the following:

Clipboard03

An interesting detail is that even ReSharper recognizes the configuration and proposes the necessary changes.

Clipboard05

Finally, we can also define some rules for defining class names, delegates, interfaces, etc.

Clipboard06

And when they are not met, define the type of notification that will be displayed.

Clipboard07

Finally, I have to clarify that while we can have many “errors” in our code, it may built without problems, as these errors are errors in style of code not compilation.

Greetings @ VSLive at Austin

El Bruno

References

#VS2017 – Nuevas opciones de Code Style en el IDE

Hola !

Hace unos meses, antes del lanzamiento oficial de Visual Studio 2017, una de las novedades del IDE era la capacidad de definir configuraciones con las reglas de estilo de código que luego se aplicaban en el IDE. Estas configuraciones se realizaban en archivos llamados “.editorconfig”, la mejor forma de conocer estos archivos es navegando EditorConfig.org.

Lo interesante del modelo es que, cuando copiamos este archivo en un folder, las configuraciones del mismo se aplican para todos los archivos y subfolders del mismo. Si queremos tener una configuración especial en estos subfolder, pues podemos crear otro archivo en esa ubicación con los cambios que querramos. La mejor introducción a este tema la podemos encontrar en este post del equipo de .Net (link)

Pues bien, hoy en una de las sesiones de Visual Studio Live, me entero que también podemos configurar estas opciones directamente desde el IDE.

Importante: Los cambios que se definen aquí se aplican para todos los proyectos que editemos con Visual Studio, no para una solución o proyecto especial.

Las opciones se pueden editar en la sección “Text Editor // Code Style” y en la misma podemos ver las diferentes reglas de edición de código.

Clipboard01

Si por ejemplo, definimos que se marcará como un Error el no uso de “this” para los fields locales, podremos ver en el editor de código lo siguiente:

Clipboard03

Un detalle interesante es que inclusive ReSharper reconoce la configuración y propone los cambios necesarios.

Clipboard05

Finalmente, también podemos definir algunas reglas de definición de nombres de clases, delegados, interfaces, etc.

Clipboard06

Y cuando no se cumplan las mismas, definir el tipo de notificación que se mostrará.

Clipboard07

Por último, tengo que aclarar que si bien podemos tener muchos “errores” en nuestro código, el mismo puede compilar sin problemas, ya que estos errores son errores de estilo de código no de compilación.

Saludos @ VSLive at Austin

El Bruno

References