Mithat Konar (the wiki)

User Tools

Site Tools

You are here: Mithat Konar (the wiki) » Programming Fundamentals with Processing » Places to Put Things
programming_fundamentals_with_processing:ch03-places-to-put-things

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Next revision		Previous revision
Last revisionBoth sides next revision
programming_fundamentals_with_processing:ch03-places-to-put-things [2017/07/26 17:49] – created mithatprogramming_fundamentals_with_processing:ch03-places-to-put-things [2017/07/26 18:02] – [Processing's composite types] mithat
Line 16: Line 16:
 $a = b + 20$ $a = b + 20$
  
-If I asked you what the value of $a$ is, you would probably reply "fifty-three," and you'd be right. In the above, both $a$ and $b$ are variables--they are expected to hold numbers whose values can change. The fact that the values can change is a central feature of variables in both mathematics and programming.+If I asked you what the value of $a$ is, you would probably reply "fifty-three," and you'd be right. In the above, both $a$ and $b$ are variables---they are expected to hold numbers whose values can change. The fact that the values can change is a central feature of variables in both mathematics and programming.
  
 Let's now look at a Processing program that does what the mathematics example above does. Let's now look at a Processing program that does what the mathematics example above does.
  
-**program ''%%variables1.pde%%'':** +<file java variables1.pde>
- +
-<code java>+
 void setup () { void setup () {
   int a;   int a;
Line 30: Line 28:
   a = b + 20;   a = b + 20;
 } }
-</code>+</file> 
 The second part of the example probably makes sense to you. It's really just the mathematical expressions with semicolons tacked onto the ends. (Remember that the end of a statement in Processing must be marked with a semicolon.) But you might be confused about the lines that begin with ''%%int%%''. Those are there because in Processing, as well as many other languages, you must explicitly state that you intend to use a variables before you use it. In other words, Processing expects you to say, "Hey, I plan to use a variable named //<somename>//," before you use it. The statements The second part of the example probably makes sense to you. It's really just the mathematical expressions with semicolons tacked onto the ends. (Remember that the end of a statement in Processing must be marked with a semicolon.) But you might be confused about the lines that begin with ''%%int%%''. Those are there because in Processing, as well as many other languages, you must explicitly state that you intend to use a variables before you use it. In other words, Processing expects you to say, "Hey, I plan to use a variable named //<somename>//," before you use it. The statements
  
Line 37: Line 36:
 int b; int b;
 </code> </code>
-do exactly that--they are **variable declarations**. They tell the Processing compiler that you plan to use two variables, one named ''%%a%%'' and the other named ''%%b%%''.((Some programming languages automatically create new variables for you as soon as you use them. Processing isn't one of those.+do exactly that---they are **variable declarations**. They tell the Processing compiler that you plan to use two variables, one named ''%%a%%'' and the other named ''%%b%%''.((Some programming languages automatically create new variables for you as soon as you use them. Processing isn't one of those.
 )) ))
  
-Processing's rules for variable declarations say only that you must declare a variable before you use it. This means that you don't have to bundle all declarations together.((Some popular languages require that you declare all the variables you will use at the very start of the code block in which you will use them. Processing is more flexible on this issue. +Processing's rules for variable declarations say only that you must declare a variable before you use it. This means that you don't have to bundle all declarations together.((Some popular languages require that you declare all the variables you will use at the very start of the code block in which you will use them. Processing is more flexible on this issue.)) So, in the above example, you could have written:
-)) So, in the above example, you could have written:+
  
 <code java> <code java>
Line 50: Line 48:
 a = b + 20; a = b + 20;
 </code> </code>
 +
 as well. as well.
  
Line 73: Line 72:
 One way we can learn the value of a variable is to output it to the console as in the code below: One way we can learn the value of a variable is to output it to the console as in the code below:
  
-**program ''%%variables2.pde%%'':** +<file java variables2.pde>
- +
-<code java>+
 void setup () { void setup () {
   int a;   int a;
Line 86: Line 83:
   println(a);   println(a);
 } }
-</code>+</file>
 or, if you like, or, if you like,
  
-**program ''%%variables2a.pde%%'':** +<file java variables2a.pde>
- +
-<code java>+
 void setup () { void setup () {
   int a;   int a;
Line 104: Line 99:
   println(a);   println(a);
 } }
-</code>+</file>
 You can also use variables in places where Processing expects literal constants. Here's an example: You can also use variables in places where Processing expects literal constants. Here's an example:
  
-**program ''%%variables3.pde%%'':** +<file java variables3.pde>
- +
-<code java>+
 void setup () { void setup () {
   int a;   int a;
Line 119: Line 112:
   rect(0, 0, a, b);   rect(0, 0, a, b);
 } }
-</code>+</file>
 This will draw a rectangle whose upper left corner is at the origin of the canvas, whose width is the value of ''%%a%%'' (53 pixels) and whose height is the value of ''%%b%%'' (33 pixels). This example shows that we can use variables whose values might be the result of calculations based on other stuff to control how things are drawn. That should seem at least a little bit interesting. This will draw a rectangle whose upper left corner is at the origin of the canvas, whose width is the value of ''%%a%%'' (53 pixels) and whose height is the value of ''%%b%%'' (33 pixels). This example shows that we can use variables whose values might be the result of calculations based on other stuff to control how things are drawn. That should seem at least a little bit interesting.
  
Line 140: Line 133:
 Knowing these rules, we could rewrite ''%%variables3a.pde%%'' as follows: Knowing these rules, we could rewrite ''%%variables3a.pde%%'' as follows:
  
-**program ''%%variables3a.pde%%'':** +<file java variables3a.pde>
- +
-<code java>+
 void setup () { void setup () {
   int var_one;   int var_one;
Line 152: Line 143:
   rect(0, 0, var_two, var_one);   rect(0, 0, var_two, var_one);
 } }
-</code>+</file>
 or, or,
  
-**program ''%%variables3b.pde%%'':** +<file java variables3b.pde>
- +
-<code java>+
 void setup () { void setup () {
   int rec_width;   int rec_width;
Line 167: Line 156:
   rect(0, 0, rec_width, rec_height);   rect(0, 0, rec_width, rec_height);
 } }
-</code>+</file> 
 The only difference in the the three versions of the program is the names we have given to the variables; the programs are functionally identical. However, of the three versions a lot of programmers would probably prefer ''%%variables3b.pde%%'' because the variables' names actually describe what they are used for--they are **descriptive identifiers**. Using descriptive identifiers isn't a language rule--you are free to use descriptive identifiers or not. However, they make reading and understanding your code much easier. And the easier your code is to read, the easier it will be for someone (even you) to fix and expand it. The only difference in the the three versions of the program is the names we have given to the variables; the programs are functionally identical. However, of the three versions a lot of programmers would probably prefer ''%%variables3b.pde%%'' because the variables' names actually describe what they are used for--they are **descriptive identifiers**. Using descriptive identifiers isn't a language rule--you are free to use descriptive identifiers or not. However, they make reading and understanding your code much easier. And the easier your code is to read, the easier it will be for someone (even you) to fix and expand it.
  
 Closely related to this are **coding conventions**--mutually agreed upon standard practices for writing code. Coding conventions are not rules; rather they are standard practices that have emerged over time and/or have been agreed upon ahead of time by a team of programmers. A common coding convention for variable names in Processing is to use CamelCase (i.e., capitalizing the first letter of adjacent words) with the first letter of the first word in lower case. Rewriting the example we have been working with so far using the CamelCase convention would yield: Closely related to this are **coding conventions**--mutually agreed upon standard practices for writing code. Coding conventions are not rules; rather they are standard practices that have emerged over time and/or have been agreed upon ahead of time by a team of programmers. A common coding convention for variable names in Processing is to use CamelCase (i.e., capitalizing the first letter of adjacent words) with the first letter of the first word in lower case. Rewriting the example we have been working with so far using the CamelCase convention would yield:
  
-**program ''%%variables3c.pde%%'':** +<file java variables3c.pde>
- +
-<code java>+
 void setup () { void setup () {
   int recWidth;   int recWidth;
Line 184: Line 172:
   rect(0, 0, recWidth, recHeight);   rect(0, 0, recWidth, recHeight);
 } }
-</code> +</file> 
-An alternative convention (used in program ''%%variables3b.pde%%'') might be to use all lower case letters for variable names and use the underscore character to separate words. I personally prefer this to CamelCase because I think it's easier to read. However, CamelCase is the defacto standard with Processing and what I will use in the remainder of this text.+ 
 +An alternative convention (used in program ''%%variables3b.pde%%'') might be to use all lower case letters for variable names and use the underscore character to separate words. CamelCase is the defacto standard with Processing and what I will use in the remainder of this text.
  
 ===== Data types ===== ===== Data types =====
Line 324: Line 313:
  
  
----- +<WRAP center round box 80%>
 === Geek break: Why doesn't this stuff happen automatically? === === Geek break: Why doesn't this stuff happen automatically? ===
  
Line 335: Line 323:
  
 These might seem like small issues when you are just starting programming, but you quickly learn to appreciate them when your programs become longer and more complex. These might seem like small issues when you are just starting programming, but you quickly learn to appreciate them when your programs become longer and more complex.
 +</WRAP>
  
- 
----- 
  
 ===== Syntactic sugar ===== ===== Syntactic sugar =====
programming_fundamentals_with_processing/ch03-places-to-put-things.txt · Last modified: 2017/07/26 18:06 by mithat
Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki