This is an automated email from the ASF dual-hosted git repository. spmallette pushed a commit to branch 3.5-dev-rebuild in repository https://gitbox.apache.org/repos/asf/tinkerpop.git
commit 3eb394536cbb77dea66147d530d11b390a0598cc Author: Stephen Mallette <[email protected]> AuthorDate: Mon Jul 26 15:03:36 2021 -0400 TINKERPOP-2592 Pointed recipes style guide at gremlint style guide CTR --- docs/src/recipes/style-guide.asciidoc | 62 ++--------------------------------- 1 file changed, 2 insertions(+), 60 deletions(-) diff --git a/docs/src/recipes/style-guide.asciidoc b/docs/src/recipes/style-guide.asciidoc index de2aa08..9a78c61 100644 --- a/docs/src/recipes/style-guide.asciidoc +++ b/docs/src/recipes/style-guide.asciidoc @@ -17,63 +17,5 @@ limitations under the License. [[style-guide]] == Style Guide -Gremlin is a data flow language where each new step concatenation alters the stream accordingly. This aspect of the -language allows users to easily "build-up" a traversal (literally) step-by-step until the expected results are -returned. For instance: - -[gremlin-groovy,modern] ----- -g.V(1) -g.V(1).out('knows') -g.V(1).out('knows').out('created') -g.V(1).out('knows').out('created').groupCount() -g.V(1).out('knows').out('created').groupCount().by('name') ----- - -A drawback of building up a traversal is that users tend to create long, single line traversal that are hard to read. -For simple traversals, a single line is fine. For complex traversals, there are few formatting patterns that should be followed -which will yield cleaner, easier to understand traversals. For instance, the last traversal above would be written: - -[gremlin-groovy,modern] ----- -g.V(1).out('knows').out('created'). - groupCount().by('name') ----- - -Lets look at a complex traversal and analyze each line according to the recommended formatting rule is subscribes to. - -[gremlin-groovy,modern] ----- -g.V().out('knows').out('created'). <1> - group().by('lang').by(). <2> - select('java').unfold(). <3> - in('created').hasLabel('person'). <4> - order(). <5> - by(inE().count(),desc). <6> - by('age',asc). - dedup().limit(10).values('name') <7> ----- - - -<1> A sequence of `ins().outs().filters().etc()` on a single line until it gets too long. -<2> When a barrier (reducer, aggregator, etc.) is used, put it on a new line. -<3> When a next line component is an "add on" to the previous line component, 2 space indent. -The `select()`-step in this context is "almost like" a `by()`-modulator as its projecting data out of the `group()`. -The `unfold()`-step is a data formatting necessity that should not be made too prominent. -<4> Back to a series of `ins().outs().filters().etc()` on a single line. -<5> `order()` is a barrier step and thus, should be on a new line. -<6> If there is only one `by()`-modulator (or a series of short ones), keep it on one line, else each `by()` is a new line. -<7> Back to a series `ins().outs().filters().etc()`. - -=== Style Guide Rules - -A generalization of the specifics above are presented below. - -* Always use 2 space indent. -* No newline should ever have the same indent as the line starting with the traversal source `g`. -* Barrier steps should form line breaks unless they are simple (e.g. `sum()`). -* Complex `by()`-modulators form indented "paragraphs." -* Standard filters, maps, flatMaps remain on the same line until they get too long. - -Given the diversity of traversals and the complexities introduced by lambdas (for example), these rules will not always -lead to optimal representations. However, by in large, the style rules above will help make 90% of traversals look great. +The Gremlin Style Guide has been moved and expanded as part of link:https://gremlint.com[Gremlint]. Please find that +style guide link:https://tinkerpop.apache.org/gremlint/#/style-guide[here]. \ No newline at end of file
