add helper methods for accessing params - #233

Getting the parameter value only to check if the parameter exists if wasteful. Consider a parameter which stores a large amount of data.

c48fb0e

Please revise the indentation here since it is really hard to read.

Please make a specific suggestion for how to revise it. The current version passes the linter and I'm not able to run your hard-to-read detector locally.

The common rule says: everything with in block ((, {, <) should be indented one level further in order to make it distinguishable.

In this case you can do e.g.:

typename std::enable_if<
  std::is_integral<type>::value && !std::is_same<type, bool>::value, int64_t>::type

or

typename std::enable_if<
  std::is_integral<type>::value && !std::is_same<type, bool>::value,
  int64_t>::type

OK, I did that in ecdc01b.

But we've got to figure out a better way to handle style. It's frustrating and unproductive to have the style rule be: "make our incredibly picky linters happy, but then also make whatever changes are preferred by other developers, according to various unwritten rules."

Technically both before and after styles were "correct", as they passed our linter and guidelines, but the new version you committed is more readable, at least in my opinion. Unfortunately getting a linter to tell you when something could be more readable is really hard, and figuring out how to make code look readable and still remain concise is a little bit of an art form. To that end, I think as much as possible in these cases should be left to the developer's discretion. In this particular case, I'd say what you originally did was fine. But I don't see any reason that one developer can't suggest an alternative syntax that is easier to read or understand, which is what I'd say is happening here. @dirk-thomas may see it differently, but you could refuse to change it too, if you like. I'd also say this one of those situations where empathy for the other developer would suggest that you make a pr to do the change for the original developer. That way it can be either merged or rejected, but it minimizes effort and frustration on the part of the original developer. At the very least, starting with a specific suggestion on how to change it and some rational why you think it's better.

<pedantry>
Also, @gerkey I'll have to disagree with your commit message 😄, if there is a style standard for a project or language (e.g. PEP8), then there is such thing as a correct and an incorrect style in certain contexts. One could say that there's no universally correct style or that correct style is is always in the context of a style standard. One could also say that there is no objectively superior style standard, but that's a different thing.
</pedantry>

In this specific case (indenting blocks of code) I think it doesn't really matter what the linter allows beside it. This rule is common across almost all style guides I have ever seen. In my opinion not every code passing our linters is "good to be merged". I could make numerous examples which linters won't catch but would look pretty bad - hopefully others would agree.

Also implying that any kind of style changes can be left for other peoples is not a good proposal. Simply because that means when creating a pull request you have the "freedom" to do whatever passes the linters and leave the
cleanup to other people.

With the goal in mind to develop well readable, consistent and maintainable source code we should follow rules (even when not covered by a linter). If some are not documented we should try to do that so that everybody is on the same page.

I like the idea of putting the burden on the reviewer to specifically propose non-essential style changes, with the original developer having the authority to make the final call.

I think that's ok so long as the the developer tries to avoid the need for such changes over time. I think it will work out better if both sides are more generous with their effort.

I could make numerous examples which linters won't catch but would look pretty bad - hopefully others would agree.

I'm pretty sure that in any of those cases, I might prefer it to be different or think that it looks strange, but I wouldn't label it as wrong or prevent a merge based on that unless it's a functionally dangerous style (e.g. if-statement without brackets). I think it's unreasonable to require style enforcement which is not covered by the linter. I think it is reasonable to ask people learn the team's prefered styles that aren't covered by the linter over time and to be open minded to style changes when they are suggested during reviews.

Also implying that any kind of style changes can be left for other peoples is not a good proposal.

What I was implying was that it would be courteous to offer to fix style changes, either because the original developer may disagree with you or because they're not aware of a potentially better way to do it. And in both cases you're likely to get a more positive response if you act more humbly and respectfully. Hopefully they will agree that the proposed style is better, and in the future they'll apply these suggestions to their own original work and there won't be any need for further pr's from reviewers. As you suggested, we can also capture these best practices that aren't covered by the linter in one of our online documents, if they aren't already. But to require someone, especially a less frequent contributor, to "just know" is unreasonable imo, and if you insist that they fix every little item you see it's just going to frustrate them further.

Simply because that means when creating a pull request you have the "freedom" to do whatever passes the linters and leave the cleanup to other people.

I've never heard the word freedom used in such a negative tone... 🇺🇸 Everyone should try to get the style in a reasonable state on the first try so others don't feel as if they have to "cleanup" after someone, but if they don't realize it and the linter didn't tell them, then I don't see how we can require it of them. When we think it could be better, then we should offer to help, not demand it should change in exchange for allowing it to be merged.

With the goal in mind to develop well readable, consistent and maintainable source code we should follow rules (even when not covered by a linter). If some are not documented we should try to do that so that everybody is on the same page.

I agree with most of that, except that we should be patient and lenient with style that isn't covered by the linter, i.e. "ask" not "tell", especially for some of the more subjective changes. In general I think that a more courteous attitude on the reviewer's side and an open minded attitude on the developer's side would go along ways to accomplishing those goals.

Style is debatable, and while we generally defer to the linter, nobody gets a veto. When there's a question as to what's preferred, we should default to give preference to the person who took the time to write the code.

+1, @wjwwood

I was cut off getting on a plane: we can't go wrong by being more open-minded, generous, and courteous.