Michael

@scorpiuszjj you're right, the d could be changed to a c to avoid the i at the end, thus reducing the keystrokes further.

@rthbound ha! Nice.

I'm sure you know this, but it's worth noting for those reading that don't. You will need to git add your changes before you git commit --amend (like you usually do.)

Also, if you've already pushed the commit, force pushing to a remote repository can be very dangerous and I only recommend it if you absolutely know that no one has fetched those changes (like in the instance that you're working on a branch that no one else is working on.) Force pushing just needs to be done with a little caution, because it can cause major problems for other people who have based their work off of what would then be an invalid history.

@janosgyerik we're talking about system wide shortcuts. ^f and ^b are right on home row so no reaching, that's why I prefer it (very much so in fact.) ESC-f and ESC-b work per word in most places (and you can do ^[ instead of ESC as usual.)

Remember though, this is about system-wide commands for editing text. We have a lot of options at the command prompt, but programmers spend their time all over the place.

@zhimingwang I'm aware of the war, just making the point that I'm not participating in it. And I agree, I'm not taking any of this too seriously ...

@zhimingwang ha, not a war at all. Just two people who use two different editors.

@zhimingwang I still lovingly use vi :)

@zhimingwang there are good reasons to be familiar with both!

@alanpearce thanks.

@djtb ^u think this only works in emacs + zsh/bash. Not system wide.

@jayallen that is just at the command prompt. I wasn't saying programmers only use vi. I was just saying that these commands work everywhere outside of vi (e.g. emacs, sublime, command prompt, browser text field, browser url field, even renaming a filename in your OS GUI.) These commands, familiar to any emacs user, should be known by all programmers, because they are used just about everywhere we deal with text. That's all.

Where do you think I learned them from? :)

If you're unfamiliar you might find "hub" from GitHub useful. It lets you do this and much more: https://github.com/github/hub

@fernandoperigolo thanks for that note!

@SaberUK The point is that installing and updating coreutils keeps you up to date.

After having spent quite a bit of time doing benchmarks in a bunch of different languages I'm here to report that there is no significant performance improvement in a lot of the common languages. I still like this approach!

@viperxiv I certainly use them and generally think of state as "private". I think a good goal is to hide the state of the objects behind their behavior. Hopefully in the end you have some objects each with just a handful of state and all connected to one another through their public methods.

@toadjamb this doesn't "completely disregard breaking up a 10-line method into two (or more) smaller methods", I'm talking about those private methods too.

In regards to my saying "never do this" or "always do that" ... I never say anything like this directly in this post. However, I do think you should "always" second guess yourself when you're considering making some behavior private. In the same way I think you should "always" second guess yourself when you have too many methods, or too many properties, or you use single-character variables. If you feel it needs to be private in your object, it's most likely behavior that could be handled by objects from some other domain which offers that behavior publicly.

My goal isn't to incite readers. I find this to be a rewarding design technique. Describing the technique as a "bad smell" was deliberate. A lot of private behavior (or maybe even a little?) in my code base is a "symptom that possibly indicates a deeper problem". The deeper problem I think I keep finding when I encounter hidden behavior is lazily designed objects. By lazily designed objects I mean that the objects are doing just a little (sometimes a lot) more than their fair share. I say "lazily" because figuring out where the behavior makes the most sense being public is more work. Not that the programmer is lazy, but more work could've been done and it wasn't.

@mrfoto try it the next time you create a private method. Imagine that you wanted to avoid making it private, where would it make the most sense being public? I find this to be a productive activity for finding holes in my design, in particular with objects that are extending themselves beyond their single responsibility. Private methods are indicative of lazy abstractions, if you did nothing but find more appropriate public homes for your private methods you would end up with tighter abstractions. This means taking into account all of the design principles and heuristics that are at your disposal. Let me know if you find this to be a fruitless activity after trying it. Thanks.

Thanks! I'm a big supporter of YAGNI as any of my pairs might begrudgingly admit. I guess though we'll just have to disagree on this particular point. When I encounter a private method I see it as an excellent candidate for improving the design. I also consider the other bad smells, like the size of methods, the number of methods, the amount of state, and the overall conceptual surface area of the the object. The difference is that private methods aren't explicitly called out, which is what I'd like to do here. I'd encourage you to reconsider when using private methods, asking instead where you'd put that behavior if you were required to make it public. Thanks for all this feedback.

@brettof86 my point is to question the idea that "private methods are useful in some circumstances." What I'm suggesting is that they are a crutch for what could be further productive design. I specifically tried to cast it as a "bad smell" so that it might be used in the way bad smells are used. I'm as guilty of poor design as anyone else is I'm sure, but when I'm given the chance to clean up my design I like having things that cue me with where my design might be improved. Private methods are an excellent cue, they smell bad, I can almost always productively redesign the private aspects of my objects into public objects from a slightly more specific domain. I don't think this is unreasonable and naive. In fact I think it's good advice.

@ruiwen This is an option, yes, and I should've mentioned it. I still prefer not using C-a because it's a combination I use so often. C-o doesn't feel uncomfortable at all and it's used far less. In fact, the only time I use C-o is when I'm running a single normal mode command from insert mode in vim. Thanks for the input.