Primero lea la guía para nuevos programadores.

Pautas básicas y estilo del código

La mayor parte de lo siguiente debería ser de sentido común para cualquiera que haya trabajado para proyectos de código libre o en ambientes de desarrollo comerciales. Lo siguiente se aplica sobre todo para el desarrollo de la rama principal i2p.i2p. Las guías para otras ramas, pluguins y aplicaciones externas pueden ser bastante diferentes, pregúntele al desarrollador indicado en tal caso.

Comunidad

• Please don't just "write code". If you can, participate in other development activities, including: development discussions and support on IRC, zzz.i2p, and i2pforum.i2p; testing; bug reporting and responses; documentation; code reviews; etc.
• Los programadores activos deberían estar disponibles periódicamente en el canal #i2p-dev del IRC. Tenga en cuenta el ciclo de liberación de versiones actual. Fix this! not translated all yet!!!

Ciclo de publicación

Our normal release cycle is 6-12 weeks. Following are the approximate deadlines within a typical 8-week cycle. Actual deadlines for each release are set by the lead developer after consultation with the full team.

• 1-2 días después de la publcación previa: Se permiten inserciones en al ramal troncal (trunk).
• 2-3 semanas depués de la publicación previa: Fecha límite para propagar cambios principales de otros ramales hacia el troncal (trunk).
• 4-5 semanas antes de la publicación: Fecha límite para solicitar nuevos enlaces para la página de inicio.
• 3-4 semanas antes de la publicación: Congelación de características. Fecha límite para nuevas características principales.
• 2-3 semanas antes de la publicación: Mantenimiento de una reunión del proyecto para revisar las peticiones de nuevos enlaces para la página de inicio, si hay alguna.
• 10-14 days before release: String freeze. No more changes to translated ("tagged") strings. Push strings to Transifex, announce translation deadline on Transifex.
• 10-14 days before release: Feature deadline. Bug fixes only after this time. No more features, refactoring or cleanup.
• 3-4 days before release: Translation deadline. Pull translations from Transifex and check in.
• 3-4 days before release: Checkin deadline. No checkins after this time without the permission of the release builder.
• Horas antes de la publicación: Fecha límite de revisión de código.

Git

• Have a basic understanding of distributed source control systems, even if you haven't used git before. Ask for help if you need it. Once pushed, checkins are forever, there is no undo. Please be careful. If you have not used git before, start with baby steps. Check in some small changes and see how it goes.
• Test your changes before checking them in. If you prefer the checkin-before-test development model, use your own development branch and propagate back to i2p.i2p once it is working well. Do not break the build. Do not cause regressions. In case you do (it happens), please do not vanish for a long period after you push your change.
• Si su cambio no es trivial, o desea que otra gente lo pruebe y necesita reportes fiables para saber si su cambio ha sido probado o no, añada un comentario de confirmación en history.txt e incremente la versión de compilación en RouterVersion.java.
• Ensure that you 'git pull' to the latest revision before you check in and push. If you inadvertently diverge, merge and push as soon as possible. Don't routinely make others merge for you.
• Do not check in major changes into the main i2p.i2p branch late in the release cycle. If a project will take you more than a couple days, create your own branch in git and do the development there so you do not block releases.

Estilo de programación

• El código de estilo en la mayoría de los casos es de usar la sangría de 4 espacios. No use tabulación. No cambie el formato del código. Si su editor o IDE quiere cambiar el formato configúrelo para que no lo haga. Sí, sabemos que usar 4 espacios es doloroso, pero probablemente pueda configurar su editor apropiadamente. En algunos casos el estilo de programar es diferente, use el sentido común, emule el estilo del archivo que está modificando.
• Todas las nuevas clases y métodos, públicos y de paquetes-privados, requieren Javadocs. Añada '@since número-de-versión'. Javadocs es deseable para nuevos métodos privados.
• Para cualquier Javadoc añadido, no debe haber ningún error o advertencia de doclint. Ejecute 'ant javadoc' con Oracle Java 8 o superior para comprobarlo. Todos los parámetros deben tener líneas @param, todos los métodos no-nulos deben tener líneas @return, todas las excepciones declaradas lanzadas deben tener líneas @throws, y no debe haber errores HTML.
• Las clases del núcleo/ (i2p.jar) y partes de i2ptunnel están incluidas en el API oficial. Hay varios pluguins y otras aplicaciones que dependen de este API. Tenga cuidado de no hacer cambios que rompan la compatibilidad. No añada métodos al API a no ser que sean de utilidad general. Los Javadocs de los métodos del API deben ser claros y completos. Si añade cambios al API, debe también actualizar la documentación en la web (i2p.www branch).
• Tag strings for translation where appropriate, which is true for all UI strings. Don't change existing tagged strings unless really necessary, as it will break existing translations. Do not add or change tagged strings after the "tag freeze" in the release cycle so that translators have a chance to update before the release.
• Siempre que pueda use clases genéricas y concurrentes. I2P es una aplicación multi-hilos.
• Familiarícese con las trampas comunes de Java que son atrapadas por findbugs. Ejecute 'ant findbugs' para saber más.
• We require Java 8 to build and run I2P as of release 0.9.47. Do not use Java 7 or 8 classes or methods in embedded subsystems: addressbook, core, i2ptunnel.jar (non-UI), mstreaming, router, routerconsole (news only), streaming. These subsystems are used by Android and embedded applications that require only Java 6. All classes must be available in Android API 14. Java 7 language features are acceptable in these subsystems if supported by the current version of the Android SDK and they compile to Java 6-compatible code.
• Try-with-resources cannot be used in embedded subsystems as it requires java.lang.AutoCloseable in the runtime, and this is not available until Android API 19 (KitKat 4.4).
• The java.nio.file package cannot be used in embedded subsystems as it is not available until Android API 26 (Oreo 8).
• Other than the above limitations, Java 8 classes, methods, and constructs may be used in the following subsystems only: BOB, desktopgui, i2psnark, i2ptunnel.war (UI), jetty-i2p.jar, jsonrpc, routerconsole (except news), SAM, susidns, susimail, systray.
• Plugin authors may require any minimum Java version via the plugin.config file.
• Convierta explícitamente entre tipos primitivos y clases; no confíe en autoboxing/unboxing.
• No use URL. Use URI.
• No atrape Exception. Atrape RuntimeException y excepciones marcadas individualmente.
• No use String.getBytes() sin un argumento con el juego de caracteres UTF-8. También puede usar DataHelper.getUTF8() o DataHelper.getASCII().
• Especifique siempre un juego de caracteres UTF-8 al leer o escribir ficheros. Las utilidades DataHelper le pueden ser de ayuda.
• Especifique siempre una localización (por ejemplo Locale.US) al usar String.toLowerCase() o String.toUpperCase(). No use String.equalsIgnoreCase(), ya que no se puede especificar una localización.
• No use String.split(). Use DataHelper.split().
• Don't add code to format dates and times. Use DataHelper.formatDate() and formatTime().
• Asegúrese de que InputStreams y OutputStreams están cerrados en los bloques del final.
• Use {} para todos los bloques for y while, incluso si sólo tienen una línea. Si usa {} para cualquiera de los bloques if, else, o if-else, úselo para todos los bloques. Ponga "} else {" en una sola línea.
• Especifique los campos al final siempre que sea posible.
• No almacene I2PAppContext, RouterContext, Log, o cualquier otra referencia al router I2P o a elementos de contexto específicos, en campos estáticos.
• No inicie hilos en los constructores. Use I2PAppThread en lugar de Thread

Logging

• For any messages not displayed at the default log level (WARN, INFO, and DEBUG), unless the message is a static string (no concatenation), always use log.shouldWarn(), log.shouldInfo(), or log.shouldDebug() before the log call to avoid unnecessary Object churn.
• Log messages that may be displayed at the default log level (ERROR, CRIT, and logAlways()) should be brief, clear, and understandable to a non-technical user. This includes exception reason text that may also be displayed. Consider translating if the error is likely to happen (for example, on form submission errors). Otherwise, translation is not necessary, but it may be helpful to search for and reuse a string that is already tagged for translation elsewhere.
• Log messages not displayed at the default log level (WARN, INFO, and DEBUG) are intended for developer use, and do not have the above requirements. However, WARN messages are available in the Android log tab, and may be of assistance to users debugging issues, so use some care with WARN messages as well.
• INFO and DEBUG log messages should be used sparingly, especially in hot code paths. While useful during development, consider removing them or commenting them out after testing is complete.
• Do not log to stdout or stderr (wrapper log).

Licencias

• Sólo suba el código que ha escrito usted. Antes de subir el código o librerías de otras fuentes, verifique que la licencia es compatible, y obtenga permiso del desarrollador.
• Si obtiene la aprobación para añadir código o jars externos, y los binarios están disponibles en cualquier paquete Debian o Ubuntu, debe implementar opciones de compilación y empaquetado para usar el paquete externo en su lugar. Lista de comprobación de ficheros a modificar: build.properties, build.xml, debian/control, debian/i2p-router.install, debian/i2p-router.links, debian/rules, sub-build.xml
• Para cualquier imagen subida de fuentes externas, es su responsabilidad verificar primero si la licencia es compatible. Incluya la licencia y la información de la fuente en el comentario de subida.

Bugs

• Mantener las entradas del Trac es trabajo de todos, por favor denos su ayuda. Observe el trac.i2p2.de por entradas que le hayan sido asignadas o en las que pueda ayudar. Asigne, categorice, comente, arregle, o cierre entradas si puede.
• Los nuevos desarrolladores deben comenzar por reparar un fallo. Busque fallos con la palabra clave 'easy' (fácil) en trac (monitor de fallos). Cuando tenga una reparación, adjunte su parche a la entrada (ticket) y añada la palabra clave 'review-needed' (precisa revisión). No cierre la entrada hasta que haya sido revisada con éxito y usted haya inscrito sus cambios. Una vez haya realizado esto sin dificultad con un par de entradas, puede seguir el procedimiento normal debajo.
• Cierre la entrada cuando piense que la ha arreglado. No tenemos un departamento de pruebas para verificar las entradas cerradas. Si no está seguro de haberlo solucionado, ciérrela y añada una nota diciendo "I think I fixed it, please test and reopen if it's still broken". Añada un comentario con el número de compilación o la revisión y establezca el hito para la siguiente versión.