Etiqueta de código abierto

14

Empecé a trabajar en mi primer proyecto de código abierto en Codeplex y encontré un código terrible. (Aprendí que C # todavía tiene la declaración "goto") Comencé a agregar funciones que el "propietario" quería y después de explorar el código base y ver qué desorden era (p. Ej., Usar "goto") quería limpiarlo un poco. Pero estoy un poco preocupado y es por eso que me dirijo a todos: ¿es adecuado para mí "arreglar" el "código incorrecto" o debo dejar que sea y trabajar en nuevas funciones? Como dije antes, soy nuevo en toda la escena de OSS y trabajo en un equipo en general, por lo que me gustaría no estropearlo.

    
pregunta Jetti 24.03.2011 - 13:47

7 respuestas

18

Está bien hacer esto, si eres modesto al respecto y no rompe nada . No se puede cambiar el formato de código e introducir errores. ¿Tiene buenas pruebas unitarias? Si no, comenzaría a contribuir agregando pruebas unitarias y luego iré a arreglar la estructura más adelante.

    
respondido por el Scott Whitlock 24.03.2011 - 13:59
13

El propósito del código abierto es obtener más información sobre un proyecto y mejorarlo. Eso incluye hacer el código mejor. Dicho esto, es una buena forma de anunciar en la lista lo que pretende hacer. Puede que obtengas un poco de retroceso, o puedes obtener un montón de +1. Esas declaraciones goto podrían estar ahí porque el autor original no pudo pensar en una mejor manera de hacer el trabajo. Si retrocede, es bueno entrar en un diálogo para averiguar de dónde proviene la presión. Trate de no permitir que se vuelva personal, y trate de abordar las inquietudes.

En pocas palabras, las pruebas unitarias hablan más que el dogma. Si puedes probar que el código funcionará mal en ciertos casos, tal como está ahora, obtendrás el visto bueno o el autor original irá y arreglará las cosas.

Recuerde, en código abierto, la comunidad es más importante que el código. Si no hay comunidad (tanto de usuarios como de desarrolladores), entonces no hay proyecto.

    
respondido por el Berin Loritsch 24.03.2011 - 14:09
6

Las personas que son celosamente defensivas con respecto a su código generalmente no lo publican para que el mundo lo examine, y si lo hacen, la comunidad que lo rodea no dura mucho tiempo. Tenga mucho tacto, pero no se preocupe de herir los sentimientos.

Solo dígales lo que quiere hacer antes de invertir demasiado tiempo en ello. A veces hay razones históricas para cosas que no son obvias. La razón por la que se evitan los gotos es que pueden producir rutas no anticipadas a través del código. En consecuencia, el peligro de eliminar gotos es que no se nota uno de los caminos beneficiosos y se omite accidentalmente del refactor.

Por otro lado, tal vez el autor original simplemente no haya podido pensar en una forma más limpia de escribirlo en ese momento. Aquí es donde el código habla más fuerte que las palabras, ya que pueden creer que no se puede hacer de forma más limpia hasta que las muestres. Una de mis primeras contribuciones de código abierto fue una solución para deshacer la pila que mejoró significativamente el rendimiento, pero que algunos de los desarrolladores centrales dijeron que sonaban demasiado complejos cuando lo describí por primera vez. Un ejemplo de código corto los llevó a bordo.

Si resulta que realmente hay buenas razones para dejarlo, presionaría al menos por un comentario que explique esas razones.

    
respondido por el Karl Bielefeldt 25.03.2011 - 13:45
6

Hablando desde la experiencia ...

El primer proyecto de código abierto al que contribuí, estaba lleno de orina y vinagre cuando empecé también.

Lo que hice inmediatamente fue revisar un montón de archivos de origen y comenzar a estilizar las cosas según mis preferencias personales, crear un parche masivo y enviarlo.

Si estás trabajando con alguien que es "bueno" (como yo lo era) (s), rechazará el parche de inmediato. Principalmente porque, cuando contribuyes a un proyecto de código abierto, se espera que dividas tus arreglos en trozos de tamaño de bocado que aborden un solo problema. 'Eliminado todos los gotos' no es un buen ejemplo de una confirmación atómica. Incluso si primero lo divide en comillas más pequeñas y bien documentadas, podría ser rechazado.

La razón es que, dado que varias personas (con diferentes estilos) trabajan el código a lo largo del tiempo, no es realmente posible aceptar cambios en toda la biblioteca para adaptarse al estilo de un desarrollador. Si fuera posible cambiar el estilo por el estilo, cada proyecto de código abierto nunca avanzaría porque el código se editaría constantemente para adaptarse a diferentes estilos de desarrolladores.

El código de refactorización y la adición de funciones (o la eliminación de cruceros en desuso) generalmente tiene prioridad sobre el código de "limpieza".

La parte más difícil y más gratificante de trabajar en un proyecto de código abierto es, se le preguntará por qué está proponiendo realizar los cambios que está enviando. Si puede dar una buena razón, hay más posibilidades de que se envíe su parche.

Mi consejo es que hagas algunos de estos cambios en un archivo fuente para darte una idea de lo que intentas hacer primero. Si los cambios están bien justificados y aceptados, pregunte si hay más cambios que mejoren la calidad del proyecto. De esa manera, no perderá mucho esfuerzo si no se rechazan sus parches en el futuro.

Desarrollar código abierto es más que escribir código. Estás trabajando para construir una relación de confianza porque los guardianes (desarrolladores que controlan el acceso push) harán lo que tienen que hacer para proteger la integridad del proyecto. A medida que envíe más parches, el controlador de acceso obtendrá una mejor idea de su estilo y no tendrá que justificar sus cambios tanto.

Es un proceso que lleva tiempo pero es muy gratificante. No solo aprenderá mucho al poder mirar y criticar el código de otra persona, sino que también será criticado por su propio estilo.

Antes de perder mucho tiempo tratando de 'corregir la injusticia de los errores del estilo de codificación de otros' pregúntate esto:

  

¿Los cambios que está proponiendo se basan en agregar valor al proyecto o se basan en su propia religión estilística interna?

Hay un lote de religión en Stack Overflow (y en sitios de Intercambio de Stack relacionados). Me refiero a un lote . La gente piensa y habla sobre el estilo sin fin, como si cuanto más habla sobre él, más se acerque al estilo de codificación "perfecto, ideal, indestructible e infalible". Hablo mucho sobre eso, principalmente porque es divertido.

En el mundo de código abierto, el estilo no es tan importante. La función es .

Nota: Todos estos consejos asumen que su controlador de acceso es un programador razonable y talentoso. Si él (s) lo está, considérese afortunado de no haberse quedado atascado con uno de los b @ & # & es que su única preocupación es proteger a su "bebé". Existen existen en la naturaleza, así que no te sorprendas si te encuentras con uno.

    
respondido por el Evan Plaice 25.03.2011 - 15:40
1

Calidad > Etiqueta

En mi opinión, no debería preocuparse por editar el código de otras personas tan pronto como descubra que es de baja calidad. Para lograr una buena calidad de software, simplemente tiene que cuidar el código limpio. No veo ningún problema al cometer mejoras en el código de otras personas, otras personas deben ser conscientes y agradecidos de que hay programadores que trabajan en su código.

    
respondido por el Ham 24.03.2011 - 13:53
0

Si pudieras encontrar una mejor manera de resolver el problema sin usar "goto", te sugiero que lo intentes. Un poco de esfuerzo para mejorar el código hoy puede ahorrarle mucho más esfuerzo en el futuro.

La comunicación con el autor original también es una buena idea.

    
respondido por el Ida 24.03.2011 - 16:12
0

No hay nada implícitamente mal con goto . Mire el código de ensamblaje: muchos gotos (saltos y ramas) por todo el lugar.

La razón por la que goto tiene un mal nombre en estos días se debe al artículo de Dijkstra Ir a La declaración se consideró dañina , que identificó la declaración de goto como algo muy malo.

Tenga en cuenta que eso fue hace 50 años donde la ingeniería del software aún no tenía nombre, y la mayoría de los lenguajes de programación eran esencialmente abstracciones de la máquina subyacente, ya que el lenguaje de la máquina contenía goto, también lo hicieron. Puedes intentar programar algunos en Microsoft Basic (el original, en Apple] [o Commodore 64) para tener una idea de cómo era esa mentalidad.

Lo que Dijkstra estaba argumentando era que para mantener las cosas simples no salte por todos lados, sino que mantenga una ruta de programa más simple con un final común. P.ej. Un retorno de un método. En otras palabras, solo saltos locales, no globales.

Este fue un paso hacia la introducción de elementos como llamadas a métodos con argumentos, modularización de código, paquetes, etc. que se han introducido para controlar la complejidad del desarrollo de software. La declaración de goto fue solo el primer espectador en esa guerra.

    
respondido por el Thorbjørn Ravn Andersen 11.02.2017 - 13:35

Lea otras preguntas en las etiquetas