|
| 1 | +# Contributing to This Project |
| 2 | + |
| 3 | +First off — thanks for checking out this project. |
| 4 | + |
| 5 | +While this is a small and focused library, and I'm not actively contributing, you're still welcome to open issues, suggest improvements, or fork it for your own use. |
| 6 | + |
| 7 | +## Guidelines |
| 8 | + |
| 9 | +If you do want to contribute, here are a few quick guidelines to follow to keep things clean and consistent: |
| 10 | + |
| 11 | +### 1. Keep It Aligned with the Project Scope |
| 12 | + |
| 13 | +This library is meant to stay minimal, maintainable, and aligned with its current goals. If you're adding something, ask: |
| 14 | +- Does this keep the project simple? |
| 15 | +- Does it make it easier to integrate JL Map - Java Leaflet into existing projects? |
| 16 | +- Is it a core use case? |
| 17 | + |
| 18 | +If you're not sure, open an issue first before writing code — happy to talk about it. |
| 19 | + |
| 20 | +### 2. Code Style |
| 21 | + |
| 22 | +Stick to standard Java conventions. If you're using an IDE like IntelliJ, the default formatter should be fine. We also added spotless since v2.2.1. Some specific preferences: |
| 23 | + |
| 24 | +- Keep every block of the code as small as possible, break it down if possible |
| 25 | +- Avoid unnecessary abstractions. |
| 26 | +- Avoid unnecessary documentation. |
| 27 | +- Keep the code, variable/class/method/etc naming self explanatory |
| 28 | +- Don’t go overboard creating tons of classes and interfaces just to perfectly follow a specific design or pattern—they're guidelines, not laws of nature. |
| 29 | +- Prefer immutability where possible. |
| 30 | +- Javadoc ,at least, public APIs. |
| 31 | + |
| 32 | +### 3. Commit Messages |
| 33 | + |
| 34 | +- Keep commit messages short and meaningful. |
| 35 | +- Avoid using any special characters. |
| 36 | +- Focus on delivering enough context than being grammatically correct. |
| 37 | + |
| 38 | +Thank you. |
0 commit comments