Vent longitude has anxiety

In some languages, there is a "do" loop. This is how a do loop looks:

Code:

do
  //code goes here//
loop

The "do" starts the loop, and the "loop" tells it to go back to "do". This loop repeats infinitely. As soon as it begins, unless there is an instruction inside the loop that causes it to actually jump out of the loop, which is often considered bad form, or stop executing the program entirely, the code inside the loop will repeat forever. (Or until you forcibly close the program or restart the computer. But consider that your operating system can be abstractly understood as an eternal loop, because you don't want the operating system to decide it's finished now and stop doing its thing unless you're shutting down your machine. Depending on what language you're using, a game you write may have an eternal loop as its main body. It might check to see if there is player input, process it if there is, and may even have a bit that says "hey operating system, you can take care of any business you may have right now without causing disruption to anything time-sensitive, then pass the control back to me", and it will repeat these steps forever, or until the player exits the game.)

There are two subtypes of do loops for when you don't actually want to loop forever. There is "do while" and "do until". Only "do while" is relevant here. You don't actually need both to have a complete programming language, and many languages omit "until" loops completely. We'll ignore them.

The "do while" loop looks like this:

Code:

do while (some condition is met)
   //code goes here//
loop

This works exactly the same as a your regular "do" loop, except it has a built-in test to limit eternal looping. Before it decides to "do", it tests whether it should do the loop at all. If so, every time "loop" sends it back to "do", it will test again. If it decides at any point not to "do", it will skip to whatever comes after "loop".

A "while" loop is still the same thing as a "do while" loop even if you haven't written out "do" or "loop". It may help to think of it that way, if only because it attaches the somewhat confusing term "while" to something a bit more concrete. Depending on your language, the beginning and end of a loop may be annotated in many different ways, but the idea of "do" and "loop" will always be there in some way. The computer needs to know where a loop starts, when it should jump back to the beginning, and how to decide if it should execute the code inside the loop at all or if it's done and can move on.

Do operating system while (user has not selected "shut down"). [Operating system goes here.] Loop.
Do game menu while (user has not chosen if they want to load a game, start a new game, or exit). [Game menu code goes here.] Loop.

 

I agree with @Verily and want to add that a "do loop" (which I've seen called an infinite while loop) is logically equivalent to a "do while" loop with the condition "while two plus two is equal to four" or "while true".

Although, honestly, if you need to write an actual program, you're... mostly going to be looking at things above the level of loops, ime? A loop is just "do this list of steps more than once," and how many times to repeat the list of steps is probably less important than things like when to even start repeating the list of steps and which steps to include.

I'm not saying loops aren't important, they absolutely are, but typically in my experience you want to start by testing out a version of the program that does something once and then look into getting it to do the thing the right number of times, and what other things to do and when, and how to respond to user input, and so on and so forth.

How you'll interact with loops actually depends quite a bit on whether you're doing GUI programming -- when you run your program, are there supposed to be visible bits and bobs and buttons to press (GUI), or just a box that displays text and that you can type into (console)?

 

A method is much more abstract than a while loop. It's part of object oriented programming. Trying not to get too bogged down in the details, someone has written some code to create an object. Their code is called a class. A class of furniture, that creates objects such as desks and chairs and so forth. A class of quadrilaterals that creates rectangles and squares, which are subclasses. The class is the category, the object is the square or the chair. An object is a thing. A class is the instructions for making and using that type of thing.

A large part of the reason for object oriented programming is to make it easier for many people to write code for the same project without having to worry so much about whether it's going to clash horribly. You don't want to have to know about all the code inside the class. You just need to be able to use the class to create objects, and to make the objects do things.

The person who has written the class has defined what the objects do and how you can request that they do it. Those are called methods. A method is something the object can do. It has code for that. The method has a name so that you can tell it what action you want an object to do. You don't need to know what the code says exactly, just what it can do and how to ask it to do that action. You call an object's method to tell an object to do an action, and it takes care of the "how" using the code of its class.