vscode visual tag studio color code closing brackethighlighter visual-studio folding

visual-studio - tag - visual studio code path intellisense



¿Cómo te sientes acerca del plegado de código? (24)

No soy fanático de las clases parciales. Intento desarrollar mis clases de modo que cada clase tenga un solo problema muy claro y responsable. Con ese fin, no creo que algo con una responsabilidad clara deba dividirse en varios archivos. Es por eso que no me gustan las clases parciales.

Dicho esto, estoy en la cerca sobre las regiones. En su mayor parte, no los uso; sin embargo, trabajo con código todos los días que incluye regiones: algunas personas se vuelven realmente pesadas (doblando métodos privados en una región y luego cada método doblado en su propia región), y algunas personas los ignoran (doblando enums, doblar atributos, etc.). Mi regla general, a partir de ahora, es que solo coloque el código en regiones si (a) los datos es probable que permanezcan estáticos o no se tocarán con mucha frecuencia (como enumeraciones), o (b) si hay métodos que se implementan por necesidad debido a la creación de subclases o la implementación de métodos abstractos, pero, nuevamente, no se tocarán con mucha frecuencia.

Para aquellos de ustedes en el entorno de Visual Studio, ¿cómo se sienten al envolver cualquiera de sus códigos en #regiones? (o si cualquier otro IDE tiene algo similar ...)


Prefiero clases parciales en lugar de regiones.

El uso extensivo de regiones por otros también me da la impresión de que alguien, en alguna parte, está violando el Principio de Responsabilidad Individual y está tratando de hacer demasiadas cosas con un solo objeto.


Realmente no tengo ningún problema con el uso de #region para organizar el código. Personalmente, generalmente voy a configurar diferentes regiones para cosas como propiedades, controladores de eventos y métodos públicos / privados.


Utilizo #Region para ocultar el código generado automáticamente feo e inútil, que realmente pertenece a la parte generada automáticamente de la clase parcial. Pero, cuando trabajas con proyectos antiguos o proyectos actualizados, no siempre tienes ese lujo.

En cuanto a otros tipos de plegado, doblo Funciones todo el tiempo. Si nombra bien la función, nunca tendrá que mirar adentro a menos que esté probando algo o (re) escribiéndolo.


Utilizo Textmate (solo Mac) que tiene plegado de código y me parece realmente útil para las funciones de plegado, sé lo que hace mi función "getGet", no lo necesito ocupando 10 líneas de oh tan valioso espacio en la pantalla.

Nunca lo uso para ocultar un bucle for, una instrucción if o similar, a menos que le muestre el código a otra persona donde ocultaré el código que han visto para evitar mostrar el mismo código dos veces.


Yo personalmente uso #Regions todo el tiempo. Encuentro que me ayuda a mantener las cosas como propiedades, declaraciones, etc. separadas unas de otras.

¡Esta es probablemente una buena respuesta, también!

Codificando Horror

Editar: ¡Dang, Pat me ganó a esto!


Yo prefiero las regiones, pero un antiguo compañero de trabajo no soportaba ocultar las cosas. Entendí su punto una vez que trabajé en una página con 7 #regiones, al menos 3 de las cuales habían sido generadas automáticamente y tenían el mismo nombre, pero en general creo que son una forma útil de dividir las cosas y mantener todo menos abarrotado


9 de cada 10 veces, el plegado del código significa que no ha utilizado el principio SoC por lo que vale.
Más o menos siento lo mismo sobre las clases parciales. Si tiene un código que cree que es demasiado grande, necesita cortarlo en partes manejables (y reutilizables), no ocultarlo ni dividirlo.
Te morderá la próxima vez que alguien necesite cambiarlo, y no podrá ver la lógica oculta en un monstruo de 250 líneas de un método.

Siempre que pueda, extraiga un código de la clase principal y en una clase auxiliar o de fábrica.

foreach (var item in Items) { //.. 100 lines of validation and data logic.. }

no es tan legible

foreach (var item in Items) { if (ValidatorClass.Validate(item)) RepositoryClass.Update(item); }



Mi $ 0.02 de todos modos.


A veces puede encontrarse trabajando en un equipo donde se alientan o se requieren #regiones. Si eres como yo y no puedes soportar jugar con el código doblado, puedes desactivar el trazado de C #:

  1. Opciones -> Editor de texto -> C # -> Pestaña Avanzado
  2. Desmarque "Entrar en modo delimitador cuando los archivos se abren"

Eclipse hace algo de esto en Java (o PHP con complementos) por sí mismo. Te permite doblar funciones y cosas por el estilo. Me suele gustar. Si sé lo que hace una función y no estoy trabajando en ella, no necesito mirarla.


Creo que es una herramienta útil, cuando se usa correctamente. En muchos casos, creo que los métodos y enumeraciones y otras cosas que a menudo se pliegan deben ser pequeñas cajas negras. A menos que los veas por alguna razón, sus contenidos no importan y deberían estar lo más ocultos posible. Sin embargo, nunca doblo métodos privados, comentarios o clases internas. Los métodos y las enumeraciones son realmente las únicas cosas que doblo.


Las regiones nunca deben usarse dentro de los métodos. Se pueden usar para agrupar métodos, pero esto se debe manejar con extrema precaución para que el lector del código no se vuelva loco. No tiene sentido plegar los métodos con sus modificadores. Pero a veces el plegado puede aumentar la legibilidad. Por ejemplo, puede ser útil agrupar algunos métodos que utiliza para solucionar algunos problemas cuando utiliza una biblioteca externa y no desea visitarlos con demasiada frecuencia. Pero el codificador siempre debe buscar soluciones como envolver la biblioteca con clases apropiadas en este ejemplo particular. Cuando todo lo demás falla, utilice plegado para mejorar la legibilidad.


Mi enfoque es similar a algunos otros aquí, usando regiones para organizar bloques de código en constructores, propiedades, eventos, etc.

Hay un excelente conjunto de macros VS.NET de Roland Weigelt disponibles en su entrada de blog, Better Keyboard Support para #region ... #endregion . Los he usado durante años, mapeando ctrl +. colapsar la región actual y ctrl ++ para expandirla. Encuentra que funciona mucho mejor que la funcionalidad predeterminada VS.NET que pliega / despliega todo.


El artículo de Coding Horror me hizo pensar en esto también.

Generalmente, en las clases grandes ubicaré una región alrededor de las variables, las constantes y las propiedades de los miembros para reducir la cantidad de texto que tengo que desplazar y dejar todo lo demás fuera de una región. En los formularios generalmente agruparé las cosas en "variables de miembro, constantes y propiedades", funciones de formulario y manejadores de eventos. Una vez más, esto es más, así que no tengo que desplazarme por un montón de texto cuando solo quiero revisar algunos manejadores de eventos.


Emacs tiene un modo de plegado menor, pero solo lo enciendo de vez en cuando. Sobre todo cuando estoy trabajando en una monstruosidad heredada de otro físico que, evidentemente, tenía menos instrucciones o se preocupaba menos por sus prácticas de codificación.


Esta es solo una de esas tontas discusiones que no llevan a ninguna parte. Si te gustan las regiones, úsalos. Si no lo hace, configure su editor para desactivarlos. Ahí, todos están felices.


El uso de regiones (o, de lo contrario, el código de plegado) no debería tener nada que ver con los olores de código (u ocultarlos) ni con ninguna otra idea de código oculto que no desee que las personas vean "fácilmente".

El plegado de regiones y códigos se trata realmente de proporcionar una forma de agrupar fácilmente secciones de código que pueden colapsarse / plegarse / ocultarse para minimizar la cantidad de "ruido" extraño alrededor de lo que está trabajando actualmente. Si configura las cosas correctamente (lo que significa realmente nombrar algo útil para sus regiones, como el nombre del método que contiene), puede colapsar todo excepto la función que está editando actualmente y aún mantener un cierto nivel de contexto sin tener que ver realmente el otro líneas de código

Probablemente debería haber algunas pautas del tipo de mejores prácticas en torno a estas ideas, pero utilizo las regiones extensivamente para proporcionar una estructura estándar a mis archivos de código (I eventos grupales, campos de toda la clase, propiedades / métodos privados, propiedades / métodos públicos). Cada método o propiedad también tiene una región, donde el nombre de la región es el nombre del método / propiedad. Si tengo un montón de métodos sobrecargados, el nombre de la región es la firma completa y luego ese grupo completo se envuelve en una región que es solo el nombre de la función.


El plegado de regiones estaría bien si no tuviera que mantener manualmente las agrupaciones de regiones en función de las características de mi código que son intrínsecas al lenguaje. Por ejemplo, el compilador ya sabe que es un constructor. El modelo de código del IDE ya sabe que es un constructor. Pero si quiero ver una vista del código donde los constructores están agrupados, por alguna razón tengo que replantear el hecho de que estos elementos son constructores, colocándolos físicamente juntos y luego poniendo un grupo alrededor de ellos. Lo mismo ocurre con cualquier otra forma de segmentar una clase / estructura / interfaz. ¿Qué pasa si cambio de opinión y quiero ver primero el material público / protegido / privado dividido en grupos y luego agrupado por tipo de miembro?

El uso de regiones para marcar propiedades públicas (por ejemplo) es tan malo como ingresar un comentario redundante que no agrega nada a lo que ya es discernible del código mismo.

De todos modos, para evitar tener que usar regiones para ese propósito, escribí un complemento IDE de Visual Studio 2008 gratuito y de código abierto llamado Ora. Proporciona una vista agrupada de forma automática, por lo que es mucho menos necesario mantener la agrupación física o utilizar regiones. Puede ser útil .


Generalmente encuentro que cuando se trata de código como Eventos en C # donde hay alrededor de 10 líneas de código que son solo parte de una declaración de evento (la clase EventArgs la declaración de delegado y la declaración de evento) Poniendo una región alrededor de ellos y luego plegándolos del camino lo hace un poco más legible.


Esto fue hablado en Coding Horror .

Mi creencia personal es que son útiles, pero como todo en exceso puede ser demasiado.

Lo uso para ordenar mis bloques de código en:
Enumeraciones
Declaraciones
Constructores
Métodos
Manejadores de eventos
Propiedades


Yo personalmente odio las regiones El único código que debería estar en las regiones en mi opinión es el código generado. Cuando abro el archivo siempre comienzo con Ctrl + M + O. Esto se pliega al nivel del método. Cuando tiene regiones, no ve más que nombres de regiones.

Antes de registrarme, agrupo métodos / campos lógicamente para que se vea bien después de Ctrl + M + O. Si necesita regiones, tiene muchas líneas en su clase. También encuentro que esto es muy común.

region ThisLooksLikeWellOrganizedCodeBecauseIUseRegions

// basura total, sin estructura aquí

endregion


Enumeraciones

Propiedades

.ctores

Métodos

Manejadores de eventos

Para eso uso regiones. No tenía idea de que pudieras usarlos dentro de los métodos.

Suena como una idea terrible :)


Si bien entiendo el problema, Jeff, et. Alabama. tener con las regiones, lo que no entiendo es por qué presionar CTRL + M , CTRL + L para expandir todas las regiones en un archivo es tan difícil de tratar.


@ Tom

Se proporcionan clases parciales para que pueda separar el código generado automáticamente de la herramienta de cualquier personalización que necesite realizar después de que el gen del código haya cumplido su cometido. Esto significa que su código permanece intacto después de volver a ejecutar el codegen y no se sobrescribe. Ésto es una cosa buena.