Comment by nine_k | Hacker News Reader

Comment by nine_k | Hacker News Reader

Parent Full thread

1. The number of cases where a one-character variable name is a good choice is small, and those are usually limited to the scope of a single loop, a lambda parameter, etc. A good linter should understand that.

Though naming is hard, and coming up with a descriptive and short name is often not easy. It's a worthy exercise, though, it makes you think about what this thing really is, and can even uncover bugs.

2. Test the public interface. Don't write, rewrite, or remove tests that test specific implementation details, to say nothing of trivial things like getters / setters. In a a good test suite, 20% of tests break during a big refactoring, but the remaining 80% show you that you're still on the right track. Most of the broken tests are often easy to fix mechanically, and those that need thinking, would need thinking anyway. They test the actually changed stuff.

3. Commit more than daily; commit with every change worth looking at, or reverting to. Spend these 15 seconds thinking up a good commit message.

Squashing on development branches is both counter-productive, hostile to code reviewers, and needless. Git can auto-squash commits on a merge for ages. Github has a checkbox for it, so does Bitbucket. Use that.

1. I did say sometimes that single letter variable are okay not always. The example you mentions are good cases. Especially lambda functions. If its not mentioned some will interpret that single letter variables are always bad.

2. My experience says that is too static way of thinking. Maybe I work in too fast paced place, but usually we learn that previous written software is not good today and we need to rewrite the code to make it better. Rarely have I seen that interfaces stays the same forever.

3. Whats the difference here? Squashing on a development branch vs on merge? Btw I do commits daily with good messages, but I am just wondering what I get from this if I loose it later anyway.

If you have to severely rework interfaces very often, your area may indeed be very fast-paced; e.g. so fast where reasonable design and planning is impossible. (I can name a few areas like that, e.g. trading algorithms.)

If you, in your very fast-paced environment, ever do code reviews, you likely noticed that showing the thought process, or separation of concerns, in separate commits helps reviewers wrap their heads around your changes. Adding commits that address feedback also helps the review process. Another feature of multi-commit development is when you notice that e.g. a particular feature won't fit in the next release, and you take only these changes to a different branch.

I guess its subjective/individual what is considered fast-paced. I would consider it normal web-development in agile environment. There is time for design and planning but you also have to be practical and get work done. Good design is preferred but change will happen, otherwise you can end up shoehorning yourself.

We already have practices about keeping PRs small so one could argue having to focus on crafting good individual commits is not that important in the grand scope of things. Especially if those carefully crafted messages will go lost after a merge. Some PRs require heavy reviews, while others just require a quick look through. From my experience people usually look at the changes and not the commit messages (myself including).

> Another feature of multi-commit development is when you notice that e.g. a particular feature won't fit in the next release, and you take only these changes to a different branch.

If your PRs are small you could also just move the changes yourself manually. Or you could do as you say and move each 'WIP' commit if necessary.

Reply on news.ycombinator.com