First define Clean code in a small context.

The context is all.

Is a test? A MVP? An architecture? or merelly a beginner kata?

A pragmatic programmer who applies Clean code also balances:

• designing/coding spent time
• readability
• available time and money cost

I agree that this isn't best practice, though it is a decent solution. For instance, I wouldn't want the arguments to be changed in the function body as it leads questions about accidental mutation (particularly if you come from another language). Of course, the argument names are bad, but as they are given by the Kata I can understand keeping them the same. However y to stand as number of years is a poor choice. With modern IDEs, there's very little reason to not use descriptive variable names. So if this was a professional codebase, I would want some changes before I would accept this.

But definitely a good solution in terms of solving the problem

If you want to make it more readable you can always customise the arguments yourself.

Fixed.

I agree with chandlerroth, this is a brilliant and concise solution but readability / reusability is terrible.

I do agree with chandlerroth here, I don't think he meant to be insulting in any way. This code, if come across in an actual code base, would stop me in my tracks and would demand refactoring or renaming. I am new here, so I am not exactly sure what the target is here at codewars but I don't see how so many people find this solution as "best practice".

I meant no attack on you personally, Azuaron (or the other warriors who completed with this code). I applaude your ability to write something in a consise mannor that solves the problem. However, I do not believe this solution best represents the term "Best Practice". It is clever, but a solution that I would consider "Best Practice" would also clearly convey the intent of what the code is accomplishing.

Emotion is hard to convey over text, and I assure you that my words in the previous post carried no malice with them. Thank you for your reply, and in future posts I will be sure to convey my opinions more clearly.

Imagine walking up to someone, opening your remarks by saying their code's bad, then expecting them to listen to anything you had to say.

Not best practice. Imagine trying to read this function with no context of the problem it was trying to solve. What does p stand for? How how about aug? Consider changing the argument names at least to something more readable.

I would also agree with @weejo on the argument mutation problem of this solution.

The Ruby version needs updating. It gives code as a starting point, and gives away another solution in the test file.

@JavierHeisecke my pleasure! And @Chrono79 I will keep that in mind, thank you. What is the edicate here on spoilers, then?