Conversation
| `F` Avoid short or one letter variable names. It's not | ||
| `f` Avoid short or one letter variable names. It's not | ||
| descriptive and doesn't make it clear what the variable is | ||
| for.{' '} |
There was a problem hiding this comment.
I was unsure what these {' '} are for but I didn't see any effect in the rendered table.
| In Java, semi-colons `;` are similar to a period in a sentence. | ||
| It is what tells the compiler when a statement ends. | ||
| Java does not have what we call "significant whitespace". | ||
| That is, whitespace such as new lines, spaces, and indentation do not affect how your code is executed. |
There was a problem hiding this comment.
I thought this might add some clarification of why semicolons are necessary, but could also leave it out.
There was a problem hiding this comment.
This is slightly wrong; whitespace does affect code, but all whitespace is essentially treated as a single space (intmyVariable won't compile, but int myVariable will)
There was a problem hiding this comment.
A good rewording might be:
That is, all whitespace (such as new lines, spaces, and indentation) are treated as a single space, and adding more does not affect how your code is executed.
EdanThomton
left a comment
There was a problem hiding this comment.
A few grammar mistakes, consistency changes, and wording changes + a few comments on stuff
|
|
||
| Variables are containers that are used to store information in a program. | ||
| This could be a variable that holds the temperature or a variable that holds the speed of the motor. | ||
| A variable might hold the temperature or it might hold the speed of the motor. |
There was a problem hiding this comment.
| A variable might hold the temperature or it might hold the speed of the motor. | |
| A variable might hold the temperature, the speed of the motor, or any other information the program might need. |
Not needed, but this reads better IMO
| `int` only allows numbers without decimals. | ||
| Example: `12` | ||
| - `double`: Numbers that are positive or negative. | ||
| Unlike `int`, `double` allows decimals. |
There was a problem hiding this comment.
| Unlike `int`, `double` allows decimals. | |
| Unlike `int`, `double` allows decimal numbers. |
| - `int`: Integer numbers that are positive or negative. | ||
| `int` only allows numbers without decimals. | ||
| Example: `12` | ||
| - `double`: Numbers that are positive or negative. |
There was a problem hiding this comment.
| - `double`: Numbers that are positive or negative. | |
| - `double`: Real numbers that are positive or negative. |
|
|
||
| When programming a robot, camel case is commonly used for creating variables. | ||
| Upper snake case is used for constants which are variables that are defined once and are not changed. | ||
| Upper snake case is used for constants, which are variables that are defined once and are not changed. |
There was a problem hiding this comment.
| Upper snake case is used for constants, which are variables that are defined once and are not changed. | |
| Upper snake case is used for constants, which are variables that never change once they're defined. |
reads better IMO
| For example: MotorID is different from motorID. | ||
| Even though it’s spelled the same, if your variable name is MotorID then you try to reference it again but spell it as motorID, Java will see the two as different, and your code will get an error. | ||
| For example: `MotorID` is different from `motorID`. | ||
| Even though it’s spelled the same, if your variable name is `MotorID` then you try to reference it but spell it as `motorID`, Java will see the two as different, and the compiler will throw an error. |
There was a problem hiding this comment.
| Even though it’s spelled the same, if your variable name is `MotorID` then you try to reference it but spell it as `motorID`, Java will see the two as different, and the compiler will throw an error. | |
| Even though it’s spelled the same, if your variable name is `MotorID` and you try to reference it as `motorID`, Java will see the two as different, and the compiler will throw an error. |
| Writing comments can also help you! | ||
| Leaving comments that explain what code does can be helpful when trying to understand what your code does and when debugging. | ||
| When programming, we use comments to document, or explain what the code does. | ||
| This helps others make sense of the code's intent. |
There was a problem hiding this comment.
| This helps others make sense of the code's intent. | |
| This helps others understand the code's intent. |
|
|
||
| Single line comments begin with `//` and mark the rest of the line as being a comment. | ||
| For example, the code below leaves the note of "This prints out Hello World." preceding the print statement | ||
| For example, the code below is documented as to what it achieves. |
There was a problem hiding this comment.
| For example, the code below is documented as to what it achieves. | |
| For example, the code below has a comment explaining what it does. |
| ``` | ||
|
|
||
| You will also see comments placed at the end of a line like the following | ||
| You might also see documenting comments placed at the end of a line |
There was a problem hiding this comment.
| You might also see documenting comments placed at the end of a line | |
| You might also see comments placed at the end of a line |
I don't think "documenting" is needed here, as it's generally implied that all comments should be documenting something
| ### Multi-line Comments | ||
|
|
||
| Multi-line Comments start with `/*` and end with `*/` The text or code that is in between the two will turn into comments. | ||
| Multi-line Comments start with `/*` and end with `*/` The text or code that is in between the two will be treated as comments. |
There was a problem hiding this comment.
| Multi-line Comments start with `/*` and end with `*/` The text or code that is in between the two will be treated as comments. | |
| Multi-line Comments start with `/*` and end with `*/` The text or code that is in between the two is a comment. |
| Multi-line Comments start with `/*` and end with `*/` The text or code that is in between the two will turn into comments. | ||
| Multi-line Comments start with `/*` and end with `*/` The text or code that is in between the two will be treated as comments. | ||
| Multi-line Comments are commonly used when you have many lines of text or need to turn a large amount of code into a comment. | ||
| For example, this is a comment with two lines of text. |
There was a problem hiding this comment.
I think it might be better to keep this line for consistency with other examples (see the one right below it)
Description
What changed?
Rewording/grammar changes.
Why? (the code + comments should speak for itself on the "how")
Proofreading
Meta
Merge checklist: