153 lines
5.1 KiB
Markdown
153 lines
5.1 KiB
Markdown
|
|
|
|
# Bug reports
|
|
> Reproducible bugs are fixable bugs.
|
|
|
|
- Describe the issue in as much detail as possible.
|
|
- Give proper steps which can be used to reproduce the bug.
|
|
- Everest comes with a CLI BugReporter. Use it to generate a report which includes the log files, system details (JVM vendor, version, OS) along with your
|
|
experience. Upload the generated zip file while opening an issue. The BugReporter can be found in the `Everest/` directory within the
|
|
installation directory. Run it using `java -jar BugReporter.jar`.
|
|
- Screenshots, animated GIFs or videos illustrating the bug would be very helpful.
|
|
|
|
# Pull Requests
|
|
- Make sure your code adheres to the style guides that follow.
|
|
- Describe your changes in as much detail as possible.
|
|
- If your PR is a bug fix, first open an issue pertaining to the issue and then work on the PR.
|
|
- If your PR is a feature addition, discuss it with me before, especially so if it is UI/UX related. You can open an issue or email me at rohitawate121@gmail.com.
|
|
- Avoid platform-dependent code. Everest should at least work on Windows, Mac and the common Linux distributions like Ubuntu, Fedora, etc.
|
|
- Screenshots, animated GIFs or videos showing Everest before and after the PR will be appreciated.
|
|
- Please do not feel bad if I ask for some changes to the PR or make some myself or if I have to decline it. I tend to nitpick a
|
|
lot when it comes to code but that is only to make sure that the code driving the end product is as beautiful and consistent as
|
|
the product itself.
|
|
|
|
# Java Styleguide
|
|
- Use a tab width of **4** for indentation. **(no spaces)**
|
|
- Class names must be `UpperCamelCase`.
|
|
- Methods and other class members must be `lowerCamelCase`.
|
|
- Variable names such as `num0` or `num1` are strictly prohibited.
|
|
- JavaFX controllers must have the word 'Controller' at the end.
|
|
For example, for the 'Dashboard.fxml' file, the controller class should be DashboardController.
|
|
- FXML-annotated variables must be grouped together just after the controller class begins.
|
|
Leave no blank lines between these. Group variables of the same type together. (Similar to how the StackPanes and VBoxes are grouped in the example)
|
|
```java
|
|
public class HomeWindowController implements Initializable {
|
|
@FXML
|
|
private StackPane homeWindowSP;
|
|
@FXML
|
|
private SplitPane splitPane;
|
|
@FXML
|
|
private TabPane tabPane;
|
|
@FXML
|
|
private TextField historyTextField;
|
|
@FXML
|
|
private VBox historyTab, searchBox, historyPane;
|
|
@FXML
|
|
private StackPane historyPromptLayer, searchLayer, searchFailedLayer;
|
|
@FXML
|
|
private JFXButton clearSearchFieldButton;
|
|
|
|
private HashMap<Tab, DashboardController> tabControllerMap;
|
|
private List<HistoryItemController> historyItemControllers;
|
|
```
|
|
- Non-FXML-annotated class members should be grouped together as shown above. Leave a blank line after the FXML-annotated members and begin.
|
|
- For `if`, `switch`, `catch` statements and all the loops, add a single space before and after the opening and closing parenthesis:
|
|
```java
|
|
if (condition) {
|
|
|
|
}
|
|
|
|
switch (name) {
|
|
|
|
}
|
|
|
|
try {
|
|
|
|
} catch (SQLException e) {
|
|
|
|
}
|
|
|
|
for (int i = 0; i < 15; i++) {
|
|
|
|
}
|
|
|
|
while (condition) {
|
|
|
|
}
|
|
|
|
do {
|
|
|
|
} while (condition);
|
|
```
|
|
- For methods, only add a single space after the closing parenthesis but not the opening one:
|
|
```java
|
|
String getAddress() {
|
|
|
|
}
|
|
```
|
|
|
|
### Conditionals
|
|
- For if-else statements with **bodies longer than one line**:
|
|
```java
|
|
if (condition) {
|
|
|
|
} else {
|
|
|
|
}
|
|
```
|
|
- `switch` cases should be indented with 4 tabs as so:
|
|
```java
|
|
switch (bodyTabController.rawInputTypeBox.getValue()) {
|
|
case "PLAIN TEXT":
|
|
contentType = MediaType.TEXT_PLAIN;
|
|
break;
|
|
case "JSON":
|
|
contentType = MediaType.APPLICATION_JSON;
|
|
break;
|
|
case "XML":
|
|
contentType = MediaType.APPLICATION_XML;
|
|
break;
|
|
case "HTML":
|
|
contentType = MediaType.TEXT_HTML;
|
|
break;
|
|
default:
|
|
contentType = MediaType.TEXT_PLAIN;
|
|
}
|
|
```
|
|
|
|
# CSS Styleguide
|
|
- Use a tab width of **4** for indentation. **(no spaces)**
|
|
- Separate styles with one blank line. (as shown in the second example)
|
|
- If applying the same style to a bunch of selectors, separate them using lines:
|
|
```css
|
|
#historyScrollPane,
|
|
#historyScrollPane .viewport,
|
|
#historyScrollPane .scroll-bar:vertical,
|
|
#historyScrollPane .scroll-bar:horizontal {
|
|
-fx-background-color: #404040;
|
|
}
|
|
```
|
|
|
|
- Group styles for the same UI element together and add a comment with the element's name before the styles.
|
|
```css
|
|
/* History item */
|
|
#historyItemBox {
|
|
-fx-background-color: #353535;
|
|
}
|
|
|
|
#historyItemBox:hover {
|
|
-fx-background-color: #282828;
|
|
}
|
|
|
|
#rawInputArea {
|
|
-fx-font-size: 15px;
|
|
}
|
|
```
|
|
|
|
# Git commit messages
|
|
- As of writing this guide (June 26, 2018), I've been doing "Added feature" instead of "Add feature" ie. not being imperative with my commit messages.
|
|
This is considered bad practice so all commit messages will be imperative now onwards. Please follow the same practice.
|
|
- Start with a capital letter. ("Add feature", not "add feature")
|
|
- Do not end with a period.
|
|
- Keep the commit history clean. Avoid "Fix blah blah" followed by "Fix blah blah #2" or "Fix blah blah #3".
|
|
- Reference issues with '#' for fixes. (Fix #15)
|