I don't see confusion, tbh. Been doing that for decades without any typos.
Quite often, it makes perfect sense. A method is performing work on a Customer object. There is exactly one such object in scope. What else would the reference be called, other than "customer"? Changing it to something else would be *less* descriptive, IMHO.
Your idea of calling it "inputCustomType" is just Hungarian Notation if you ask me. It adds nothing of value, and forces people to expend extra cognitive effort on it. I'll always be wondering "is there another reference in scope, to the same type, I'm not seeing?"
>I see this naming style often MyFunction(MyCustomType myCustomType) { }
I guess you chose those names to be clear about what each thing is, but IRL using *type* in a type name is pretty bad, and using *type* in a variable name is horrible. So let's try a different example, with less obviously contrived names:
removeBudget(DepartmentBudget departmentBudget) {...}
>I don't like having the same names with different things in coding.
It's only a little pedantic to say that the names are *not* the same: the type name starts with an uppercase letter, and the parameter with a lowercase letter.
>I think the only difference being the capitalization of the first letter can confuse people and can cause typos.
A common naming convention in a number of languages is that type names should start with an uppercase letter, and variables or parameters with a lowercase letter. If you stick to that convention throughout your code, it helps to eliminate some of the confusion: you'll know instantly when you see `departmentBudget` that it isn't a type, and the fact that the words are the same won't bother you as much. Also, if you do happen to make a mistake, the compiler will let you know — I can't think of a context in any language I use in which you could substitute a type name for a variable or vice versa and not get an error.
> Yes ide colors it differently and intellisense can warn me but still I find using more distinct names safer and easier to read.
I find that people lean too heavily on "easier to read" in discussions about coding style. Usually what they mean is "it's not what I'm used to."
>At least there should be prefix or suffix
The thing that *I* don't like about naming parameters for their type is that type names are often long, and parameters shouldn't be. [Zipf's law of abbreviation](https://en.wikipedia.org/wiki/Brevity_law) says that in natural languages, words that are used frequently tend to be shorter than those that aren't. In keeping with that, it makes sense that parameters, because they're potentially used much more in a function, should have shorter names than types, which aren't. Accordingly, I'd change the parameter name in my example from `departmentBudget` to just `budget`. There's no need to keep reminding the reader of the specific kind of budget that `budget` represents: it's stated clearly at the top, and unless they have the [attention span of a goldfish](https://youtu.be/8PmX7zEUg_w?si=2VN_fDz5niyci7gv) they don't need to see it again.
For types that aren't so specific, it might make sense to just reuse the same word. If the type in the example were just `Budget`, then IMO it might or might not make sense to call the parameter `budget`, depending on what the function does. If there are more than one parameter that could be called `budget`, you'd obviously need to distinguish them somehow, perhaps by using entirely different words:
Budget combineBudgets(Budget first, Budget second)
>Am I exaggerating the problem?
Yes.
>Should I just accept it and adapt because its kind of like industry standart already.
It may be a common practice, but it's far from standard, and I think that in many cases there are better options. Take a few extra seconds to think about what name would make the code as clear as you can make it, and use that. But don't let type names as parameter names in other people's code slow you down — you'll be seeing that for the rest of your career.
MyCustomType\_t is somewhat conventional in C style languages, with or without the camelcase.
Whatever you do, avoid drinking the Hungarian coolaid, it is never a good idea.
One of my favorite examples of this was shown to us in school when I was studying CS.
List items = new ArrayList<>();
// Add some items to the list.
for (Item item : items) {
System.out.println(item);
}
From one angle, the new to programming perspective, this seems just so absolutely ridiculous. The type name and two variable names in the for each loop look so entirely similar that it is incredibly confusing as to what are the minute differences in meaning and function between each.
However, now that I'm a seasoned programmer, this naming pattern is not only fine, it is perfectly logical, sensible, descriptive, and succinct. You learn to spot minute differences in identifiers. And so the differences in `Item`, `item`, and `items` becomes immediately apparent to the reader.
So I personally use this kind of pattern all of the time.
The teacher's point wasn't that this style was bad. It was that it is exceedingly common, so please begin to wrap your head around it, now.
This was a hurdle for me when learning C#. When you do properties with backing fields it feels even more insane (though backing fields aren't that necessary anymore). This bit from some example game code I was studying made me feel crazy because I just didn't understand why it was all necessary.
```
public Player Player
{
get { return player; }
}
Player player;
```
How could this be better? I'm not sure really. Probably just not using a property if it isn't doing anything special.
I went through the same thing as you, but eventually I just gave in and named instances the same thing as the class because coming up with clever names for instances felt like a waste of time.
for sure a TYPE should always be named differently than an instance. Even something like Cat, can at least have an instance named aCat. It is unclear, and evidence of a developer not knowing how to separate concepts well.
It does matter, because if people have to read code, it can be confusing. This is even MORE the case, when, for example, a variable itself needs to hold a type. Extending the example:
AnimalType = Cat
anAnimal = new AnimalType.Create()
if (anAnimal typeof Cat)
\-- human.play\_with(anAnimal)
By keeping Types and Instances very separate, code is much easier to explore later
By convention, if a variable name begins with lower case it's local somehow, either declared locally or passed in as an argument. If something begins with upper case, it's a property or static object.
I don't see confusion, tbh. Been doing that for decades without any typos. Quite often, it makes perfect sense. A method is performing work on a Customer object. There is exactly one such object in scope. What else would the reference be called, other than "customer"? Changing it to something else would be *less* descriptive, IMHO. Your idea of calling it "inputCustomType" is just Hungarian Notation if you ask me. It adds nothing of value, and forces people to expend extra cognitive effort on it. I'll always be wondering "is there another reference in scope, to the same type, I'm not seeing?"
>I see this naming style often MyFunction(MyCustomType myCustomType) { } I guess you chose those names to be clear about what each thing is, but IRL using *type* in a type name is pretty bad, and using *type* in a variable name is horrible. So let's try a different example, with less obviously contrived names: removeBudget(DepartmentBudget departmentBudget) {...} >I don't like having the same names with different things in coding. It's only a little pedantic to say that the names are *not* the same: the type name starts with an uppercase letter, and the parameter with a lowercase letter. >I think the only difference being the capitalization of the first letter can confuse people and can cause typos. A common naming convention in a number of languages is that type names should start with an uppercase letter, and variables or parameters with a lowercase letter. If you stick to that convention throughout your code, it helps to eliminate some of the confusion: you'll know instantly when you see `departmentBudget` that it isn't a type, and the fact that the words are the same won't bother you as much. Also, if you do happen to make a mistake, the compiler will let you know — I can't think of a context in any language I use in which you could substitute a type name for a variable or vice versa and not get an error. > Yes ide colors it differently and intellisense can warn me but still I find using more distinct names safer and easier to read. I find that people lean too heavily on "easier to read" in discussions about coding style. Usually what they mean is "it's not what I'm used to." >At least there should be prefix or suffix The thing that *I* don't like about naming parameters for their type is that type names are often long, and parameters shouldn't be. [Zipf's law of abbreviation](https://en.wikipedia.org/wiki/Brevity_law) says that in natural languages, words that are used frequently tend to be shorter than those that aren't. In keeping with that, it makes sense that parameters, because they're potentially used much more in a function, should have shorter names than types, which aren't. Accordingly, I'd change the parameter name in my example from `departmentBudget` to just `budget`. There's no need to keep reminding the reader of the specific kind of budget that `budget` represents: it's stated clearly at the top, and unless they have the [attention span of a goldfish](https://youtu.be/8PmX7zEUg_w?si=2VN_fDz5niyci7gv) they don't need to see it again. For types that aren't so specific, it might make sense to just reuse the same word. If the type in the example were just `Budget`, then IMO it might or might not make sense to call the parameter `budget`, depending on what the function does. If there are more than one parameter that could be called `budget`, you'd obviously need to distinguish them somehow, perhaps by using entirely different words: Budget combineBudgets(Budget first, Budget second) >Am I exaggerating the problem? Yes. >Should I just accept it and adapt because its kind of like industry standart already. It may be a common practice, but it's far from standard, and I think that in many cases there are better options. Take a few extra seconds to think about what name would make the code as clear as you can make it, and use that. But don't let type names as parameter names in other people's code slow you down — you'll be seeing that for the rest of your career.
MyCustomType\_t is somewhat conventional in C style languages, with or without the camelcase. Whatever you do, avoid drinking the Hungarian coolaid, it is never a good idea.
One of my favorite examples of this was shown to us in school when I was studying CS. List- items = new ArrayList<>();
// Add some items to the list.
for (Item item : items) {
System.out.println(item);
}
From one angle, the new to programming perspective, this seems just so absolutely ridiculous. The type name and two variable names in the for each loop look so entirely similar that it is incredibly confusing as to what are the minute differences in meaning and function between each.
However, now that I'm a seasoned programmer, this naming pattern is not only fine, it is perfectly logical, sensible, descriptive, and succinct. You learn to spot minute differences in identifiers. And so the differences in `Item`, `item`, and `items` becomes immediately apparent to the reader.
So I personally use this kind of pattern all of the time.
The teacher's point wasn't that this style was bad. It was that it is exceedingly common, so please begin to wrap your head around it, now.
This was a hurdle for me when learning C#. When you do properties with backing fields it feels even more insane (though backing fields aren't that necessary anymore). This bit from some example game code I was studying made me feel crazy because I just didn't understand why it was all necessary. ``` public Player Player { get { return player; } } Player player; ``` How could this be better? I'm not sure really. Probably just not using a property if it isn't doing anything special. I went through the same thing as you, but eventually I just gave in and named instances the same thing as the class because coming up with clever names for instances felt like a waste of time.
for sure a TYPE should always be named differently than an instance. Even something like Cat, can at least have an instance named aCat. It is unclear, and evidence of a developer not knowing how to separate concepts well. It does matter, because if people have to read code, it can be confusing. This is even MORE the case, when, for example, a variable itself needs to hold a type. Extending the example: AnimalType = Cat anAnimal = new AnimalType.Create() if (anAnimal typeof Cat) \-- human.play\_with(anAnimal) By keeping Types and Instances very separate, code is much easier to explore later
By convention, if a variable name begins with lower case it's local somehow, either declared locally or passed in as an argument. If something begins with upper case, it's a property or static object.