Problem Solving

[PistAchiYo]

What do you think about before writing code for anything? What's your process?I need some tips :)

[wavic]

# get the web page
# give it to bs4 and make a soup

# for each element with this class selector
    # get the url to the page and open it
        # get the data
        # and print it

# write the sorted results to csv and json files on the disk

For example. The necessary steps for scraping a web site and get what you need. Then just write the corresponding code under every comment.

[ichabod801]

I tend to think in an object oriented way for larger projects. What are the objects I am going to need (cards, decks of cards, hands of card, players, and a game object to put it all together). What attributes do they need that other objects will need (card rank and suit, player name and score)? How will they need to interact (cards will need to fit into a deck, a deck will need to shuffle cards, and hand will need to draw and play cards, a player will need to make decisions).

The interaction planning is the most important in my experience. That's where you find out your plan doesn't work, and you need to rethink your objects, attributes, methods, and how they all relate to each other. Often you find this out while you are programming, but it's much easier to deal with in the planning stage, so planning is key.

And I use the method wavic posted to do all this. Planning out your code with comments and then filling in the comments with code is one of the best tools I ever learned in programming.

[Aurthor_King_of_the_Brittons]

Good afternoon. The following is a helpful document I got from school regarding problem solving. I referenced it many time when I started. I couldn't figure out how to attach a word document, so sorry for the lengthy response...

Problem-Solving Techniques for Programmers (Detailed)
1. To begin, step away from the computer. Start with a pencil and paper.
2. Understand the problem:
• Read the problem several times.
• Express the problem in your own words. Write this down. Make sketches if applicable.
• Clearly define the “requirements”. What determines that the problem is solved? Write this down in your own words.
3. Identify the given information:
• Some problems are presented with given values. Does this apply to this problem?
• If so, identify the given values and select variable names that will hold them in the program.
4. Identify user inputs needed:
• Many (not all) problems require inputs from the user. Are user inputs needed?
• If so, select and write down the prompt that the user will see for each input.
• Select and write down the variable name that will hold each input.
5. Identify the processing steps and any calculations that are needed:
• Are arithmetic calculations or formulas needed?
• If so, write down expressions for the formula(s) using the variable names chosen.
• Solve the problem manually with some sample numbers. Don’t know a formula? Google it.
• Does the program need to make any decisions?
• If so, write down the logic for each decision, using the variable names you have chosen.
• Does the program need to repeat the same processing steps multiple times?
• If so, consider using a loop and write down the steps that must be inside the loop.
• Do the requirements specify that you use/create one or more functions (in addition to the main function)?
• If so, determine precisely what task each function should do, or accomplish, and choose a function name that describes the task. Write down the function names you select.
• Does a specific function need data to perform its task?
• If so, select parameter names for the data and place them inside the parentheses of the function.
• Write down the processing steps and/or output steps that the function must perform, using the parameter names chosen above.
• Determine where in main each function should be called (executed).
6. Identify the required outputs:
• Usually, this can be determined by re-checking the requirements.
• Write down the outputs required. Include any formats required (such as currency or decimal places).
7. Sequence all of the above steps in the order that is required.
8. Now, turn to your computer and start the IDLE program, but keep the paper handy.
9. Write the pseudocode:
• Open a new window in IDLE script mode and enter the sequence from Step 7 as Python comments.
• Use plain English and the chosen variable names to describe the steps needed.
• Make sure all steps are sequenced in the proper order.
10. Create your program in Python syntax by referring to the pseudocode.
• Translate the pseudocode into Python statements.
• Edit the pseudocode as needed as you code the program.
• Add more comments as needed to clarify code.
11. Test and debug the program.
• Run the program several times with different inputs to be sure it works as required. Fix errors.
• Check the requirements again. Be sure that your program meets all requirements.
• Check your spelling. Spelling mistakes reflect poor attention to detail, and that will worry your customers.

[perfringo]

In theory I like the document posted by JTHillard. Really like. But.. it's like ten commandments in bible.

In reality I think that there are very few who had followed it fully. This is IMHO too intimidating for beginners; tasks/assingments/problems usually exist in digital form and printing them out would be crime against trees; and it contains some inconsistency as well:

1. To begin, step away from the computer. Start with a pencil and paper.
/.../
5./.../
/.../Don’t know a formula? Google it.
/.../
8. Now, turn to your computer

For pure practical reasons I like more derivatives of wavic approach, especially in case of beginner.

[buran]

I guess paper and pencil is more or less figure of speech nowadays. One can do it in a text processor software for example :-)
Or mentally if the problem ate hand is relatively limited in scope.
The @JTHilliard answers OP question nicely, covering more or less all bases. With the experience some of the steps will become redundant...
I would add that at some point (as the problems become more complex) you would need to research available tools, libraries, architectures, etc. that would make your life easier and eventually familiarize with the docs if you are going to use something new that you didn't use before

[ndc85430]

I start by writing a failing test. That is, I write an automated test (e.g. a unit test) that expresses, in code, what should happen in a scenario I want to implement. In so doing, I'm focused on one small part of the problem (i.e. a particular scenario) and think about things needed to make it work (like any input data, or system state). I then run the test to make sure it fails (which it should, because there isn't an implementation yet) and then write enough of an implementation to make it pass. Once it's passing, I perform any necessary refactoring (extracting methods, putting parts of the code in the right place, making sure names are as expressive as they should be).

This "red, green, refactor" cycle is known as test-driven development (TDD).