You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardexpand all lines: DEVELOPER_GUIDE.md
+12-12
Original file line number
Diff line number
Diff line change
@@ -351,9 +351,9 @@ through the same build issue.
351
351
352
352
### Class and package names
353
353
354
-
Class names should use `CamelCase`.
354
+
Class names should use `CamelCase`.
355
355
356
-
Try to put new classes into existing packages if package name abstracts the purpose of the class.
356
+
Try to put new classes into existing packages if package name abstracts the purpose of the class.
357
357
358
358
Example of good class file name and package utilization:
359
359
@@ -371,7 +371,7 @@ methods rather than a long single one and does everything.
371
371
### Documentation
372
372
373
373
Document you code. That includes purpose of new classes, every public method and code sections that have critical or non-trivial
374
-
logic (check this example https://github.com/opensearch-project/neural-search/blob/main/src/main/java/org/opensearch/neuralsearch/query/NeuralQueryBuilder.java#L238).
374
+
logic (check this example https://github.com/opensearch-project/neural-search/blob/main/src/main/java/org/opensearch/neuralsearch/query/NeuralQueryBuilder.java#L238).
375
375
376
376
When you submit a feature PR, please submit a new
377
377
[documentation issue](https://github.com/opensearch-project/documentation-website/issues/new/choose). This is a path for the documentation to be published as part of https://opensearch.org/docs/latest/ documentation site.
@@ -384,17 +384,17 @@ For the most part, we're using common conventions for Java projects. Here are a
384
384
385
385
1. Use descriptive names for classes, methods, fields, and variables.
386
386
2. Avoid abbreviations unless they are widely accepted
387
-
3. Use `final` on all method arguments unless it's absolutely necessary
387
+
3. Use `final` on all method arguments unless it's absolutely necessary
388
388
4. Wildcard imports are not allowed.
389
389
5. Static imports are preferred over qualified imports when using static methods
390
390
6. Prefer creating non-static public methods whenever possible. Avoid static methods in general, as they can often serve as shortcuts.
391
391
Static methods are acceptable if they are private and do not access class state.
392
-
7. Use functional programming style inside methods unless it's a performance critical section.
392
+
7. Use functional programming style inside methods unless it's a performance critical section.
393
393
8. For parameters of lambda expression please use meaningful names instead of shorten cryptic ones.
394
394
9. Use Optional for return values if the value may not be present. This should be preferred to returning null.
395
395
10. Do not create checked exceptions, and do not throw checked exceptions from public methods whenever possible. In general, if you call a method with a checked exception, you should wrap that exception into an unchecked exception.
396
396
11. Throwing checked exceptions from private methods is acceptable.
397
-
12. Use String.format when a string includes parameters, and prefer this over direct string concatenation. Always specify a Locale with String.format;
397
+
12. Use String.format when a string includes parameters, and prefer this over direct string concatenation. Always specify a Locale with String.format;
398
398
as a rule of thumb, use Locale.ROOT.
399
399
13. Prefer Lombok annotations to the manually written boilerplate code
400
400
14. When throwing an exception, avoid including user-provided content in the exception message. For secure coding practices,
@@ -440,17 +440,17 @@ Fix any new warnings before submitting your PR to ensure proper code documentati
440
440
441
441
### Tests
442
442
443
-
Write unit and integration tests for your new functionality.
443
+
Write unit and integration tests for your new functionality.
444
444
445
445
Unit tests are preferred as they are cheap and fast, try to use them to cover all possible
446
-
combinations of parameters. Utilize mocks to mimic dependencies.
446
+
combinations of parameters. Utilize mocks to mimic dependencies.
447
447
448
-
Integration tests should be used sparingly, focusing primarily on the main (happy path) scenario or cases where extensive
449
-
mocking is impractical. Include one or two unhappy paths to confirm that correct response codes are returned to the user.
450
-
Whenever possible, favor scenarios that do not require model deployment. If model deployment is necessary, use an existing
448
+
Integration tests should be used sparingly, focusing primarily on the main (happy path) scenario or cases where extensive
449
+
mocking is impractical. Include one or two unhappy paths to confirm that correct response codes are returned to the user.
450
+
Whenever possible, favor scenarios that do not require model deployment. If model deployment is necessary, use an existing
451
451
model, as tests involving new model deployments are the most resource-intensive.
452
452
453
-
If your changes could affect backward compatibility, please include relevant backward compatibility tests along with your
453
+
If your changes could affect backward compatibility, please include relevant backward compatibility tests along with your
454
454
PR. For guidance on adding these tests, refer to the [Backwards Compatibility Testing](#backwards-compatibility-testing) section in this guide.
0 commit comments