Add links to code style guide

Author: Kate Osborn

CONTRIBUTING.md

@@ -14,11 +14,6 @@ considering contributing!
 * [Issues and Discussions](#issues-and-discussions)
 * [Development Guide](#development-guide)
 
-[Style Guides](#style-guides)
-
-* [Git Style Guide](#git-style-guide)
-* [Go Style Guide](#go-style-guide)
-
 [Code of Conduct](CODE_OF_CONDUCT.md)
 
 [Contributor License Agreement](#contributor-license-agreement)
@@ -74,8 +69,8 @@ template.
 #### Issue lifecycle
 
 When an issue or PR is created, it will be triaged by the maintainers and assigned a label to indicate the type of issue
-it is (bug, feature request, etc) and to determine the milestone. See the [Issue Lifecycle](/ISSUE_LIFECYCLE.md) document
-for more information.
+it is (bug, feature request, etc) and to determine the milestone. See the [Issue Lifecycle](/ISSUE_LIFECYCLE.md)
+document for more information.
 
 ### Development Guide
 
@@ -85,36 +80,14 @@ Before beginning development, familiarize yourself with the following documents:
   your development environment and executing tasks required when submitting a pull request.
 - [Branching and Workflow](/docs/developer/branching-and-workflow.md): This document outlines the project's specific
   branching and workflow practices, including instructions on how to name a branch.
-- [Implement a Feature](/docs/developer/implementing-a-feature.md): A step-by-step guide on how to implement a feature or
-  bug.
+- [Implement a Feature](/docs/developer/implementing-a-feature.md): A step-by-step guide on how to implement a feature
+  or bug.
 - [Testing](/docs/developer/testing.md): The project's testing guidelines, includes both unit testing and manual testing
   procedures. This document explains how to write and run unit tests, and how to manually verify changes.
 - [Pull Request Guidelines](/docs/developer/pull-request.md): A guide for both pull request submitters and reviewers,
   outlining guidelines and best practices to ensure smooth and efficient pull request processes.
-
-## Style Guides
-
-### Git Style Guide
-
-* Keep a clean, concise and meaningful git commit history on your branch, rebasing locally and squashing before
-  submitting a PR
-* Follow the guidelines of writing a good commit message as described [here](https://chris.beams.io/posts/git-commit/)
-  and summarized in the next few points
-    * In the subject line, use the present tense ("Add feature" not "Added feature")
-    * In the subject line, use the imperative mood ("Move cursor to..." not "Moves cursor to...")
-    * Limit the subject line to 72 characters or less
-    * Reference issues and pull requests liberally after the subject line
-    * Add more detailed description in the body of the git message (`git commit -a` to give you more space and time in
-      your text editor to write a good message instead of `git commit -am`)
-
-### Go Style Guide
-
-* Run `gofmt` over your code to automatically resolve a lot of style issues. Most editors support this running
-  automatically when saving a code file.
-* Run `go lint` and `go vet` on your code too to catch any other issues.
-* Follow this guide on some good practice and idioms for Go -  https://github.com/golang/go/wiki/CodeReviewComments
-* To check for extra issues, install [golangci-lint](https://github.com/golangci/golangci-lint) and run `make lint`
-  or `golangci-lint run`
+- [Go Style Guide](/docs/developer/go-style-guide.md) A coding style guide for Go. Contains best practices and
+  conventions to follow when writing Go code for the project. 
 
 ## Contributor License Agreement
 

docs/developer/implementing-a-feature.md

@@ -17,19 +17,21 @@ practices to ensure a successful feature development process.
    the [branching and workflow](/docs/developer/branching-and-workflow.md) documentation.
 4. **Branch**: Create a branch following
    the [naming conventions](/docs/developer/branching-and-workflow.md#branch-naming-conventions).
-5. **Make changes**: Make the necessary changes for the feature.
-6. **Consider opening a draft PR**: If your feature involves substantial architecture changes, or you would like to
+5. **Review style guide** Review the [Go style guide](/docs/developer/go-style-guide.md) to familiarize yourself with
+   the project's coding practices.
+6. **Make changes**: Make the necessary changes for the feature.
+7. **Consider opening a draft PR**: If your feature involves substantial architecture changes, or you would like to
    receive early feedback, consider opening a draft PR and requesting reviews from the maintainers. Draft PRs are an
    effective means to solicit feedback and ensure that major architectural changes align with the project's goals and
    standards.
-7. **Add or update unit tests** All features **must** be accompanied by unit tests that verify the functionality. Make
+8. **Add or update unit tests** All features **must** be accompanied by unit tests that verify the functionality. Make
    sure to thoroughly test the different scenarios and edge cases related to the feature to ensure robustness and
    reliability. Additionally, open the code coverage report to ensure that the code you added has sufficient test
    coverage. For instructions on writing and running unit tests, refer to
    the [testing](/docs/developer/testing.md#unit-test-guidelines) documentation.
-8. **Manually verify your changes**: Refer to the [manual testing](/docs/developer/testing.md#manual-testing) section of
+9. **Manually verify your changes**: Refer to the [manual testing](/docs/developer/testing.md#manual-testing) section of
    the testing documentation for instructions on how to manually test your changes.
-9. **Update any relevant documentation**: Here are some guidelines for updating documentation:
+10. **Update any relevant documentation**: Here are some guidelines for updating documentation:
     - **Gateway API Feature**: If you are implementing a Gateway API feature, make sure to update
       the [Gateway API Compatibility](/docs/gateway-api-compatibility.md) documentation.
     - **New Use Case:** If your feature introduces a new use case, add an example of how to use it in
@@ -41,22 +43,20 @@ practices to ensure a successful feature development process.
     - **Other Documentation Updates**: For any other changes that affect the behavior, usage, or configuration of NKG,
       review the existing documentation and update it as necessary. Ensure that the documentation remains accurate and
       up to date with the latest changes.
-10. **Lint code**: See the [run the linter](/docs/developer/quickstart.md#run-the-linter) section of the quickstart
+11. **Lint code**: See the [run the linter](/docs/developer/quickstart.md#run-the-linter) section of the quickstart
     guide for instructions.
-11. **Open pull request**: Open a pull request targeting the `main` branch of
+12. **Open pull request**: Open a pull request targeting the `main` branch of
     the [nginx-kubernetes-gateway](https://github.com/nginxinc/nginx-kubernetes-gateway/tree/main) repository. The
     entire `nginx-kubernetes-gateway` group will be automatically requested for review. If you have a specific or
     different reviewer in mind, you can request them as well. Refer to
     the [pull request](/docs/developer/pull-request.md) documentation for expectations and guidelines.
-12. **Obtain the necessary approvals**: Work with code reviewers to maintain the required number of approvals.
-13. **Squash and merge**: Squash your commits locally, or use the GitHub UI to squash and merge. Only one commit per
+13. **Obtain the necessary approvals**: Work with code reviewers to maintain the required number of approvals.
+14. **Squash and merge**: Squash your commits locally, or use the GitHub UI to squash and merge. Only one commit per
     pull request should be merged. Make sure the first line of the final commit message includes the pull request
     number. For example, Fix supported gateway conditions in compatibility doc (#674).
     > **Note**:
     When you squash commits, make sure to not include any commit messages related to the code review
     (for example, Fixed a typo). If you changed the code as a result of the code review in way that the original commit message no longer describes it well, make sure to update the message.
-     
-
 
 ## Fixing a Bug