¿El desarrollo de C # es efectivamente inseparable del IDE que usa?

Soy un programador de Python que está aprendiendo C # que está tratando de dejar de preocuparse y simplemente ama C # por lo que es, en lugar de compararlo constantemente con Python.

Estoy atrapado en un punto: la falta de información explícita sobre dónde se definen las cosas, como se detalla en esta pregunta de Stack Overflow . En resumen: en C #, using foono le dice de qué nombres fooestán disponibles, lo que es análogo a from foo import *Python, una forma que se desaconseja dentro de la cultura de codificación de Python por ser implícita en lugar del enfoque más explícito from foo import bar.

Me sorprendieron bastante las respuestas de Stack Overflow a este punto de los programadores de C #, que era que, en la práctica, esta falta de explicidad realmente no importa porque en su IDE (presumiblemente Visual Studio) puede pasar el cursor sobre un nombre y se lo dirá El sistema de donde proviene el nombre. P.ej:

Ahora, en teoría, me doy cuenta de que esto significa que cuando buscas con un editor de texto, no puedes saber de dónde provienen los tipos en C # ... pero en la práctica, no creo que eso sea un problema. ¿Con qué frecuencia estás mirando el código y no puedes usar Visual Studio?

Esto es revelador para mí. Muchos programadores de Python prefieren un enfoque de editor de texto para la codificación, usando algo como Sublime Text 2 o vim, donde se trata del código, además de herramientas de línea de comandos y acceso directo y manipulación de carpetas y archivos. La idea de depender de un IDE para comprender el código a un nivel tan básico parece anatema. Parece que la cultura C # es radicalmente diferente en este punto. Y me pregunto si solo necesito aceptar y aceptar eso como parte de mi aprendizaje de C #.

Lo que me lleva a mi pregunta aquí: ¿el desarrollo de C # es efectivamente inseparable del IDE que usa?

Visual Studio es tan conveniente que después de trabajar con él por un tiempo es difícil usar un IDE diferente. Tiene muchas herramientas útiles y un montón de complementos disponibles, por lo que prácticamente tiene todas las funciones que necesitaría.

Por otro lado, sea cual sea el idioma que aprenda, se recomienda utilizar la línea de comandos al principio, para que pueda comprender mejor cómo funciona. C # no es una excepción.

¿El desarrollo de C # es efectivamente inseparable del IDE que utiliza?

Teóricamente no, pero prácticamente sí. Es posible escribir en C # usando un editor de texto y una línea de comando, pero si tiene Visual Studio, nunca lo haría. De hecho, muy pocos programadores han ejecutado código C # desde la línea de comandos.

Por cierto, si se siente incómodo using foo, puede usar toda la ruta al usar un tipo.

La idea de depender de un IDE para comprender el código a un nivel tan básico parece anatema.

No se trata de entender su código: dado el tiempo suficiente, siempre puede localizar la variable correcta con un editor de texto básico o incluso en una copia impresa. En lo que respecta a la comprensión del código, la dependencia IDE no existe en absoluto.

Localizar sus referencias de manera eficiente es un tema completamente diferente: me encanta la capacidad de encontrar usos de variables Java en Eclipse tanto como me encanta encontrar puntos de declaración en Visual Studio, tanto para C # como para C ++. Prefiero pasar mi tiempo codificando, en lugar de buscar puntos de declaración manualmente. Esto es similar a hacer matemáticas: puedo multiplicar números de varios dígitos en una hoja de papel, pero prefiero usar la calculadora para ahorrarme uno o dos minutos.

Comenzando en un cierto "tamaño crítico" del código, un buen IDE se vuelve muy útil independientemente del lenguaje de programación. El tamaño puede variar de un idioma a otro, pero una vez que cruza varios miles de líneas, tener un IDE ayuda independientemente de su idioma. Esto tiene más que ver con las limitaciones de una mente humana que con un lenguaje de programación particular: en algún momento, su memoria a corto plazo está destinada a "desbordarse".

Hay trucos que le permiten aumentar ese tamaño crítico donde IDE se vuelve útil. Por ejemplo, podría seguir una convención de nomenclatura (los nombres húngaros fueron importantes en el mundo de C ++ en algún momento, especialmente entre los profesionales de Windows). Otro truco común es calificar las variables de instancia this.incluso en contextos donde no se requiere dicha calificación.

Estos trucos vienen con compensaciones: casi inevitablemente, hacen que su programa sea menos legible al ocultar nombres o al insertar las referencias explícitas que la encapsulación pretendía ocultar. Ante la elección, elijo un código de aspecto limpio más un IDE sobre un código de aspecto menos limpio menos un IDE. Sin embargo, reconozco plenamente que las elecciones de otras personas pueden diferir de las mías.

Muchos programadores de Python prefieren un enfoque de editor de texto para la codificación, usando algo como Sublime Text 2 o vim, donde se trata del código, además de herramientas de línea de comandos y acceso directo y manipulación de carpetas y archivos.

Eso es genial, pero se pierde el punto de VS IDE. El objetivo de un IDE como VS es un rápido soporte de desarrollo a través de herramientas de código fuertes como refactorización e intellisense. VS es un editor muy muy bueno para el código C #.

Ahora C # le permite codificar en un estilo que depende de su IDE en mayor medida (puede usar muchas varpalabras clave y similares). Algunas personas prefieren ser más explícitas, por ejemplo, utilizando alias de espacio de nombres para tener claro a qué espacio de nombres pertenece una clase (como importen Java o Python). Esa es más una opción de estilo de codificación que una característica del lenguaje.

Como C # se escribe estáticamente (aunque con algunas extensiones dinámicas, a partir de v4) siempre es bastante fácil averiguar a qué tipos se hace referencia; si están equivocados, el código no se compilará y VS no es el único IDE con soporte para C # intellisense. Sin embargo, es probablemente el mejor.

Desarrollar C # sin un IDE potente (como VS) es como martillar clavos con la mano cuando ya tienes una pistola de clavos de alta gama; puede que sea el momento extraño que necesites hacerlo, pero los profesionales usan la herramienta adecuada para el trabajo .

Yo diría que lo mismo es probablemente cierto también para Java. Si hay un IDE poderoso con intellisense y herramientas de refactorización de código, probablemente debería estar usándolo.

Sin embargo, mírelo al revés: si no desea intellisense, compile la verificación de código de tiempo y el análisis / refactorización de código, entonces un IDE hinchado no es el camino a seguir, y tampoco lo es un lenguaje estáticamente tipado. Creo que es al revés:

Muchos programadores que prefieren un enfoque de editor de texto para la codificación no obtienen tanto de los lenguajes tipados estáticamente (como C # y Java) y, por lo tanto, podrían estar mejor si se adhieren a los dinámicos como Python y Javascript.

Yo creo que:

• Los lenguajes dinámicos se adaptan a herramientas livianas (los IDE pesados ​​confieren menos beneficios aquí)
• Los lenguajes estáticos se adaptan a IDE potentes (las herramientas pueden ayudar con el código a costa de la flexibilidad)

Para responder a su pregunta: aunque está cambiando lentamente, el entorno de desarrollo de Microsoft ha sido en gran medida un monocultivo .

Este enfoque tiene muchos aspectos positivos y negativos, que podrían discutirse extensamente (por ejemplo, considere los pros y los contras de las plataformas abiertas y cerradas, como las PC frente a una Xbox), pero al final del día, la herramienta de Microsoft es lo que más La gente usa. La compañía también ha demostrado que su toma de decisiones es a menudo una especie de proceso de "dar el mayor valor a la mayoría de nuestros usuarios", siempre buscando compromisos prácticos (más recientemente, considere la posibilidad de Typecript ). Básicamente, no me sorprendería descubrir que el desarrollo de C # se hizo / se hace con las herramientas (VS) en mente.

Por un lado, C # no es Python. Existen diferentes metodologías de diseño.

Ahora, para responder a su pregunta, es completamente posible usar su Python-esque usando declaraciones.

using FooBar=MyName.Foo.FooBar; 

Es solo que definitivamente no es la norma porque no es tan fácil. Sin embargo, creo que debería preocuparse menos por saber exactamente de dónde viene exactamente cada clase. Sin embargo, no entiendo el punto completo de hacerlo de esta manera en Python.

Y también, C # es un lenguaje que se presta muy bien para usar IDEs para hacerlo más fácil. Intellisense es increíblemente simple de implementar, especialmente en comparación con lenguajes dinámicos como Ruby y Python. Sin embargo, no tiene que estar atascado en su IDE. He oído hablar de personas que usan Eclipse. También hay, por supuesto, MonoDevelop (que uso bastante), e incluso puedes trabajar desde una línea de comandos. En mi servidor a veces, editaré archivos C # viy luego los usaré xbuildpara reconstruirlos ... Es solo que usar un IDE hace las cosas mucho más fáciles en comparación con la línea de comandos para casos típicos.

¿Alguien se molesta en leer aquí?

Resumo diciendo que la funcionalidad IDE masivamente compleja es indispensable y que (debería) evolucionar al Zen de Sublime VimNess algún día ...

Nuestro software tiene 129 proyectos de aproximadamente 2M LOC. Agregue la masividad del marco .NET y dado todo lo que puedo decir es que el IDE es vital, trascendiendo las motivaciones de la pregunta de este hilo.

Información sobre la base del código

Período. Conoces el tipo de características de las que estamos hablando; excepto que su conveniencia se vuelve indispensable y esencial con el tipo de código base con el que trato.

Escribo un código mejor debido al IDE. Siempre agrego mensajes personalizados a mis pruebas de Nunit porque es fácil, rápido y preciso. Estoy a favor de enumeraciones sobre cadenas debido en gran parte a intellisense. No dudo en usar nombres descriptivos / largos: una declaración de varias líneas se compone de forma rápida y limpia.

Pero incluso esta inteligencia es demasiado a veces. A menudo uso la búsqueda de texto "buscar en archivos".

Ayuda de codificación

Aquí es donde a menudo lloro "¡suficiente!". Imagine una pantalla llena con una docena de colores en su mayoría oscuros, algunas variables particulares resaltadas en todas partes, resaltando las llaves ocultando lo que realmente es la llave, subrayando onduladamente en todas partes porque "quiere" que escriba literatura, no códigos, iconos para menús contextuales de Resharper (usted solo tengo que hacer clic en él y luego ignorarlo la mayor parte del tiempo), una ventana emergente de ayuda de la firma que abarca 2/3 de la pantalla horizontalmente, verticalmente mostrando varias sobrecargas, una ventana emergente debido a donde acabas de dejar el cursor del mouse ... I ¡Ni siquiera puedo ver el & ^!% line * s * del código en el que estoy trabajando!

Vis.Stud. necesita abrazar el minimalismo para que pueda centrarme en la codificación y no pasar por cientos (miles si cuenta cada configuración de codificación de color y todos esos complementos) de configuraciones en una batalla perdida para recuperar la cordura. Una tecla " Pareto " sería genial.

¿El desarrollo de C # es efectivamente inseparable del IDE que utiliza?

Por supuesto no. ¿Por qué no importarías todo el espacio de nombres? La elección de usar un IDE integrado o un editor de texto no tiene nada que ver con eso. Importar todo el espacio de nombres no hace que sea más difícil leer el código o usarlo.

Recuerde, C # es un lenguaje escrito. Si importa varios espacios de nombres que tienen la misma clase, obtendrá un error de compilación.

Yo personalmente no uso tanto las declaraciones de tipo de ninguna manera. En cambio, uso la varpalabra clave en su lugar por las razones que describo aquí: http://blog.gauffin.org/2012/08/to-var-or-not-to-var-is-that-really-the-question/

Entendí que en Python, "todo es público" o algo por el estilo. En C #, el diseñador del módulo decide qué es público y qué no lo es, por lo que cuando lo haces importsolo obtienes la API pública de todos modos. Esa podría ser una razón de la diferencia que estás describiendo.

¿El desarrollo de C # es efectivamente inseparable del IDE que utiliza?

En mi trabajo anterior, usaba principalmente vim para codificar en lenguajes como C #, JavaScript, Powershell, Perl, C ++, y bastantes desarrolladores solían hacer algo similar. El proyecto era demasiado grande para Visual Studio.

Dicho esto, la mayoría de los desarrolladores de C # se ocupan de proyectos mucho más pequeños y están muy contentos de usar VS.

Esta es una vista interesante sobre el desarrollo de C #. Sin embargo, lo que está pidiendo va más allá de C #, si está preguntando sobre el IDE.

Como usted dice, en Python, puede usar varios editores para escribir su código. También puede hacerlo con el marco .NET. También hay otras herramientas IDE que puede usar, como SharpDevelop. Visual Studio está muy desarrollado en conjunto con el marco .NET y es relativamente costoso. Existen herramientas como SharpDevelop y las versiones "Express" de VS para atraer a más desarrolladores a usar .NET. Esencialmente, todo lo que un IDE hace por usted es proporcionar un entorno organizado, generalmente con complementos inteligentes para la productividad y un "ayudante" para ensamblar lo que puede terminar siendo una línea de comandos de aspecto muy aterrador para pasar a su compilador. Lo mismo es cierto para Java, las herramientas como Eclipse solo nos proporcionan mejoras en la organización y la productividad. Bajo el capó, no ocurre nada mágico hasta que construyes o compilas tu proyecto y ese respeto,

Cuando habla sobre la declaración de "uso" en C # y la compara con Python, no es realmente lo mismo que sucede debajo del capó. El compilador utiliza las instrucciones de uso para ayudarlo a transformar su código C # en MSIL. En MSIL, no existe la directiva "importar todas estas clases desde este espacio de nombres". Cuando el código de tiempo está en el nivel MSIL, todas las clases han sido etiquetadas con sus nombres completos. Estas declaraciones de "uso" e "importación" son para ayudar a la legibilidad humana. No son comandos de optimización del compilador. Después de que todo este "etiquetado inicial de nombres completamente calificados" haya continuado, podría haber una especie de "minificación" de bajo nivel para los FQN, pero esto es para ayudar al compilador / intérprete a ejecutarse más rápido.

Una diferencia fundamental final entre todos estos lenguajes mencionados aquí es que algunos de ellos son interpretados por máquinas virtuales, algunos son interpretados al estilo JIT y otros están completamente compilados. La forma en que se implementan estas directivas de uso en esos compiladores e intérpretes es muy diferente.

HTH.

Creo que históricamente la respuesta es más o menos sí: conseguir que el desarrollo de C # se ejecute de manera efectiva en cualquier cosa fuera de Visual Studio, Xamarin o SharpDevelop fue una experiencia demasiado desagradable.

Pero recientemente han surgido muchos proyectos que lo hacen más fácil, por ejemplo:

OmniSharp , proporciona una base para intellisense y refactorización, junto con vim, emacs, atom y complementos sublimes. En realidad no lo he usado, así que no sé qué tan bien funciona, pero parece prometedor.

Los generadores Yeoman ASP.NET MVC ayudan a arrancar un nuevo proyecto MVC (quizás existan otros generadores).

paket , una alternativa a NuGet donde puede agregar paquetes NuGet a su proyecto desde la línea de comandos y actualizar sus archivos .csproj (aunque había una herramienta de línea de comandos NuGet, actualizar los proyectos para usar los paquetes era parte del IDE integración, no herramientas de línea de comandos).

Paket tiene la implicación de que tiene que adaptar su código fuente para usarlo, por lo que si se sienta como el único miembro de un equipo y quiere usar un editor de texto para la codificación, y todos los demás usan Visual Studio, tendría que convencer a todos más para adaptar la solución a sus necesidades :(

Por lo tanto, debería poder ponerse en funcionamiento, pero hay mucho más trabajo por hacer para que su cadena de herramientas funcione de manera eficiente.

Ya no:

http://www.omnisharp.net/

OmniSharp es una familia de proyectos de código abierto, cada uno con un objetivo: permitir un excelente desarrollo de .NET en el editor de su elección.

Es divertido decir Cross Platform .NET. ¿Pero es razonable que alguien desarrolle .NET sin Visual Studio y Windows?

¿Es divertido hacer .NET en una Mac en Sublime? Ubuntu y Emacs? Windows y Atom? Puede usar su editor ADEMÁS para usar excelentes funciones como Intellisense (no solo Autocompletar), Agregar referencia, Formatear documento y mucho más. Desarrolle en cualquier lugar, implemente en cualquier lugar (¡y en Azure!)

He probado esto con subime3 y osx

Más muestras en

http://blog.jonathanchannon.com/2014/11/12/csharp-first-class-citizen-sublime-text/