Adding code guidelines

DEVELOPER_GUIDE.md

@@ -17,6 +17,7 @@
   - [Supported configurations](#supported-configurations)
   - [Submitting Changes](#submitting-changes)
   - [Building On Lucene Version Updates](#building-on-lucene-version-updates)
+  - [Code Guidelines](#code-guidelines)
 
 # Developer Guide
 
@@ -338,3 +339,80 @@ 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.
+
+
+
+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.
+
+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.