Worth refactoring 4 lines of code?


casperes1996

macrumors 68040
Jan 26, 2014
3,950
1,899
Horsens, Denmark
Code is a matter of judgement.

If a loop does not act as control logic, i.e. something dynamically changing that cannot be known at compile time, a loop is slower than inline code; That said, most compilers optimise this difference away by "unrolling" the loop anyway. - Loops however can make code easier to read. If you feel the looping variant is easier to read, use it, if not don't, unless you're having code duplication issues.
 
  • Like
Reactions: BootLoxes

BootLoxes

macrumors member
Original poster
Apr 15, 2019
72
21
I think your version is more flexible if you wanted to change the distance or other parameters in the future.

In general, anything that improves readability is worth a refactor IMO.
So do you think the change was worth it?
 

MEJHarrison

macrumors 65816
Feb 2, 2009
1,352
1,154
You're seeing alternate approaches to problems. That right there is reason to celebrate.

You're a beginner. Improving things, no matter how little, is exercising those programming muscles. Even when your improvements aren't actually improvements, you'll learn. Experimentation is exercising those muscles. So I say it was worth the change just for the learning experience if nothing else.

Now, as for the change itself. Personally, I prefer the first version. The first version makes it extremely clear what will happen. You move forward 4 squares, turn right, move two more, then turn right again. The second version works, but only when walk = 6. If walk was something else, like 12, it would go forward 4, turn, go 4 more, turn, go 4 more and then turn one last time. The is not the same behavior as the first version and I suspect not the desired behavior. So version 2 feels more fragile and prone to errors.

Beyond that, I'll agree that anything that makes the code more readable and understandable are valuable changes. I do this for a living. I've had extremely productive days where I've probably written 1 line of code the whole day. # of lines of code is a horrible metric to pay attention to. It doesn't matter if you change 4 lines or 400. The question is, are things better than when you started?
 

casperes1996

macrumors 68040
Jan 26, 2014
3,950
1,899
Horsens, Denmark
I'd like to add to MEJHarrison's excellent answer, by saying that "worth refactoring" also depends on the point of the project. This is a learning project so it's worth exploring and thinking about ideas, but the end result is throwaway code anyway. Strive for good solutions, but it doesn't need to be maintainable for decades.
I code differently if I'm making a quick one time script to change the way data is structured to use for something else, than if I'm coding a long-term project, like the Civilisation-Like game I'm working on these days.

For learning projects like this, absolutely consider various solutions and work to make your code the best it can be, but the ideas and thoughts are more important than what you end up leaving this specific code base at. In a few months you'll have developed many more new ideas about how you code anyway.
Even though it's a STEM subject, programming isn't so rigid with styling rules either. You might initially find that solution A is the best to solve your problem. Then when the project grows and evolves, you suddenly need three more parameters and you find that solution B is better, even though you initially decided against it.
In Swift Playgrounds like this, once you move to the next challenge, the previous code is probably pretty irrelevant. In a production environment where your codebase grows over time, your new code will interact with old code all the time, and whenever you do something that means you find a need to look at your old code, you have a chance to consider if the solution you picked then is still the best for the issue at hand.
I often start off with a class with a simple constructor taking a few arguments, suddenly it takes 6 arguments and I decide to make a Factory for it. I may start off hard-coding to a specification. Then the specification changes and it becomes a Strategy Pattern instead.

To quote a programming mantre; "I make horrible sins to make the code work... Then I clean it up and check that it still works" (from a book on Test Driven Development).

If you work in a larger codebase, there are also more factors to consider, such as "Is a similar problem solved elsewhere?" If so, your new implementation should do it the same way. That is, if it's identical, don't reimplement it. You want to avoid duplicated code. But similar things should be done in similar ways.
 
  • Like
Reactions: MEJHarrison

BootLoxes

macrumors member
Original poster
Apr 15, 2019
72
21
I see. I hope I can one day reach a point where I know whether a refactor is better or worse than before. Guess I have to keep grinding