You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tinkerpop.apache.org by Marko Rodriguez <ok...@gmail.com> on 2016/03/04 15:39:07 UTC
[DISCUSS] Proper indentation of Gremlin traversals.
Hello,
I'm futzing with our docs and noticed that the authors have different indentation styles for multi-line Gremlin traversals.
I think we should converge on a similar style? ………
And guess what, I think my style is the best.
g.V().out("knows").out("attended"). // <1>
group().by("state").by() // <2>
select("Vermont").unfold() // <3>
in("attended").has("gpa") // <4>
order() // <5>
by("age",decr). // <6>
by("gpa",incr).
limit(10).values("name") // <7>
Key features:
1. A bunch of in().outs().filters().etc. on a single line until it gets too long.
2. If you bust a barrier (reducer, aggregator, etc.), new line.
3. When a next line component is an "add on" to the previous line component, 2 space indent.
- that select() is "almost like" a by().
- unfold() is a dirty sucky you just tack on the end and don't make it too prominent as its just data formatting.
4. Back to a series of in().outs().etc., new line.
5. Another barrier -- new line.
6. If there is only one by()-modulator (or a series of short ones), keep it on one line. If its complex, each by() is a line.
7. Back to a series outs().filters().maps().etc.
In summary,
1. 2 space indent.
2. Nothing is on equal spacing with "g."
3. Barriers form line breaks.
4. by()-modulators form indented "paragraphs."
5. Standard filters.maps.flatmaps are single line until it gets unwieldy.
Thoughts?,
Marko.
http://markorodriguez.com
Re: [TinkerPop] [DISCUSS] Proper indentation of Gremlin traversals.
Posted by Marko Rodriguez <ok...@gmail.com>.
Hi,
> I would think a section on style would be useful though ultimately we all tend to have our own ideas on what looks good. I guess you would look to add this to the reference docs?
Yes. I was looking a provider's docs the other day and it was "one-liner" central. I recommended they break up their traversals to make them "prettier" and then pointed them to THIS EMAIL! :) … Be good to have it in the reference docs and point them there. I will add a section to the tp31/ branch and up merge.
Marko.
>
> On Thu, Apr 14, 2016 at 6:06 PM, Marko Rodriguez <ok...@gmail.com> wrote:
> Hi,
>
> What do YOU people think about putting this in the docs? That is, a multi-line style guide.
>
> Marko.
>
> http://markorodriguez.com
>
> On Mar 4, 2016, at 7:39 AM, Marko Rodriguez <ok...@gmail.com> wrote:
>
>> Hello,
>>
>> I'm futzing with our docs and noticed that the authors have different indentation styles for multi-line Gremlin traversals.
>>
>> I think we should converge on a similar style? ………
>>
>> And guess what, I think my style is the best.
>>
>> g.V().out("knows").out("attended"). // <1>
>> group().by("state").by() // <2>
>> select("Vermont").unfold() // <3>
>> in("attended").has("gpa") // <4>
>> order() // <5>
>> by("age",decr). // <6>
>> by("gpa",incr).
>> limit(10).values("name") // <7>
>>
>> Key features:
>>
>> 1. A bunch of in().outs().filters().etc. on a single line until it gets too long.
>> 2. If you bust a barrier (reducer, aggregator, etc.), new line.
>> 3. When a next line component is an "add on" to the previous line component, 2 space indent.
>> - that select() is "almost like" a by().
>> - unfold() is a dirty sucky you just tack on the end and don't make it too prominent as its just data formatting.
>> 4. Back to a series of in().outs().etc., new line.
>> 5. Another barrier -- new line.
>> 6. If there is only one by()-modulator (or a series of short ones), keep it on one line. If its complex, each by() is a line.
>> 7. Back to a series outs().filters().maps().etc.
>>
>> In summary,
>>
>> 1. 2 space indent.
>> 2. Nothing is on equal spacing with "g."
>> 3. Barriers form line breaks.
>> 4. by()-modulators form indented "paragraphs."
>> 5. Standard filters.maps.flatmaps are single line until it gets unwieldy.
>>
>> Thoughts?,
>> Marko.
>>
>> http://markorodriguez.com
>>
>
>
> --
> You received this message because you are subscribed to the Google Groups "Gremlin-users" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to gremlin-users+unsubscribe@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/gremlin-users/C34EE833-2D5E-471A-890E-31327E7707D5%40gmail.com.
> For more options, visit https://groups.google.com/d/optout.
>
>
> --
> You received this message because you are subscribed to the Google Groups "Gremlin-users" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to gremlin-users+unsubscribe@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/gremlin-users/CAA-H43-gLSbzcFXqAA9meWjpjwdQ7GOCbHY2b5c%3DYFkCvkKYcw%40mail.gmail.com.
> For more options, visit https://groups.google.com/d/optout.
Re: [TinkerPop] Re: [DISCUSS] Proper indentation of Gremlin traversals.
Posted by Stephen Mallette <sp...@gmail.com>.
I would think a section on style would be useful though ultimately we all
tend to have our own ideas on what looks good. I guess you would look to
add this to the reference docs?
On Thu, Apr 14, 2016 at 6:06 PM, Marko Rodriguez <ok...@gmail.com>
wrote:
> Hi,
>
> What do YOU people think about putting this in the docs? That is, a
> multi-line style guide.
>
> Marko.
>
> http://markorodriguez.com
>
> On Mar 4, 2016, at 7:39 AM, Marko Rodriguez <ok...@gmail.com> wrote:
>
> Hello,
>
> I'm futzing with our docs and noticed that the authors have different
> indentation styles for multi-line Gremlin traversals.
>
> I think we should converge on a similar style? ………
>
> And guess what, I think my style is the best.
>
> g.V().out("knows").out("attended"). // <1>
> group().by("state").by() // <2>
> select("Vermont").unfold() // <3>
> in("attended").has("gpa") // <4>
> order() // <5>
> by("age",decr). // <6>
> by("gpa",incr).
> limit(10).values("name") // <7>
>
>
> Key features:
>
> 1. A bunch of in().outs().filters().etc. on a single line until it gets
> too long.
> 2. If you bust a barrier (reducer, aggregator, etc.), new line.
> 3. When a next line component is an "add on" to the previous line
> component, 2 space indent.
> - that select() is "almost like" a by().
> - unfold() is a dirty sucky you just tack on the end and don't make it too
> prominent as its just data formatting.
> 4. Back to a series of in().outs().etc., new line.
> 5. Another barrier -- new line.
> 6. If there is only one by()-modulator (or a series of short ones), keep
> it on one line. If its complex, each by() is a line.
> 7. Back to a series outs().filters().maps().etc.
>
> In summary,
>
> 1. 2 space indent.
> 2. Nothing is on equal spacing with "g."
> 3. Barriers form line breaks.
> 4. by()-modulators form indented "paragraphs."
> 5. Standard filters.maps.flatmaps are single line until it gets unwieldy.
>
> Thoughts?,
> Marko.
>
> http://markorodriguez.com
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Gremlin-users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to gremlin-users+unsubscribe@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/gremlin-users/C34EE833-2D5E-471A-890E-31327E7707D5%40gmail.com
> <https://groups.google.com/d/msgid/gremlin-users/C34EE833-2D5E-471A-890E-31327E7707D5%40gmail.com?utm_medium=email&utm_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>
Re: [DISCUSS] Proper indentation of Gremlin traversals.
Posted by Marko Rodriguez <ok...@gmail.com>.
Hi,
What do YOU people think about putting this in the docs? That is, a multi-line style guide.
Marko.
http://markorodriguez.com
On Mar 4, 2016, at 7:39 AM, Marko Rodriguez <ok...@gmail.com> wrote:
> Hello,
>
> I'm futzing with our docs and noticed that the authors have different indentation styles for multi-line Gremlin traversals.
>
> I think we should converge on a similar style? ………
>
> And guess what, I think my style is the best.
>
> g.V().out("knows").out("attended"). // <1>
> group().by("state").by() // <2>
> select("Vermont").unfold() // <3>
> in("attended").has("gpa") // <4>
> order() // <5>
> by("age",decr). // <6>
> by("gpa",incr).
> limit(10).values("name") // <7>
>
> Key features:
>
> 1. A bunch of in().outs().filters().etc. on a single line until it gets too long.
> 2. If you bust a barrier (reducer, aggregator, etc.), new line.
> 3. When a next line component is an "add on" to the previous line component, 2 space indent.
> - that select() is "almost like" a by().
> - unfold() is a dirty sucky you just tack on the end and don't make it too prominent as its just data formatting.
> 4. Back to a series of in().outs().etc., new line.
> 5. Another barrier -- new line.
> 6. If there is only one by()-modulator (or a series of short ones), keep it on one line. If its complex, each by() is a line.
> 7. Back to a series outs().filters().maps().etc.
>
> In summary,
>
> 1. 2 space indent.
> 2. Nothing is on equal spacing with "g."
> 3. Barriers form line breaks.
> 4. by()-modulators form indented "paragraphs."
> 5. Standard filters.maps.flatmaps are single line until it gets unwieldy.
>
> Thoughts?,
> Marko.
>
> http://markorodriguez.com
>
Re: [TinkerPop] [DISCUSS] Proper indentation of Gremlin traversals.
Posted by Daniel Kuppitz <me...@gremlin.guru>.
>
> 1. 2 space indent.
2. Nothing is on equal spacing with "g."
Cool. Although I prefer to start behind V() (at least 5 spaces in the
second line), UNLESS I have a mid-traversal V().
3. Barriers form line breaks.
Not cool. Long lines form line breaks. Sometimes I make it depend on the
steps I'm using, but the types of steps usually don't play a role.
4. by()-modulators form indented "paragraphs."
Nah, kinda don't like your style. I will show my variant at the end of that
message.
5. Standard filters.maps.flatmaps are single line until it gets unwieldy.
Again, the line length is all that really matters.
Here's my variant:
g.V().out("knows").out("attended").
group().by("state").by().
select("Vermont").unfold().
in("attended").has("gpa").
V().foo().bar().whatever().
order().by("age",decr).
by("gpa",incr).
limit(10).values("name").
Besides that, I think that choose() is kinda special:
.choose(condition(), then().do().this(),
else().do().that())
Cheers,
Daniel
On Fri, Mar 4, 2016 at 3:39 PM, Marko Rodriguez <ok...@gmail.com>
wrote:
> Hello,
>
> I'm futzing with our docs and noticed that the authors have different
> indentation styles for multi-line Gremlin traversals.
>
> I think we should converge on a similar style? ………
>
> And guess what, I think my style is the best.
>
> g.V().out("knows").out("attended"). // <1>
> group().by("state").by() // <2>
> select("Vermont").unfold() // <3>
> in("attended").has("gpa") // <4>
> order() // <5>
> by("age",decr). // <6>
> by("gpa",incr).
> limit(10).values("name") // <7>
>
>
> Key features:
>
> 1. A bunch of in().outs().filters().etc. on a single line until it gets
> too long.
> 2. If you bust a barrier (reducer, aggregator, etc.), new line.
> 3. When a next line component is an "add on" to the previous line
> component, 2 space indent.
> - that select() is "almost like" a by().
> - unfold() is a dirty sucky you just tack on the end and don't make it too
> prominent as its just data formatting.
> 4. Back to a series of in().outs().etc., new line.
> 5. Another barrier -- new line.
> 6. If there is only one by()-modulator (or a series of short ones), keep
> it on one line. If its complex, each by() is a line.
> 7. Back to a series outs().filters().maps().etc.
>
> In summary,
>
> 1. 2 space indent.
> 2. Nothing is on equal spacing with "g."
> 3. Barriers form line breaks.
> 4. by()-modulators form indented "paragraphs."
> 5. Standard filters.maps.flatmaps are single line until it gets unwieldy.
>
> Thoughts?,
> Marko.
>
> http://markorodriguez.com
>
> --
> You received this message because you are subscribed to the Google Groups
> "Gremlin-users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to gremlin-users+unsubscribe@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/gremlin-users/55E7B211-2B1B-4FDE-BC61-1C7A90428ECC%40gmail.com
> <https://groups.google.com/d/msgid/gremlin-users/55E7B211-2B1B-4FDE-BC61-1C7A90428ECC%40gmail.com?utm_medium=email&utm_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>
Re: [DISCUSS] Proper indentation of Gremlin traversals.
Posted by HadoopMarc <m....@xs4all.nl>.
Hi guys,
I do not want to risk never getting another one of Daniel's splendid
gremlin answers, but I am afraid that I like Marko's systematic "to
-the-left" indentation style better. Probably because it resembles the
python PEP-8 style I am used to (also python's 80 char line length limit
forces you to think about clean code formatting).
As to closures that do not fit a single line: I prefer to insert a named
lambda (in Java/Scala) or an externally defined string ${myClosure} (in the
Groovy repl).
Fixed styling rules per type of step could be cumbersome since a natural
grouping of steps will depend on the overall logic of the traversal.
Best wishes, Marc