Python Forum
Approach to coding, good/bad
Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Approach to coding, good/bad
#1
Hello all,
this question is about coding generally. But if the answer might contain someting Python-specific, do point it out.

I noticed that with coding, I tend to take the approach:
  • write all the code for what the program should do, the way it feels most right/correct
  • execute it and correct/modify it step by step, as the execution hits (numerous) errors
What do you as experienced coders think of that? It kind of works for me and brings success so far. But at the same time it feels like quite an immature strategy, which could just be my comfort zone. Does it need (minor) improvements? Should I change the approach completely? Is there a logical next step in the process of learning to code?
Thanks for comments!
Reply
#2
I'm not an experienced coder, but I pretty much follow the same strategy.  Initially, I will write my code without regard to making it 'pythonic'.  My overriding goal is that it works.  Afterwards I will try to 'break' it, then do my best to correct those problems. Finally, I will work on refining the code.  For me, the last part is the hardest as it usually involves considerable time with my nose stuck in the doc's.  As I learn more, though, I notice that step one and step three are slowly merging
If it ain't broke, I just haven't gotten to it yet.
OS: Windows 10, openSuse 42.3, freeBSD 11, Raspian "Stretch"
Python 3.6.5, IDE: PyCharm 2018 Community Edition
Reply
#3
I think that's fine for small things, but will cause problems for large or novel projects. I wouldn't say you necessarily should change what you're doing, but you might find at some point that you've painted yourself into a corner because of a lack of foresight. You can imagine two options - (1) always consider carefully and it rarely matter or (2) never consider and at some point it bites you. "Experienced" programmers probably have heuristics that allow for a middleground which, while not perfect, is (slightly) less frustrating.

It can also depend on what you're working. If your work is constantly boring, you might be more in the mode of not worrying about it.

And one last thing - whether you think ahead or not, I'm definitely a fan of "get it working first" so while I do try to write Pythonic code the first time, you don't want to re-write as you go if you end up having to make big changes just to get it working.
Reply
#4
When I usually start out with an idea, I go through the following iterations
Keep in mind that I usually don't have a real clear concept of all of the inputs and outputs.
  • Start writing code, my spec at this point is probably written on a napkin
  • Build a vague framework of what i (think) I want, this in three 4 stages:
  • Input sources and structure
  • Output I am aiming for
  • Process needed to take the input and from that create the output
  • Presentation of results portion (report, GUI, etc.)
  • ... Examine results ...
  • Sit down and write a pseudo formal specification
  • Start over
I go through this process several times until I have a polished application (and am satisfied with the results)
Reply
#5
My coding approach is a more or less the "inside-out" one. I try to split the problem into manageable parts, then write these parts with functions that I try to keep small and focused. Since most of my professional coding is server code that's hard to debug on the fly, I test my functions very throughly on the side before adding them to the code (I'll often write as much "test" code as "production" code). I'll even change the design to isolate the "hard" parts in pre-testable functions. Once all this is working I put the bricks together with some glue code to make the final application.

I do like the current trend of starting by writing the (automated) tests, then writing the app is just debugging an empty source file (or source code repository).
Unless noted otherwise, code in my posts should be understood as "coding suggestions", and its use may require more neurones than the two necessary for Ctrl-C/Ctrl-V.
Your one-stop place for all your GIMP needs: gimp-forum.net
Reply
#6
I'm with Micseydel. Small things, I will just run off quickly. The bigger the project is, the more effort I put in to up front planning and design. The big project I'm currently doing I tried doing without planning, and it just turned into a horrible nightmare of a mess. I ended up scrapping the whole thing and starting over with a detailed plan. And now, in the midst of it, I'm finding that even the detailed plan wasn't good enough. I've been having to make significant changes mid-stride. Thankfully, I also had a clear implementation plan. So the problems I'm having to deal with are coming when I have a minimum of code to deal with, which makes them a lot easier to deal with.
Craig "Ichabod" O'Brien - xenomind.com
I wish you happiness.
Recommended Tutorials: BBCode, functions, classes, text adventures
Reply
#7
(Mar-22-2017, 09:22 PM)ichabod801 Wrote: I'm with Micseydel. Small things, I will just run off quickly.
Small things are better occasions to learn new tricks than big projects.
Unless noted otherwise, code in my posts should be understood as "coding suggestions", and its use may require more neurones than the two necessary for Ctrl-C/Ctrl-V.
Your one-stop place for all your GIMP needs: gimp-forum.net
Reply
#8
That depends almost entirely on how good your refactoring tools are :p
Reply
#9
In my approach, the first part is proof of concept.
After testing the waters, I too, created extensive documentation
and of course had design meetings. In the end we built huge systems
including Call record processing systems for a very large telecommunications
company.

I can't imagine doing it without.
Reply
#10
If you want to build a shack you just do it. No planning, no blueprints, no geological research and environmental assessment. But if you want to build a plant or 160 floors high scrape you can't do it without all these steps and more.

I am not a programmer and do not have a noticeable experience but we have this proverb: measure three times, cut once.
"As they say in Mexico 'dosvidaniya'. That makes two vidaniyas."
https://freedns.afraid.org
Reply


Possibly Related Threads…
Thread Author Replies Views Last Post
  How to approach pyusb application arch m3atwad151 0 705 Nov-10-2022, 06:11 AM
Last Post: m3atwad151

Forum Jump:

User Panel Messages

Announcements
Announcement #1 8/1/2020
Announcement #2 8/2/2020
Announcement #3 8/6/2020