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