User Tools
ch03-places-to-put-things
Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision | ||
|
ch03-places-to-put-things [2017/08/24 02:00] mithat [Syntactic sugar] |
ch03-places-to-put-things [2017/08/24 02:03] (current) mithat [Potential pitfalls] |
||
|---|---|---|---|
| Line 368: | Line 368: | ||
| int foo = 66; | int foo = 66; | ||
| </code> | </code> | ||
| - | The above statement declares an integer variable named ''%%foo%%'' and gives it an initial value of 66 in one statement. You can initialize any of Processing's primitive types this way---as long as the value on the right of the equals sign is compatible with the variable's type. | + | The above statement declares an integer variable named ''%%foo%%'' and gives it an initial value of 66 in one statement. You can initialize any of Processing's primitive types this way, as long as the value on the right of the equals sign is compatible with the variable's type. |
| - | If you try to access the value of a variable without initializing it or otherwise giving it a value, the Processing IDE will complain at you. This is because it is widely considered bad programming practice to rely on the default values given to variables by a language. The reason for this is that many languages do not specify //any// default values for variables---at least for some categories. In other words, the "default" value given to a variable you declare might be a random and/or arbitrary value.((The language on which Processing is built, Java, [[http://docs.oracle.com/javase/tutorial/java/nutsandbolts/datatypes.html|//does//]] specify default values for certain kinds of variables. However, the kinds of variables we have been using up to now and will use for most of this text do not fit into that category. | + | If you try to access the value of a variable without initializing it or otherwise giving it a value, the Processing IDE will complain at you. This is because it is widely considered bad programming practice to rely on the default values given to variables by a language. The reason for this is that many languages do not specify //any// default values for variables---at least for some categories. In other words, the "default" value given to a variable you declare might be a random and/or arbitrary value.((The language on which Processing is built, Java, //[[http://docs.oracle.com/javase/tutorial/java/nutsandbolts/datatypes.html|does]]// specify default values for certain kinds of variables. However, the kinds of variables we have been using up to now and will use for most of this text do not fit into that category. |
| )) | )) | ||
| Line 380: | Line 380: | ||
| char firstInitial, secondInitial; | char firstInitial, secondInitial; | ||
| </code> | </code> | ||
| - | declare two variables---''%%firstInitial%%'' and ''%%secondInitial%%''---which are both character types. Notice the comma between the two variable names. | + | declare two variables, ''%%firstInitial%%'' and ''%%secondInitial%%'', which are both character types. Notice the comma between the two variable names. |
| You can even combine variable initialization and multiple declaration in the same statement: | You can even combine variable initialization and multiple declaration in the same statement: | ||
| Line 389: | Line 389: | ||
| ==== Potential pitfalls ==== | ==== Potential pitfalls ==== | ||
| - | Syntactic sugar can be a tricky thing. On the one hand, syntactic sugar makes it easier to write your programs---it increases **writability**. When done right, it also makes programs easier to read--it increases **readability**. However, when a language has too much syntactic sugar, then the number of ways to express the same idea increases to such a level that it ends up making it //harder// to read--because the reader has to know all the intricacies of all the different possible ways of doing things. | + | Syntactic sugar can be a tricky thing. On the one hand, syntactic sugar makes it easier to write your programs---it increases **writability**. When done right, it also makes programs easier to read---it increases **readability**. However, when a language has too much syntactic sugar, then the number of ways to express the same idea increases to such a level that it ends up making it //harder// to read because the reader has to know all the intricacies of all the different possible ways of doing things. |
ch03-places-to-put-things.1503540043.txt.gz · Last modified: 2017/08/24 02:00 by mithat
Page Tools
