That rocks. The lookahead and keeping matches techniques are essentials.

Some people, when confronted with a problem, think "I know, I'll use regular expressions." Now they have two problems.

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

It is just "Distributive property". So p0 * (1 + percent / 100) is mathematically equivalent to p0 + p0*(percent / 100).

In what language would assignment to p0 mutate anything in a way noticeable for a caller? No matter if p0 holds a reference to an object, or a value, reassignment of p0 parameter won't mutate anything on the outside^†. Or will it?

^† I can point one language where reassignment of an argument can mutate values seen to the outside (without changing the syntax of a call), I wonder if there's more and what they are.

Whilst in JS, assuming p0 is a number, then mutation isn't going to happen, for people coming in from other languages it's uncomfortable to see. Generally it's a bad habit to 'mutate' arguments as you're increasing the cognitive load on future coders to know whether the argument is a reference or not. For example, if the code is refactored and now p0 is given as an object or an array - if the coder niavely updates the code, they could easily start actually mutating the argument. Of course, good testing will guard against this, but it is a bad habit unless you want mutation outside of the function.

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

I am also confused on how p0 = p0 * (1 + pecent/100) + aug works.
does the 1+ replace the need for p0 += p0 * percent/100 + aug?

10 + (10 * 0.05) === 10 * 1.05

While we all want to write more readable code, just remember that 'readability' sometimes depends on our ability to read! More advanced code may seem unreadable for beginners but may actually be very readable and concise the more one learns...

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

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 agree that we should avoid data mutations at all costs, but there is no need for this since we aren't working with references.

This is just completely wrong and stupid. You obviously have no idea how JS even works.