Repository navigation
Estilo de código
Caution
NO MODIFIQUES EL CÓDIGO EXISTENTE SOLO PARA CAMBIAR EL ESTILO
Si estás editando el código existente de manera significativa, entonces está bien cambiar el estilo. De lo contrario, mantén las adiciones de forma coherente con el código adyacente. Los cambios que son únicamente de estilo de código representan un desperdicio de recursos y son una falta de respeto al colaborador que escribió el código original; cualquier cambio de este tipo será deshecho o rechazado.
Esto incluye, pero no se limita a:
- 🚫 Añadir o eliminar líneas en blanco.
- 🚫 Cambiar el estilo de los comentarios.
- 🚫 Cambiar el estilo de los saltos de línea.
- 🚫 Cambiar la sangría (excepto para corregir errores de sintaxis).
De lo contrario, el equipo de desarrollo oficial no tiene una guía de estilo estricta, pero aquí hay un par de convenciones que suelen seguir:
- Sangrías de cuatro espacios. ⌨️
Los nombres de las etiquetas deben estar en minúsculas y separados por guiones bajos (monika_twitter).
Si utilizas muchas etiquetas para un subprograma relacionado, colócales el prefijo mas y el nombre de tu subprograma (por ejemplo: mas_coolfungame_flowstart).
Note
Excepciones a esta regla: temas, saludos y despedidas de Monika, aunque esto podría cambiar en el futuro.
Ciertos prefijos están reservados:
- 📥
greeting: usado para saludos regulares. - 💬
i_greeting: usado para saludos interactivos especiales. - 📖
ch30: usado para etiquetas clave del capítulo 30. - 💚
monika: usado para casi todos los temas de Monika. - 🃏
m_joke: usado también para el sistema de chistes. - 📝
mas_poem: usado para el juego de poemas. - 💝
mas_compliment: usado para cumplidos. - 😊
mas_mood: usado para estados de ánimo. - 📚
mas_story: usado para historias. - 🙏
mas_apology: usado para disculpas no genéricas. - 🎵
mas_song: usado para canciones (añade el sufijo_longpara canciones largas). - 🎮
game: usado para la mayoría de los minijuegos. - 🔄
vv/v: usado para material relacionado con actualizaciones. - 👋
bye: usado para despedidas.
Puede haber más, por lo que, en general, sé consciente de las etiquetas que utilizas. 🕵️
En Ren'Py, los stores son como espacios de nombres (namespaces), excepto que no pueden anidarse. Recomendamos agrupar datos relacionados, constantes y funciones en stores para evitar alterar el espacio de nombres global.
Para crear un store:
init python in mas_store_name:
var1 = 1
var2 = 2
...
# o
define mas_store_name.var1 = 1
define mas_store_name.var2 = 2Para acceder a un store:
store.mas_store_name.var1 = 1
# o
python:
import store.mas_store_name as mas_store_name
mas_store_name.var1 = 1El equipo de desarrollo oficial utiliza varios stores diferentes para agrupar distintos datos. Al decidir crear un nuevo store, asegúrate de que no esté ya en uso. Prefija los nombres de tus stores con mas_.
Note
persistent es como un store, pero es uno especial que se guarda en el disco. Úsalo únicamente si necesitas guardar datos entre múltiples sesiones.
Si una función es muy específica de un subprograma o flujo, considera crearla en un store e importarla cuando sea necesario. Si una función se puede generalizar para muchos casos de uso, créala en un bloque init python regular (lo que la hace global). Prefija las funciones globales con mas_.
Para la documentación, tanto los comentarios en bloque (#) como las cadenas de documentación (docstrings, """) están bien. El equipo de desarrollo oficial no impone una forma particular de documentar las funciones, pero indicar qué hace la función, sus variables de entrada y salida, qué retorna y qué variables asume sería un buen comienzo:
def mas_someKindOfFunction(var1, var2, var3=None):
"""
Esta función hace algún tipo de cosa. Úsala con precaución.
ENTRADA:
var1 - valor de algo
var3 - el valor máximo de algo
(Por defecto: None)
SALIDA:
var2 - contiene una referencia modificada a algo
RETORNA:
una copia de var2
ASUME:
persistent.var4
"""Para los nombres de las funciones, tanto camelCase como lowercase_underscores están bien.
Este elemento similar a un store guarda datos en el disco y es la forma en que Ren'Py realiza el seguimiento de los datos. Debido a que ya está cargado con datos del juego base, evita usarlo si puedes. (Es decir: en lugar de usar un persistent para verificar si se ha visto un evento, usa renpy.seen_label o seen_event).
Important
Prefija todos los nombres de variables persistentes con _mas_. (El equipo de desarrollo oficial está en proceso de convertir todos los valores persistent creados para que tengan el prefijo correcto).
Define constantes en lugar de literales cuando las uses varias veces. Utiliza MAYÚSCULAS_CON_GUIONES_BAJOS para nombrarlas.
Note
Una excepción a esto son los literales utilizados en pantallas (screens). Si una pantalla no se llama con nopredict, utiliza literales cuando puedas, ya que Ren'Py optimiza las pantallas con literales.
Por favor, haz que sean descriptivas. No es necesario que sea al estilo de Java, solo lo suficiente para que sea relativamente fácil descifrar qué es. El uso de abreviaturas o siglas está bien. Utiliza lowercase_underscores para nombrarlas.
Por favor, escribe comentarios. Aunque Python es legible por sí mismo, conocer la razón de alto nivel por la que estamos haciendo algo o los efectos de alto nivel de hacerlo es de gran ayuda. 📝
Nuevamente, no se impone estrictamente, pero mantenlas razonables. Lo recomendable es limitarse a 80 columnas, pero hasta 120 está bien.
Warning
La excepción es el código de Ren'Py. El código de Ren'Py no siempre se puede dividir en varias líneas.
Cualquier recurso que utilices debe estar en la carpeta mod_assets/. Si tienes una gran cantidad de recursos, agrúpalos en una subcarpeta. 🖼️
Si puedes hacerlo sin usar un paquete externo, hazlo sin el paquete externo. Las excepciones deben discutirse con el equipo de desarrollo oficial.
Warning
Si la biblioteca que deseas agregar pesa más de un megabyte, es casi seguro que no será permitida.