It even exists but in general it doesn’t pay. You do what we call abstraction, so you create another method that calls this one and then give it a smaller (better) name. In some cases you may even have an optimization and no additional cost, but you may not have this optimization for a number of circumstances and then you pay a running price to type less.
public static class DateUtils { //algumas pessoas criticam este tipo de coisa
public static string ToShortDatePtBr() => StringFormats.DatetTimeToShortDateStrPtBR();
I put in the Github for future reference.
It changes very little because it will call:
DateUtils.ToShortDatePtBr();
In some contexts it is possible to apply some different technique to get some result, but nothing that indicates in the question.
And obviously being a code of yours in the original method can change the writing of it to give shorter names (not that I’m recommending because it depends on context as well, and it doesn’t seem much that this is the case except perhaps by DatetTime
initial and who knows this Str
, that is, the original name is poorly defined). The problem with this name is that it seems to have been ill-defined, not that it needs to get smaller, it needs to get better. If I were to do this with a method with a good name it would certainly only get worse by giving a smaller name.
I don’t think it’s extensive anything that’s readable to indicate what the method is doing. In general shortening more than should take away the legibility of the significance of what is running there is worse, even this shortening can easily increase confusion by not indicating well what is doing.
And that has nothing to do with repetition. If you use this once there is no repetition, if the method calls A
and use 2 times will have repetition, so the question starts from wrong premise.