[DISCUSS] Proper indentation of Gremlin traversals.

[Marko Rodriguez]

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

[Daniel Kuppitz]

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

--
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-user...@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.
For more options, visit https://groups.google.com/d/optout.

[HadoopMarc]

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

[Marko Rodriguez]

Hi,

What do YOU people think about putting this in the docs? That is, a multi-line style guide.

Marko.

http://markorodriguez.com

[Stephen Mallette]

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?

--
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-user...@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.

[Marko Rodriguez]

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.

To view this discussion on the web visit https://groups.google.com/d/msgid/gremlin-users/CAA-H43-gLSbzcFXqAA9meWjpjwdQ7GOCbHY2b5c%3DYFkCvkKYcw%40mail.gmail.com.