Como contribuir - jackgris/wikiLibGDX_es GitHub Wiki

1.3 Como contribuir

Contribuir con libgdx es fácil:

Cambios y agregados en la API

Si modifica una API pública, o añade una nueva, asegúrese de agregar estos cambios en el archivo CHANGES en la raíz del repositorio. Además de el archivo CHANGES, esas modificaciones se publicaran en el blog y en Twitter para llegar a toda la comunidad. Si usted desea sondear el pensamiento de otros desarrolladores, ya sea enviando un pull request eh iniciando una conversación en GitHub, o iniciando un nuevo hilo en este sub-foro Usted va a necesitar una autorización especial en el foro, escríbame un mail al correo de contacto en badlogicgames punto com y dígame su ID en el foro. También debería suscribirse a ese foro a través de correo electrónico, hay un botón en la parte inferior de la página para eso. Además puede pasar por el IRC (irc.freenode.org, #libgdx), donde la mayoría de los desarrolladores del core están al acecho.

Acuerdo de licencia para los que contribuyen

Libgdx esta licenciado bajo Apache 2.0. Antes de que podamos aceptar contribuciones de código, necesitamos que firme nuestro contrato de licencia de colaborador . Solo debe imprimirlo, llenar los espacios en blanco y enviar una copia [email protected], con el asunto '[Libgdx] CLA'. La firma de la CLA nos permitirá usar y distribuir su código. Se trata de una licencia no exclusiva, para que conserve todos los derechos sobre su código. Es a prueba de fallas para no tener a alguien que contribuye con código esencial y más tarde decide tomarlo de vuelta.

Eclipse Formatter

Si trabaja con el código de libgdx, necesitamos que utilice el Eclipse Formatter localizado en el directorio raíz del repositorio. Si no utilizas el formateador vas a darle lugar a Nate, y el es muy molesto. Si estas utilizando IntellijIDEA, igual poder hacer uso del formateador de código de Eclipse: mire este artículo

Estilo del código

Libgdx no tiene un estándar oficial de codificación. Sobre todo seguimos el estilo habitual de Java, y usted debería hacerlo también.

Algunas cosas que prefiero no ver:

  • guiones bajos en cualquier tipo de identificador
  • notación húngara
  • prefijos para campos o argumentos
  • llaves en nuevas líneas

Si modifica un archivo existente, siga el estilo de código que tiene. La llaves pueden omitirse solo si no se pierde nada de legibilidad. Si crea un nuevo archivo, asegúrese de agregar el encabezado de Apache, como se ve aquí Si crea una nueva clase, por favor, al menos agregue la documentación de la clase donde explique su uso y alcance. Puede omitir el Javadoc de métodos que son sencillos de entender.

Si la clase es explícitamente thread-safe, menciónelo en el Javadoc. Por defecto se asume que la clase no es thread-safe. Para reducir la cantidad de bloqueos costosos para el código base.

Consideraciones sobre el rendimiento

Libgdx esta destinado a funcionar en plataformas de escritorio y móviles, incluyendo navegadores (Javascript!!!). Mientras que en el escritorio la VM HotSpot puede tener una buena paliza de asignaciones innecesarias, la Dalvik VM y compañía no.

Un par de cosas a tener en cuenta:

  • Evitar la asignación de objetos temporales siempre que sea posible.
  • No realice copias defensivas.
  • Evite los bloqueos, las clase en libgdx por defecto no son thread-safe a menos que este especificado explícitamente.
  • No utilice boxed primitives (Integer, Long, etc)
  • Use las clases de colecciones dentro del paquete com.badlogic.gdx.utils
  • No realice comprobaciones de argumentos para los métodos que puedan ser llamados miles de veces por cuadro (frame)
  • Si es necesario utiliza pooling, si es posible, evitar la exposición del pooling para el usuario, ya que esto complica la API.

Git

La mayoría de los miembros del equipo de libgdx son usuario de Git novatos, como tal, estamos aprendiendo del oficio nosotros mismos. Para disminuir el riesgo de realizar algo mal, nos gustaría pedirles amablemente que mantenga las pull request lo más pequeños posibles. Con un cambio de 3000 archivos probablemente nunca se realizara un merge.

Hacemos abrir un nuevo branch cuando se desean realizar grandes cambios en la API. Si nos ayuda a sacar una nueva API, asegúrese de que su pull request se dirija al branch especifico.

Los pull request para el branch master del repositorio va a ser verificado por múltiples contribuidores del core antes de que se incluya. Podemos rechazar su pull request al master si no consideramos que este listo o sea acorde a lo necesario. Por favor en ese caso no se ofenda. Libgdx es utilizado por miles de proyectos en el mundo, tenemos que asegurarnos de que las cosas queden cuerdas y estables.

Enlaces