Am I doing this right? Do the ends justify the means?
Posted by Fit_Bed_3008@reddit | learnprogramming | View on Reddit | 10 comments
Heyy! I'm doing the MOOC programming course so I'm just a beginner but I have a question.
I just want to know how "simple" I should make my code. Because often I make the hardest most complicated way to the solution of a problem, my outcomes are correct but I keep thinking if the ends justify the means... Maybe in the long run this will make it harder for me if I don't fix this now, and if so how do I fix this?
For example:
I had this exercise;
Please write a program which asks the user to type in a number. The program then prints out the positive integers between 1 and the number itself, alternating between the two ends of the range as in the examples below.
Sample output
Please type in a number: 5
1
5
2
4
3
My answer was this
number = int(input("Please type in a number:"))
x = 1
y = number
while x <= ((number+1)//2):
print (x)
if x != y:
print (y)
x += 1
y -= 1
The model answer this
number = int(input("Please type in a number: "))
left = 1
right = number
while left < right:
print(left)
print(right)
left += 1
right -= 1
if left == right:
print(left)
I think the model answer is a lot easier to understand and is more bug-proof than mine.
Should I focus more on finding easier solutions for in the long run. Or am I overthinking this and should I just do what works for me and after some practice I'll make simpler solutions anyway.
FloydATC@reddit
I would say the most important thing is that you understand the code and why it works. Think of it as if you were making a chair; the most important thing is that you can sit on it.
Starting with that, the difference is in how you proceed. Unless you're happy with forever churning out code/chairs that only just meet the most basic requirement, you should revisit the code and see how you can make it better, shorter, more efficient, easier to read etc. without sacrificing the most basic requirement: That it works. The amount of work you're willing and able to put into it at this point is the difference between code/chairs that barely qualify and code/chairs you would gladly show off to others.
The most important thing though, is that you remain the one in control. The objective of the task was never about counting, it was about the thought process.
Even after decades of programming, my very first solution to a problem I never encountered before always looks like the hairy mess you pull out of a clogged sink. Pulling it apart and turning it into readable, testable, presentable and ultimately re-usable code is the real challenge.
Suspicious_Coat3244@reddit
In fact your solution is absolutely acceptable for a novice. The crucial thing is that you get the right solution and it makes sense when you read it.
It's good that you already realized that the model answer feels more neat. That's a good instinct. Becoming a better programmer consists mostly of learning to reduce unnecessary complexity over time once you have a working solution.
Most people actually write the "more difficult" version and then, through experience, develop a sense for simplification and patterns that simplify the code naturally. That's how things are done.
What's dangerous is not occasionally writing more complex code, but not critically examining it later on. You are already critically examining the code, which is a very good sign.
WellHung67@reddit
Code is read 10x more than it’s written. Even code you write yourself is read by you personally much more than you write it. Written once, read forever.
Always write code that is simple and readable which in turn makes it maintainable, and prefer this over anything else. So yeah your answer works but it’s overly complicated. It is a bad habit due to the read vs write thing. Also, complicated code makes it harder to spot bugs - most people can hold at most 7 pieces of context in their head. So if some of that is deciphering complexity that’s not needed, it becomes harder to see other things. Sometimes complexity is unavoidable of course, but defer to Feynman here. Make it as simple as possible, but no simpler
Ormek_II@reddit
There is no big difference between the solutions.
They increment first, you print first.
They call them left and right, you x and y.
Noticable: difference in abort condition. I would need more energy to figure out if yours is always correct and never stops too early or too late.
You are fine how you proceed. Make your own review after looking at the solution: what did they do different? Do I consider mine or their way “better” and why? Only if you find you solution cumbersome, put the example solution away and modify your code into the other algorithm.
If the spellchecker tells me I misspelled a difficult word, I do not just let it fix it, but type the correct letter sequence. Of you should never just memorize code as you would spelling. If it was a simple word, that I know and just made a typo, I let it go its way.
Whatever801@reddit
Your solution is fine but definitely the simpler and more readable to another person the better. Think to yourself "would someone else find this understandable without having to think too hard?". As a software engineer a huge portion of your time goes to maintaining and improving the code that you and other people have already written. I can't tell you how many times I was looking at code and said "who wrote this shit?". Turns out it was me 5 years ago 😂😂😂
smichaele@reddit
You're just starting out. You shouldn't worry at this point about coming up with the most efficient or optimal solution. It's enough at this point that you can come up with a method to solve the problem. As you learn more and read more code, you'll start naturally changing how you think about and structure your code.
ffrkAnonymous@reddit
All of the above.
For example. Sort a bunch of numbers. You can bubble sort, quick sort, etc.
Or you can do a simplest
sort(). But then you didn't actually learn anything.amazing_rando@reddit
Poorly designed code that works is considered “technical debt.” It’s called debt because you, or someone else on your team, will need to spend time to fix it in the future if you ever need to modify it in any way. Sometimes this is unavoidable, but as long as you have the time, it is useful to spend it making your code as clear as possible. This is obviously a relatively trivial example, but the whole point of practicing these problem is to build good skills and habits that you can bring to more complex problems in the future.
shinyblots@reddit
This is also touching on a data structures and algorithms concept known as two pointer. The way the model writes it makes it clearer that you use two points and work your way to the middle by decrementing the right side and incrementing the left side then checking when they overlap.
The general way to go about learning DSA like things is solve the problem your own way most likely you'll be doing a brute force method but then you look up and learn the "optimal solution" then commit the intuitions, methods and tools that lead you there to memory so that if you encounter this same problem pattern again you have an idea of what to do. It would be imo better if you kept this in mind going forward.
zugzwangister@reddit
Make it more like the model.
The easier it is to explain, the better it is.