The most important aspect in teaching someone programming is making him understand how the programs work in a way that's most familiar to them.
I beg differ. I think programmers can be more productive if they understand a language in its own logic than if they try to translate it in common English. Furthermore, when you create a "buffer" variable it creates the expectation that it might be used again if you have to remember that this variable has been created for the rest of the algorithm it dilutes your attention for the rest. Redundancies in the code also makes it harder to modify.
You seek productivity in the wrong places. What you did to your professor's code is more akin to
code golfing rather than refactoring.
if they understand a language in its own logicThe logic behind languages that fit the imperative programming paradigm (PHP is one of them) is imperative programming itself. You have a sequence of steps that change the state of the program when they're executed. This holds true for any language that allows you to do this; a broken logic written down in PHP is still broken if transposed in another language.
Specific languages provide extra tools that let you express your intent more easily. The ternary operator is one of them, and if used wisely, can make code shorter without affecting readability.
$car_speed = IsKeyPressed() ? 100 : 0;
It's best applied when the statements are
short and can be quickly
read by the programmer. When you have to split the statement into multiple lines, it means it's too long. Jumping from line to line and merging them all into a single expression takes longer than staying on the same line for the reader. Productivity is decreased in this case.
Furthermore, when you create a "buffer" variable it creates the expectation that it might be used again if you have to remember that this variable has been created for the rest of the algorithm it dilutes your attention for the rest. This is not true. For this case, I'll mention that variables have:
1) A name. If set properly, the name itself will tell you what the variable is used for. This increases the productivity tremendously, because it lets programmers have a better grasp of the algorithm laid before their eyes. Intermediate results can be stored safely in one-shot variables if the names of the variables make the code easier to understand. An example below where an intermediate variable is a nicer choice than plugging in the formula as a parameter or wrapping it in a separate function.
$required_experience = Sqr($current_level * 0.5f);
ShowExperienceDifference($required_experience, $current_experience);
v.s.
ShowExperienceDifference(Sqr($current_level * 0.5f), $current_experience); //Is the result of Sqr the required experience or something else?
2) A scope. As a rule of thumb, a variable must be declared in the scope most fit for it, and its lifetime must end when the execution goes out of that scope. Usually, you deal with variables local to methods and functions. Methods and functions, to be easily read and understood, should be as short as possible. The average, as I've noticed, lies around ~8 to 10 lines of properly formatted code. 8 lines is not
a lot of code through which to remember about a specific variable. If the variable is also aptly named, you won't even call it remembering the variable. You'll call it understanding the variable's purpose. It won't dilute your attention to the rest.
Redundancies in the code also makes it harder to modify.With this I agree. Your professor did duplicate code without reason, which is something bad to show students too. Duplicated code requires duplicated modifications, thus kills productivity. However, you went way farther than removing duplicated code.
To give myself as an example, I managed to parse your professor's code in a single go, without having to stop once. Leaving the duplication aside, it was really just this:
check if a parameter is set; get an action; execute it;
Yours however, had me stop and double check if the formatting was what I thought it was (it especially had me stop at parsing the multiline ternary), how function results are passed directly as parameters, how deep this nesting actually goes, and what gets -> execute()'d. Basically, I immediately marked it as a possible source of bugs or misunderstood behavior.
If there's anything that really kills productivity and any flow you might be finding yourself in, it's having to completely stop to understand a tiny piece of code.
You may be biased now because you wrote your golfed code a short while back and understand it perfectly. Come back to it a year from now, and I can guarantee it will make you stop, even for a few seconds, to carefully tell its true intentions (i.e. where it might fail, what gets returned and where, and what gets executed).
