Adding code guidelines to DEVELOPER_GUIDE md

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

DEVELOPER_GUIDE.md

@@ -311,6 +311,7 @@ run successfully on the PR. For example, if a PR on main needs to be backported
 `backport 2.x` to the PR and make sure the backport workflow runs on the PR along with other checks. Once this PR is
 merged to main, the workflow will create a backport PR to the `2.x` branch.
 
+
 ## Building On Lucene Version Updates
 There may be a Lucene version update that can affect your workflow causing errors like
 `java.lang.NoClassDefFoundError: org/apache/lucene/codecs/lucene99/Lucene99Codec` or
@@ -338,3 +339,71 @@ 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 methods whenever possible. Static methods should generally be avoided as they are often used as a shortcut.
+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 style in case your string is using parameters, prefer that to direct string concatenation
+13. Prefer Lombok annotations to the manually written boilerplate code
+
+Some of mentioned styles are enforced by the `spotless` Gradle plugin, please check [Java Language Formatting Guidelines](##Java Language Formatting Guidelines) section for more details.
+
+### 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.
+
+### 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.