Approach to coding, good/bad

[teenspirit]

IT's kind of a double edged sword, because when you code like that, you get fast results on small functions and projects, but big projects you run into problems down the line. My current project, the food distribution logistics program i am working on with quite a bit of community help, i started with an idea of what needed accomplished, wrote down some goals and necessary items, then i dove right in after not touching python for about a year and a half. I had definitely forgotten more than i thought, not to mention i wasnt all that great a year and a half ago. So now i have basic input and some of the output i need, but the actual problem itself isnt solved. I thought i could figure out how to do the final step on the fly, but now i think i might have made a big mistake. I cant quite solve my final problem, and now a solution may require rewriting lots of the current program. So you should always set out at least a list of goals, but you should probably learn to work from the inside out, get the processing done first with stand invariables instead of inputs and interaction, then develop the interaction up to the UI. I really have appreciated all the community help on my project, and i am taking a couple courses to brush up my python skills before i keep charging forward.

[Larz60+]

So you should always set out at least a list of goals

I think you missed the point of the overall thread.

This thread advocates having a very good and complete overall plan.
Details are often trial and error, but only for small unproven parts.
The folks of this forum are professionals and have been involved in some huge
successful projects, many for billion dollar companies, and or governments.

So even though a few of the posts say no planning here, the overall concensus is
that a planning is most important

What I am saying is that the thread agrees with you.

[volcano63]

So you should always set out at least a list of goals

I think you missed the point of the overall thread.

This thread advocates having a very good and complete overall plan.

oh, the days of Pearly Spencer, sorry - waterfall
Didn't it work well   . 
But of course it's a folly to write "quick and dirty" - and then redoing it. I try to start writing proper code from the start - including some rudiment comments. Occasionally it turns right 

But you make - and fix - mistakes. As you go, you realize that things don't work exactly as you planned. Then someone tells you that you misunderstood the requirements - or they were wrong. Then someone changes requirements.
But the cleaner the initial code was - the easier refactoring will be (about a year ago - commit of 400 changed lines  in 2 days).
It is important to keep in mind have to understand that occasionally even project developer - when visiting his/her own old code - will have to spend some time to figure out what the hell were the intentions. 
So, again - the cleaner is the code from the start, the easier life will be in the long run

---

PS Several times in my career as QA Automation Developer I was preached by my managers that they don't care about performance, code quality - I must quickly supply solutions to the problems that the management piles on me. And they did not understand that those solutions eventually turn into problems

[Ofnuts]

will have to spend some time to figure out what the hell were the intentions

Which is what comments are for (if the code is well written they are unnecessary to understand how it works).

[volcano63]

(if the code is well written they are unnecessary to understand how it works).

Depends on the complexity of the implemented algorithm. I like KISS as any other guy   but occasionally you have to implement something non-trivial....

[Ofnuts]

(if the code is well written they are unnecessary to understand how it works).

Depends on the complexity of the implemented algorithm. I like KISS as any other guy but occasionally you have to implement something non-trivial....

Implementing the algorithm is the intent of the code...

[volcano63]

Implementing the algorithm is the intent of the code...

No shit ? Any more words of wisdom?

[sparkz_alot]

Language please.  Remember we are a public forum with young members and viewers.

[ichabod801]

Which is what comments are for (if the code is well written they are unnecessary to understand how it works).

Common sense is not common, and intuition is not intuitive. Always comment your code.

[ndc85430]

Get into the habit of writing tests. For one, they give you safety. If you're testing manually, you have the problem of making changes and not really knowing whether you've broken anything else in doing so until you run the application. If you write tests, you can run them after making the changes and find and fix any breakages before running the application. Clearly, when developing software for use in the real world that's very important and I think it's useful to gain those skills. Python comes with a unit testing module (unittest) and Kent Beck's "Test Driven Development: By Example" is a good intro book on writing tests first (the examples in the first part are in Java, mind). Working in a test driven manner also helps you to focus on small chunks of the application at a time, rather than having to keep everything in mind at once.

I'm not a big fan of commenting code, because the only thing that tells you what the code does is the code itself (and the tests, of course!) - comments can be misleading (e.g. if they're out of date) and extra noise (I've seen lots of commented out code just left there in projects I've worked on). I much prefer code to be written in a way that makes the intent clear - by using good names and breaking things down into small pieces (like nice, small functions).