I would be cynical, I would say it is useless, just eating CPU cycles.
I am not, so I will say the performance hit is not visible, and somehow it has a documentation purpose (indicating the initial value). Could also have set the value at declaration time. But in both cases, it is not necessary because class fields (and thus Processing "global variables") are set to a default value: null for objects (including strings and arrays), 0 or 0.0 for numbers, false for booleans, etc.
Note that's not the case for local variables (declared in a block, including function definitions): the compiler will warn you against use of uninitialized variable usage.

If you're learning out of a book, a lot of times an author will use the same sketch over and over and add things to it along the way. The variable endY may have a different purpose later on, where you'll be initializing it to something else in the setup(), and so the author wants to keep things organized properly for the earlier stages. This may or may not be true, so take this comment in addition to what PhiLho said.

Let me also say this. Don't be too overly concerned with knowing the exact purpose of every little line of code when you're learning. You've obviously noticed that taking out that initialization in setup() doesn't affect your sketch. So that's part of learning right there, being observant on how things affect your sketch and not necessarily why things affect your sketch.

I used to try and learn programming languages by sitting down with a book and reading from cover to cover before I did any coding at all. I wanted to know everything there was about the language before I started coding. What a fool I was! This is the equivalent of trying to learn a foreign language by sitting down with a dictionary and just learning all the words. It's better to learn in context, kind of like learning a foreign language through immersion. You just get your feet wet, and figure out the details later. I'm experiencing this big time with the iPhone SDK right now. Objective-C is bizarre when you're coming from Java and C++, and it's a vast language, and it's really useless to try and learn all the details before you just start trying to make iPhone apps. Then as your needs change, you dig deeper to find the answer. It'll be the same with Processing. Sorry this is long-winded, but hope this helped in some way!

If you're looking for a good, practical C++ book, I highly recommend Beginning C++ Through Game Programming by Michael Dawson. He has you creating working games right from the beginning, so you're always programming for a reason, for some sort of interactivity, rather than just printing things out all the time about variable statuses.

Oh and I highly, highly, HIGHLY recommend OpenFrameworks for programming in C++. The developers really tried to make it just like Processing, and named a lot of the drawing and other methods the exact same as Processing, so it's super easy to go from one to the other. It's set up just like a Processing sketch, with setup() and draw() methods and all that. You should definitely check that out if you are into C++ using OpenGL.

There is something puzzling me about openFrameworks. The Web page hasn't much changed in ages, still mentioned "in pre-release, and heading towards a public release" and beside a bunch of videos, I see no real information.
So I wonder how people can even use it Is joining the mailing list the mandatory step to be in the secret

Lenticular wrote on Aug 21^st, 2009, 1:28pm:


From my experience Processing is a really good place to learn the ropes.  I'd done a lot of procedural coding in ActionScript, and before that web stuff using PHP and a little Python, but had never considered writing classes until I started working with Processing...  Now I've got my head round the concepts involved I'm comfortable writing classes in ActionScript and feel ready to apply the same principles in other languages... though TBH it will be hard to drag myself away from Processing given its versatility...