<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div><span style="-webkit-text-size-adjust: auto; background-color: rgba(255, 255, 255, 0);">> On second thought, I think the extra newlines actually improve *reading*<br>> but may somewhat impare *scanning*.<br><br>> Consider:<br>> <a href="https://github.com/zxq9/zuuid/blob/master/src/zuuid.erl" x-apple-data-detectors="true" x-apple-data-detectors-type="link" x-apple-data-detectors-result="1">https://github.com/zxq9/zuuid/blob/master/src/zuuid.erl</a></span></div><div><span style="-webkit-text-size-adjust: auto;"><br></span></div><div><span style="-webkit-text-size-adjust: auto;">Ah, much easier on my aging eyes.</span></div><div><span style="-webkit-text-size-adjust: auto;"><br></span></div><div><span style="-webkit-text-size-adjust: auto;">Best wishes,</span></div><div><span style="-webkit-text-size-adjust: auto;"><br></span></div><div><span style="-webkit-text-size-adjust: auto;">LRP<br></span><br><span style="-webkit-text-size-adjust: auto;">Sent from my iPad</span></div><div style="-webkit-text-size-adjust: auto;"><br>On Feb 4, 2016, at 7:52 AM, zxq9 <<a href="mailto:zxq9@zxq9.com">zxq9@zxq9.com</a>> wrote:<br><br></div><blockquote type="cite" style="-webkit-text-size-adjust: auto;"><div><span>On 2016年2月4日 木曜日 07:29:06 Nathaniel Waisbrot wrote:</span><br><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>I don't even like the idea of using maps for this, but the "old</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>fashioned" tuple type seems to be discouraged in the R18 docs. Meh.</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>So much for trying to be hip to the new thing. I like my old tuples.</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>I don't think there is anything in here that doesn't work even with</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>rather old ERTS releases, so I'm switching this (back) to tuples.</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>With regard to tuples VS maps for trivial things like this... I almost</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>feel like its a case of getting a newfangled toy and simply feeling</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>compelled to use it everywhere.</span><br></blockquote></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>As someone with less than 10,000 hours of OTP code under my belt, I found</span><br></blockquote><blockquote type="cite"><span>this change (tuples to maps) to be so useful that I immediately upgraded</span><br></blockquote><blockquote type="cite"><span>all my code to require version 18.</span><br></blockquote><blockquote type="cite"><span>With the tuples, I had to check the documentation every single time I made</span><br></blockquote><blockquote type="cite"><span>a supervisor to confirm whether it was `intensity` or `period` first. I</span><br></blockquote><blockquote type="cite"><span>also would get copy/paste errors because I'd copy the child spec for a</span><br></blockquote><blockquote type="cite"><span>worker that was set to `brutal_kill` and use that as template for a</span><br></blockquote><blockquote type="cite"><span>supervisor without changing it to `infinity`.</span><br></blockquote><blockquote type="cite"><span>The new maps are self-documenting and they provide sane defaults so that if</span><br></blockquote><blockquote type="cite"><span>I want a vanilla supervisor I can just say `#{id => cool_super, start =></span><br></blockquote><blockquote type="cite"><span>{M, F, A}, type => supervisor}`. Not only do I avoid dumb bugs, but it's</span><br></blockquote><blockquote type="cite"><span>also clear that this is a vanilla supervisor and not something more</span><br></blockquote><blockquote type="cite"><span>interesting.</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>It seems like a small change, but I thought the old tuples were _awful_ and</span><br></blockquote><blockquote type="cite"><span>I was very happy to see them marked as deprecated.</span><br></blockquote><span></span><br><span>Having a method for defaulting to sane values (using maps for convenience)</span><br><span>makes perfect sense. But *deprecating* tuples bothers me -- it means that</span><br><span>eventually every piece of OTP code is going to break or have to be</span><br><span>(arbitrarily) moved forward to maps for no gain.</span><br><span></span><br><span>Ideally, if I could have my way... and actually I can, so I'm going to add</span><br><span>something like this to my own templating tool...</span><br><span></span><br><span> vanilla_worker(Name) -></span><br><span> vanilla_worker(Name, []).</span><br><span></span><br><span> vanilla_worker(Name, Args) -></span><br><span> {Name,</span><br><span> {Name, start_link, Args},</span><br><span> permanent,</span><br><span> brutal_kill,</span><br><span> worker,</span><br><span> [Name]}.</span><br><span></span><br><span>...And maybe one or two more really common ones.</span><br><span></span><br><span>I find it every bit as annoying to define a bunch of nearly identical</span><br><span>maps as a bunch of nearly identical tuples. I generally only have to do</span><br><span>this from scratch *once* per project, which is really not a big deal.</span><br><span>Its annoying either way, but its typically a one-off annoyance.</span><br><span></span><br><span>(Until now I've just had a template I have a script pull over and start</span><br><span>from there, so I sort of forgot that this could be annoying.)</span><br><span></span><br><blockquote type="cite"><blockquote type="cite"><span>Oh, a layout issue. I don't like big black blobs (except when I</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>write them). So</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>%% wdrwertwertwert</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>%% wertwertwertwrt</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>%% wretertwertwertew</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>-spec frgsdfgdfghsdfg</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>asdfasdf(sdfgsdfg) -></span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span> ....</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>is just a bit too much for me to be comfortable with. I'd find</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>it easier to read with blank line after the %% comment block</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>and a blank line after the -spec.</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>I find that with my OWN code it's so obvious that packing it</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>tightly doesn't impair readability, but with someone else's</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>code well-placed blank lines never go amiss. I can only suppose</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>that I'm in error about my own code and that it too could do with</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>more blank lines.</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>*MY* code is always perfectly readable as big, immaculate, unbroken</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>blocks. Until a few months later. Ugh.</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>I'm not sure where I stand on the line break issue, really, but since</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>you mentioned it I'm trying out a line between doc and spec, a line</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>between spec and definition, and two lines between functions (but no</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>lines between function clauses -- I already know that confuses me,</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>especially with un-specced/un-docced functions).</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>I don't feel very strongly on this one (I do about the supervisor spec),</span><br></blockquote><blockquote type="cite"><span>but I find the tight-packed blocks _more_ readable in other people's code.</span><br></blockquote><blockquote type="cite"><span>I run my eyes down the left-hand side and see</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>%</span><br></blockquote><blockquote type="cite"><span>-</span><br></blockquote><blockquote type="cite"><span>a</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>And that's pretty clearly (1) some comments, (2) a compiler directive, (3)</span><br></blockquote><blockquote type="cite"><span>a function. They all go together: I expect the comment to be function</span><br></blockquote><blockquote type="cite"><span>documentation and the dash to be a function spec.</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>If I see</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>%</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>-</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>a</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>Then the comments might be module-level comments and the directive might be</span><br></blockquote><blockquote type="cite"><span>an export or an if or a define or a type declaration and I have to read</span><br></blockquote><blockquote type="cite"><span>more characters to figure out if those three lines are related.</span><br></blockquote><span></span><br><span>I sometimes think so myself. In this case, though, where every function has</span><br><span>an explicit `%% @doc` at the head of the function docs and everything else</span><br><span>follows a pretty obvious pattern, I do indeed find it easier with the extra</span><br><span>lines. With a mishmash of styles in a single source file, though... ugh. I</span><br><span>think it would get really annoying. Tomorrow I'll check again and see which</span><br><span>I like. Part of my goal here is to get some feedback before I start doing</span><br><span>more open-source stuff... the place I've been coding the last year has been</span><br><span>rather niche and impossible to make generally applicable someplace like</span><br><span>github.</span><br><span></span><br><span>On second thought, I think the extra newlines actually improve *reading*</span><br><span>but may somewhat impare *scanning*.</span><br><span></span><br><span>Consider:</span><br><span><a href="https://github.com/zxq9/zuuid/blob/master/src/zuuid.erl">https://github.com/zxq9/zuuid/blob/master/src/zuuid.erl</a></span><br><span></span><br><span>One clear advantage is that my super-lazy-man's navigation in vi is far</span><br><span>more precise now, as each function and spec had is the start of what the</span><br><span>editor sees as its own block. Not a big deal (I usually jump directly to</span><br><span>wherever I want to go), but it is sort of nice.</span><br><span></span><br><span>-Craig</span><br><span>_______________________________________________</span><br><span>erlang-questions mailing list</span><br><span><a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a></span><br><span><a href="http://erlang.org/mailman/listinfo/erlang-questions">http://erlang.org/mailman/listinfo/erlang-questions</a></span><br></div></blockquote></body></html>