1. 6

    Probably a Sneak Peek, unless there’s a stealthy mountain involved.

    1. 1

      Reminded me that I haven’t looked at https://perkeep.org/ in years. Not exactly the same, but may be interesting to a similar audience.

      1. 1

        I looked at it a long time ago, but it was very low level and seemed that you only got it if you came from a certain niche.

        This OTOH looks immediately useful to me.

      1. 2

        I agree wholeheartedly with the author’s opinion on explicit vs. implicit nil.

        On the point of guard clauses we disagree.

        Except in this case, we’re not “guarding” the rest of the method from being run. That conditional is the entire raison d’être of the class.

        And indeed, the raison d’être (execute super when appropriate) remains the same – albeit with a ruby-idiomatic postfix conditional.

        Conditionals need not look a certain way. They don’t exist to lend a certain visual element to your code. Furthermore, Ruby is to blame for guard clauses, not Rubocop. It’s not unreasonable for Rubocop to recommend programmers express problems more succinctly. In my opinion, guard clauses make code more readable in code bases where they’re idiomatic. That’s an important caveat. If the developers you work with regularly ignore this Rubocop rule, then guard clauses will not be idiomatic in your code base, and you should avoid them for that reason.

        1. 2

          I wish the example wasn’t about ‘nil’ because the author seem to imbue ‘nil’ with some magic readability that I don’t think it has. It’s pushing the behavior back to the caller and having it decide what to do and I think that’s rarely a good idea.

          1. 1

            Yeah, for me it isn’t about nil specifically. Sometimes things read more clearly with explicit returns.

            1. 1

              The behaviour is identical in all the code examples. They all return nil under the same circumstances. The only difference is whether you can see it actually written in the code.

            2. 2

              My current opinion on guard clauses is that they are appropriate in specific situations (a couple spring to mind). I think it’s a false dichotomy to either try and use them as much as possible, or not at all. I can see an argument for never using them, depending on the people in your team, but personally I’m not on those kinds of teams.

            1. 2

              Odd that it mentions control-n (autocomplete based on next match) but not control-p (autocomplete based on previous match). I’m far more likely to want to autocomplete something that I’ve typed just before the insert point than just after, so I find control-p gives the completion that I want higher up the list (usually at the top) than control-n.

              ci<char> is interesting and something I should probably learn. I typically use d% to delete bracketed things, but that requires me to be at the start or end of the block.

              S is great to mention, I think they’re assuming everyone knows s (delete the current character and insert), which I use regularly but didn’t learn until 5-10 years after I started using vim.

              A few of these (I, S, O) are variations of the same command as a lower-case thing. That’s a general pattern in vim and good to highlight: if there’s a lower-case command you use frequently, try hitting the upper-case variant and see what happens: it’s probably something useful (e.g. D deletes to the end of the current line).

              1. 1

                ci is interesting and something I should probably learn.

                You can also use cib for parens, “change inside block” is how I remember it. But yeah being able to use other chars is cool, I didn’t know you could do that.

                1. 1

                  i<delimiter> is a motion that goes with any command. So di{ deletes everything inside a set of curlies, vi’ enters Visual and highlights everything inside a set of single quotes, etc.

                  There’s also a<delimiter>, which is the same motion except it includes the delimiters themselves. “i” for “inside”, “a” for “around”.

                  My biggest revelation using vim/evil-emacs is that it’s really a whole composable command language.

                  1. 3

                    i is a motion that goes with any command.

                    ah, now that you say it im like “doh that should have been obvious!” but i never thought about it. thanks!

                    My biggest revelation using vim/evil-emacs is that it’s really a whole composable command language.

                    Absolutely, if you think of it as command hotkeys, it will be confusing, but if you think of it as composing little sentences to tell the editor what to do, then it makes a lot more sense.

                    1. 2

                      To learn all of them you can :help text-objects

                1. 2

                  If anyone is interested, this is the Sandi Metz talk from which the article is taken https://www.youtube.com/watch?v=OMPfEXIlTVE