4 ms·

With the right definition of nit, I agree. However, the first example is "a variable name that could use a more appropriate word" AKA "a variable name that incr

With the right definition of nit, I agree. However, the first example is "a variable name that could use a more appropriate word" AKA "a variable name that increased confusion". If perfect performance optimization doesn't matter, then don't review for it, but code readability does always matter. It won't be them who has to fix it in a few years, so take every opportunity to change things that put friction on the path of enlightenment to within the bounds of your capacity to sacrifice optimizations. It doesn't make you an irascible ass to say "I find this variable name confusing. Can we change it to something more like X?"

woutr_be 6y ago
> "I find this variable name confusing. Can we change it to something more like X?" My problem with stating it like this is that when the person saying this is in a position of authority it’s extremely hard to say no to it. And that person might not always be necessary right, or the person writing the code had a good reason for this naming, and now can’t argue against it. While there are best practices for naming, people often have different opinions, but that doesn’t mean one is right and the other one wrong.
- BugsJustFindMe 6y ago
  > it’s extremely hard to say no to it. Good. A person just told you that you did something that confused them. You don't have to rename it to "X" exactly, but you do need to try to do something that communicates effectively to your collaborators. > And that person might not always be necessary right There is no right. There are only confusing and not-confusing. A person that you're collaborating with just told you that what you did is unclear to them. That means you have to make things more clear. I don't care if your solution to this problem is to just add a comment, as long as you're both happy that the end result communicates your ideas effectively. But you have to do something to fix the fact that your original variable name didn't communicate what you thought it would. > that doesn’t mean one is right and the other one wrong Thinking of names as objectively right or wrong is a mistake. Names either add confusion or reduce confusion. Striving for the latter requires meeting your interlocutor halfway.
  - woutr_be 6y ago
    > A person just told you that you did something confusing. The person told me that I did something confusing to them. And with using that kind of format, almost forces you to have to pick his opinion. Because now instead of clarifying your choice of naming, have to now defend your choice against his or her. > There is no right/wrong here. There is only confusing and not-confusing. A person that you're collaborating with just told you that what you did is _unclear_ to them. That means you have to clarify what you did. A person just told me they find a name confusing, and asked if it can be changed. That person could’ve clarified why it was named a certain way, but instead just proposed a change. Again, the way the comment was written makes it extremely hard to do anything other than use the proposed new name. > Thinking of names as right or wrong is a mistake. Names either add confusion or reduce confusion. Always strive for the latter. That’s an extremely subjective statement, and to me is not how things are in the real world.
    - BugsJustFindMe 6y ago
      > And with using that kind of format, almost forces you to have to pick his opinion. I said that it needs to communicate the right information to both of you, not just to you and not just to them. If their suggestion still communicates to you, then suck it up and admit that they came up with a better name. If it _doesn't_ but you use their suggestion anyway, then you've just failed at being part of a team. It's on you to learn how to say "that's unclear to me, let's look for a third option". > have to now defend your choice It sounds like you think you're likely to feel defensive about having created confusion for someone. Maybe focus less on defending and more on achieving clarity.
      - woutr_be 6y ago
        > I said that it needs to communicate the right information to both of you, not just to you and not just to them. Right, but you see how it took multiple back and forwards to even clarify what you wanted to achieve? The same goes with your original comment. > "I find this variable name confusing. Can we change it to something more like X?" You don't clarify why it's confusing, so I don't know your interpretation of what the variable represents. I need to first understand as to why you find this confusing, and how your new proposed naming will help to clarify. > It sounds like you think you're likely to feel defensive about having created confusion for someone. Maybe focus less on defending and more on achieving clarity. I do not, and it's pretty bad practice to assume this of people. This comes back to the whole nitpicking, to me it sounds like you were nitpicking on the naming. You didn't clarify your stance, or what caused you confusion. And leave it up to me to reach out to you to clarify this. This could've been communicated in your first PR comment, so that we didn't have to go through this dance.

woutr_be 6y ago

> "I find this variable name confusing. Can we change it to something more like X?" My problem with stating it like this is that when the person saying this is in a position of authority it’s extremely hard to say no to it. And that person might not always be necessary right, or the person writing the code had a good reason for this naming, and now can’t argue against it. While there are best practices for naming, people often have different opinions, but that doesn’t mean one is right and the other one wrong.

BugsJustFindMe 6y ago
> it’s extremely hard to say no to it. Good. A person just told you that you did something that confused them. You don't have to rename it to "X" exactly, but you do need to try to do something that communicates effectively to your collaborators. > And that person might not always be necessary right There is no right. There are only confusing and not-confusing. A person that you're collaborating with just told you that what you did is unclear to them. That means you have to make things more clear. I don't care if your solution to this problem is to just add a comment, as long as you're both happy that the end result communicates your ideas effectively. But you have to do something to fix the fact that your original variable name didn't communicate what you thought it would. > that doesn’t mean one is right and the other one wrong Thinking of names as objectively right or wrong is a mistake. Names either add confusion or reduce confusion. Striving for the latter requires meeting your interlocutor halfway.
- woutr_be 6y ago
  > A person just told you that you did something confusing. The person told me that I did something confusing to them. And with using that kind of format, almost forces you to have to pick his opinion. Because now instead of clarifying your choice of naming, have to now defend your choice against his or her. > There is no right/wrong here. There is only confusing and not-confusing. A person that you're collaborating with just told you that what you did is _unclear_ to them. That means you have to clarify what you did. A person just told me they find a name confusing, and asked if it can be changed. That person could’ve clarified why it was named a certain way, but instead just proposed a change. Again, the way the comment was written makes it extremely hard to do anything other than use the proposed new name. > Thinking of names as right or wrong is a mistake. Names either add confusion or reduce confusion. Always strive for the latter. That’s an extremely subjective statement, and to me is not how things are in the real world.
  - BugsJustFindMe 6y ago
    > And with using that kind of format, almost forces you to have to pick his opinion. I said that it needs to communicate the right information to both of you, not just to you and not just to them. If their suggestion still communicates to you, then suck it up and admit that they came up with a better name. If it _doesn't_ but you use their suggestion anyway, then you've just failed at being part of a team. It's on you to learn how to say "that's unclear to me, let's look for a third option". > have to now defend your choice It sounds like you think you're likely to feel defensive about having created confusion for someone. Maybe focus less on defending and more on achieving clarity.
    - woutr_be 6y ago
      > I said that it needs to communicate the right information to both of you, not just to you and not just to them. Right, but you see how it took multiple back and forwards to even clarify what you wanted to achieve? The same goes with your original comment. > "I find this variable name confusing. Can we change it to something more like X?" You don't clarify why it's confusing, so I don't know your interpretation of what the variable represents. I need to first understand as to why you find this confusing, and how your new proposed naming will help to clarify. > It sounds like you think you're likely to feel defensive about having created confusion for someone. Maybe focus less on defending and more on achieving clarity. I do not, and it's pretty bad practice to assume this of people. This comes back to the whole nitpicking, to me it sounds like you were nitpicking on the naming. You didn't clarify your stance, or what caused you confusion. And leave it up to me to reach out to you to clarify this. This could've been communicated in your first PR comment, so that we didn't have to go through this dance.