[GitHub] [solr] dsmiley commented on a diff in pull request #1038: document the various code quality tools in our Developer FAQ

[GitBox <gi...@apache.org>]

dsmiley commented on code in PR #1038:
URL: https://github.com/apache/solr/pull/1038#discussion_r979062578


##########
dev-docs/FAQ.adoc:
##########
@@ -51,3 +51,37 @@ Run `gradle dev`, and then `cd ./packaging/build/dev/`.  Fire up your cluster
 via `bin/solr start -e cloud -noprompt` and then as you make changes to assets in `/solr/webapp/web`,
 run `gradle dev` to redeploy the web assets. Do a  hard refresh in your browser
 to pick up your changes.
+
+=== How do we ensure coding standards and quality?
+
+We use a number of tools for ensuring that Solr's codebase follows our community standards.  The most

Review Comment:
   nit:  when writing adoc files, consider one sentence per line.  It helps with diffs.



##########
dev-docs/FAQ.adoc:
##########
@@ -51,3 +51,37 @@ Run `gradle dev`, and then `cd ./packaging/build/dev/`.  Fire up your cluster
 via `bin/solr start -e cloud -noprompt` and then as you make changes to assets in `/solr/webapp/web`,
 run `gradle dev` to redeploy the web assets. Do a  hard refresh in your browser
 to pick up your changes.
+
+=== How do we ensure coding standards and quality?
+
+We use a number of tools for ensuring that Solr's codebase follows our community standards.  The most
+important tool is the very rich testing infrastructure that Solr enjoys.  We strive for testing
+of every aspect of Solr.   If you find a bug, write a test demonstrating it, so we can ensure that once
+the bug is squashed, it stays squashed.
+
+Beyond testing, we also have some tools for ensuring coding standards are followed.
+[Spotless](https://github.com/diffplug/spotless) is used to format the Java source code
+so that everyone uses the same formatting patterns.  Run Spotless via:
+
+`./gradlew tidy`
+
+Learn more via `./gradlew :helpFormatting`
+
+The Eclipse IDE's linting tool ECJ is applied as part of the `check` task.
+
+[Error Prone](https://errorprone.info/) goes beyond static type checking and recommends fixes
+for common bug patterns.  Error Prone is normally run during a CI build, to run it locally via:
+
+`./gradlew check -Pvalidation.errorprone=true`

Review Comment:
   that will also run tests; right?  instead run the specific task if that's what we're trying to show someone.



-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For additional commands, e-mail: issues-help@solr.apache.org