Ir al contenido principal

Cómo deshabilitar el resaltado de código Razor

Bocadillos dot NET #2

Para quienes somos usuarios de temas oscuros en nuestro IDE, una de las principales ventajas es la reducción de la fatiga visual. Los colores oscuros generan menos brillo y contraste, haciendo que nuestras sesiones de programación sean más cómodas, especialmente durante largas horas frente a la pantalla. Sin embargo, puede surgir un problema particular: al compartir pantalla, especialmente en vistas de Razor, el resaltado predeterminado de código puede dificultar la legibilidad para los demás.

En este artículo, vamos a explorar cómo deshabilitar o ajustar el formato de "código resaltado" en Visual Studio, mejorando así la legibilidad al compartir pantalla.

Objetivo

Deshabilitar el formato de "código resaltado" para el código Razor en Visual Studio. Este formato, aunque útil para algunos, puede ser un inconveniente cuando se utiliza un tema oscuro debido a dificultades de legibilidad, especialmente durante presentaciones remotas o defensas de proyectos.

Pasos a seguir

Abrir las opciones de configuración:
  • En Visual Studio 2019 (el proceso es similar en versiones posteriores o anteriores):
  • Ir a Herramientas Opciones.
  • En el menú lateral, seleccionar Entorno Fuentes y colores.
Luego debemos localizar el elemento de Razor HTML
  • En la ventana denominada Mostrar los elementos, navegar hasta el elemento Fondo del código Razor HTML.
Tip: Podés utilizar el teclado presionando la tecla F para buscar más rápidamente.

Ventana de Configuración de Visual Studio

Ajustar los colores

En los recuadros Primer plano del elemento y Fondo del elemento, seleccionar:
  • Automático, para que el sistema ajuste los colores de acuerdo con el tema del IDE.
O bien, elegí un color que armonice mejor con tu tema oscuro y sea más legible.

Luego hacemos click en Aceptar para aplicar la configuración.

Resultado

Vista con la configuración predeterminada: los colores del resaltado dificultan la lectura, especialmente en temas oscuros.

Vista de ejemplo con Razor antes de las modificaciones

Vista con la configuración ajustada: colores armonizados que mejoran la legibilidad durante presentaciones o colaboraciones remotas.

Vista de ejemplo con Razor después de las modificaciones



Este sencillo ajuste en la configuración de Visual Studio permite mejorar la experiencia visual tanto para ti como para quienes visualizan tu pantalla durante una sesión remota. Es un pequeño cambio que puede marcar una gran diferencia en la claridad y profesionalismo de tus presentaciones.

Espero que este tip te sea útil. Si tenés algún truco o personalización que utilices en tu flujo de trabajo y querés compartirlo, dejalo en los comentarios.

Otros artículos

Principio de Responsabilidad Única (SRP) – SOLID explicado con ejemplos

Introducción a S.O.L.I.D En esta entrada, intentaremos abordar un nuevo ciclo de conceptos que tienen que ver sobre los principios SOLID , que son fundamentales en la programación orientada a objetos o POO . Estos principios fueron formulados, en principio, por Robert C. Martin , también conocido como " Uncle Bob ", con el objetivo de mejorar la mantenibilidad y escalabilidad del código de software. SOLID es un acrónimo que representa cinco principios de diseño: Single Responsibility Principle (SRP) – Principio de Responsabilidad Única Open/Closed Principle (OCP) – Principio de Abierto/Cerrado Liskov Substitution Principle (LSP ) – Principio de Sustitución de Liskov Interface Segregation Principle (ISP) – Principio de Segregación de Interfaces Dependency Inversion Principle (DIP) – Principio de Inversión de Dependencias Estos principios nos ayudan a crear software más ...

Open/Closed Principle (OCP) – SOLID explicado con ejemplos

Continuando con el repaso de los principios de S.O.L.I.D. que inició en el hilo anterior - si no lo viste hacé click acá  Principio de Responsabilidad Única (SRP) - vamos a ver el segundo en orden de aparición: Principio de Abierto/Cerrado (OCP por sus siglas en inglés). Definición Formal El principio OCP (Open/Closed Principle) establece que el código de una clase o un módulo debe estar abierto para la extensión, pero cerrado para la modificación. Esto significa que no se deben realizar cambios en el código existente cuando se requiere alterar alguna funcionalidad. En lugar de modificar el código existente, se debe crear una nueva implementación que extienda la funcionalidad. La única excepción a esto son los arreglos de bugs, donde está permitido modificar el código existente. Si se desea introducir una nueva funcionalidad, como la ordenación en un método existente, en lugar de modificar el código, se crearía una nueva implementación q...

Roadmap para Desarrolladores Backend en .NET en 2025

El mundo del desarrollo backend está en constante evolución, y mantenerse actualizado con las mejores prácticas y tecnologías es clave para seguir siendo competitivo en el mercado. Si estás buscando una guía clara y estructurada para mejorar tus habilidades en . NET backend , el sitio roadmap.sh ofrece un excelente punto de partida. Para esta entrada vamos a explorar lo siguiente: ¿Qué es roadmap.sh y por qué es relevante? El roadmap backend para .NET en 2025 Tecnologías y habilidades esenciales para backend a considerar ¿Qué es roadmap.sh y quién lo creó? roadmap.sh es una plataforma ampliamente reconocida dentro de la comunidad de desarrolladores. Fue creada por Kamran Ahmed, un Google Developer Expert y contribuidor en múltiples proyectos de código abierto. Desde su lanzamiento, la plataforma ha crecido exponencialmente, acumulando más de 300,000 estrellas en GitHub y una comunidad activa de...

Codewars

Como algunos ya saben, soy un gran entusiasta de las plataformas en línea dedicadas a la educación y al entrenamiento de habilidades, lo que podríamos llamar "gimnasios mentales". Hoy quiero presentarles, o tal vez recordarles, una de mis favoritas: Codewars, conocida también como " Guerras de Código " en español. Si aún no la conocían, los invito a explorarla. Y si ya la conocían, este es un buen momento para redescubrirla y sacarle más provecho. ¿Qué es Codewars? Codewars es una plataforma educativa en línea diseñada como un juego para entrenar habilitades de programación. fue fundada en noviembre de 2012 por Nathan Doctor y Jake Hoffner . La idea surgió durante una competencia de Startup Weekend ese mismo año, donde desarrollaron un prototipo que obtuvo el primer lugar. En la actualidad, Codewars es propiedad de Qualified , una empresa tecnológica que ofrece una plataforma para evaluar y entrenar habilidades en ingeniería de software. Con esta herramienta pod...

Principio de Sustitución de Liskov (LSP) – SOLID explicado con ejemplos

¿Qué es el Principio de Sustitución de Liskov? Imaginá que tenés un control remoto universal diseñado para funcionar con cualquier televisor. Si un nuevo modelo de TV no responde a los mismos comandos, el control deja de ser útil. El Principio de Sustitución de Liskov es como una garantía de que cualquier 'televisor' (o clase derivada) va a funcionar correctamente con el 'control remoto' (o clase base). El Principio de Sustitución de Liskov ( LSP ) es el tercer principio de SOLID , representado por la letra L y establece que: Los objetos de una clase derivada deben poder sustituir a los objetos de su clase base sin afectar el comportamiento correcto del programa. En otras palabras, si una clase hija hereda de una clase padre, cualquier instancia de la clase hija debería poder usarse en lugar de una instancia de la clase padre sin alterar la funcionalidad esperada. ¿Quién es Bárbara Liskov? Bárbara Liskov es una destacada científi...

Principio de Segregación de Interfaces (ISP) – SOLID explicado con ejemplos

El Principio de Segregación de Interfaces es otro de los principios SOLID y establece que: Una clase no debería verse obligada a depender de métodos que no utiliza .  En otras palabras, en lugar de crear una interfaz grande con muchos métodos, es mejor dividirla (segregar) en interfaces más pequeñas y específicas. Pero.. ¿Por qué? Obliga a implementar métodos innecesarios Si una clase solo necesita una "parte" de la funcionalidad de una interfaz, pero esta interfaz es muy grande, se va a ver obligada a implementar métodos que no usa. Esto es casi que inevitable si no buscamos la manera de separar mejor las responsabilidades. Imaginemos una interfaz IVehiculo que tiene los siguientes métodos: public interface IVehiculo { void Conducir () ; void Volar () ; void Navegar () ; } Si una clase Auto implementa esta interfaz, se ve obligado a definir métodos como Volar() o Navegar() , aunque un auto no vuela ni navega. public c...
Buy Me A Coffee