Adding code guidelines (#502)

* Adding code guidelines to DEVELOPER_GUIDE md

Signed-off-by: Martin Gaievski <[email protected]>

* Adding guidelines to the table of content

Signed-off-by: Martin Gaievski <[email protected]>

* Added section with spotlessApply and javadoc commands

Signed-off-by: Martin Gaievski <[email protected]>

---------

Signed-off-by: Martin Gaievski <[email protected]>

Author: martin-gaievski

DEVELOPER_GUIDE.md

@@ -17,6 +17,14 @@
   - [Supported configurations](#supported-configurations)
   - [Submitting Changes](#submitting-changes)
   - [Building On Lucene Version Updates](#building-on-lucene-version-updates)
+  - [Code Guidelines](#code-guidelines)
+    - [Class and package names](#class-and-package-names)
+    - [Modular code](#modular-code)
+    - [Documentation](#documentation)
+    - [Code style](#code-style)
+    - [Style and Formatting Check](#style-and-formatting-check)
+    - [Tests](#tests)
+    - [Outdated or irrelevant code](#outdated-or-irrelevant-code)
 
 # Developer Guide
 
@@ -338,3 +346,114 @@ through the same build issue.
 3. Head over to your OpenSearch cloned repo root directory
    1. `./gradlew publisToMavenLocal`
 4. Finally run `./gradlew build` from the neural search repo
+
+## Code Guidelines
+
+### Class and package names
+
+Class names should use `CamelCase`. 
+
+Try to put new classes into existing packages if package name abstracts the purpose of the class. 
+
+Example of good class file name and package utilization:
+
+`src/main/java/org/opensearch/neuralsearch/processor/factory/RerankProcessorFactory.java`
+
+following naming needs improvement, it creates unnecessary package and uses underscores case for file name
+
+`src/main/java/org/opensearch/neuralsearch/rerank_factory/rerank_processor_factory.java`
+
+### Modular code
+
+Try to organize code into small classes and methods with a single concise purpose. It's preferable to have multiple small
+methods rather than a long single one and does everything.
+
+### Documentation
+
+Document you code. That includes purpose of new classes, every public method and code sections that have critical or non-trivial
+logic (check this example https://github.com/opensearch-project/neural-search/blob/main/src/main/java/org/opensearch/neuralsearch/query/NeuralQueryBuilder.java#L238). 
+
+When you submit a feature PR, please submit a new
+[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.
+
+Please be prepared to provide any additional guidance (like example of query request/response, details of API parameters etc.) for the team doing the documentation.
+
+### Code style
+
+For the most part, we're using common conventions for Java projects. Here are a few things to keep in mind.
+
+1. Use descriptive names for classes, methods, fields, and variables.
+2. Avoid abbreviations unless they are widely accepted
+3. Use `final` on all method arguments unless it's absolutely necessary 
+4. Wildcard imports are not allowed.
+5. Static imports are preferred over qualified imports when using static methods
+6. Prefer creating non-static public methods whenever possible. Avoid static methods in general, as they can often serve as shortcuts.
+Static methods are acceptable if they are private and do not access class state.
+7. Use functional programming style inside methods unless it's a performance critical section. 
+8. For parameters of lambda expression please use meaningful names instead of shorten cryptic ones.
+9. Use Optional for return values if the value may not be present. This should be preferred to returning null.
+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.
+11. Throwing checked exceptions from private methods is acceptable.
+12. Use String.format when a string includes parameters, and prefer this over direct string concatenation. Always specify a Locale with String.format; 
+as a rule of thumb, use Locale.ROOT.
+13. Prefer Lombok annotations to the manually written boilerplate code
+14. When throwing an exception, avoid including user-provided content in the exception message. For secure coding practices,
+limit exception messages to the bare minimum and log additional details to the application logs, as user input could be maliciously crafted.
+
+Please check [Java Language Formatting Guidelines](##Java Language Formatting Guidelines) section for more details.
+
+### Style and Formatting Check
+As part of our continuous integration (CI) pipeline, we check code formatting and style. Failed checks may block your PR from being merged. To avoid this, run the following command locally before submitting your PR:
+
+```bash
+./gradlew spotlessApply
+```
+
+To verify that all required public Java documentation is present, run:
+
+```bash
+./gradlew javadoc
+```
+
+This command will identify missing or incomplete documentation. Common warnings include:
+
+- missing documentation for public methods
+- missing parameter descriptions
+- missing documentation for public fields
+
+Example warning:
+
+```
+/neural-search/build/generated/sources/delombok/java/main/org/opensearch/neuralsearch/processor/combination/ArithmeticMeanScoreCombinationTechnique.java:18: warning: no comment
+public static final String TECHNIQUE_NAME = "arithmetic_mean";
+```
+Documentation requirements:
+
+- all public methods must have descriptions that explain:
+    - main responsibility of the method
+    - any side effects (like mutating input objects)
+    - any exceptional conditions or error cases
+- all parameters in public methods must have descriptions
+- public fields should be documented with their purpose and usage
+
+Fix any new warnings before submitting your PR to ensure proper code documentation.
+
+### Tests
+
+Write unit and integration tests for your new functionality. 
+
+Unit tests are preferred as they are cheap and fast, try to use them to cover all possible
+combinations of parameters. Utilize mocks to mimic dependencies. 
+
+Integration tests should be used sparingly, focusing primarily on the main (happy path) scenario or cases where extensive 
+mocking is impractical. Include one or two unhappy paths to confirm that correct response codes are returned to the user. 
+Whenever possible, favor scenarios that do not require model deployment. If model deployment is necessary, use an existing 
+model, as tests involving new model deployments are the most resource-intensive.
+
+If your changes could affect backward compatibility, please include relevant backward compatibility tests along with your 
+PR. For guidance on adding these tests, refer to the [Backwards Compatibility Testing](#backwards-compatibility-testing) section in this guide.
+
+### Outdated or irrelevant code
+
+Do not submit code that is not used or needed, even if it's commented. We rely on github as version control system, code
+can be restored if needed.