-1

I just found the following code in our code base:

public String identifyArchitectureName(String platformName, String input) ...

In my opinion input is one of the most meaningless names for a variable that can be. Is it just me? I can just quietly change it, but should I address the fellow programmer that has done it?

Improve this question
  • 2
    Ask the other programmer "What is 'input'?" Keep asking for further explanation until he gives you the answer you want to hear. Then change the name to that answer. – kevin cline Apr 5 '12 at 15:50
5

It depends on the context to me.

string GetEncrypted(string input)

quite obviously, input is a string to be encrypted. What would you rename this parameter to?

I also use str for methods that perform conversions or string manipulations

MyEnum Parse(string str) // what could str be? login? password? text to be parsed?

public static int? TryToInt(this string str)

I don't think this is the same as

public String identifyArchitectureName(String platformName, String input)
Improve this answer
  • Marking as an answer for providing an example for an adequate use for the parameter name. – Vic Apr 5 '12 at 10:12
  • @Vic Cheers! [3 more to go] – Konrad Morawski Apr 5 '12 at 10:21
  • I'd rename the method to Encrypt and the argument to plaintext. – CodesInChaos Mar 1 '13 at 21:41
4

Part of working with others is educating/teaching/mentoring them, in particular if you have seniority.

By all means, take it up with the developer and come up with a better name together.

Improve this answer
1

You are right that the name input doesn't communicate it's intention really well. Uncle Bob talks about "Boy Scout Rule" in his book Clean Code: "Leave the campground cleaner than you found it." The idea is that if you refactor code every time you touch, it is impossible for the code quality to degrade. So feel free to replace the parameter name to more descriptive one.

I wouldn't necessarily confront my coworker for a single instance like that. If that sort of bad naming conventions are typical in you project, then you should gather your team together and come up with common conventions about naming, style etc. Then after everybody knows the rules, they can be enforced with code reviews.

Still, everybody makes mistakes and nitpicking about one parameter name is not cool :) just fix it and get on with whatever you are doing

Improve this answer
0

Do you mean input? Just change it, if you think there is a better name.
It's parameter, renaming it won't break any code.

Improve this answer
  • Hi, of course it won't, just shouldn't parameters called Input be a taboo? – Vic Apr 5 '12 at 8:54
  • 1
    Depends on the context. I have many parameters named value which make a lot of sense in their context. input does seem a little on the extreme side of ambiguity. – MattDavey Apr 5 '12 at 8:59
  • @Vic, I don't think it's such a big deal. The first parameter have a decent name, so the second could be named so poorly just by occasion. – Abyx Apr 5 '12 at 9:01
0

I'm in two minds about whether you should confront the other programmer.

My first thought is that I'd be inclined just to rename it and be done with it.

While we should all be big boys about receiving critique, having a conversation about a parameter name on face value seems almost a little petty or over the top.

That being said, if this was just one of a series of "little petty" things I can see it might be the straw that breaks the camel's back.

Do you have a formal peer review process that you could cover this in?

Improve this answer
0

Change it? Sure.

Confront the other person? Not so fast. I'd rather see you kick off a group discussion about coding standards, and add a paragraph to the coding standards document (you have one, right?) that specifies that in non-trivial cases, formal parameters should be self documenting.

Improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.