In addition to comments in h.t. email we can also insert comments in our pitch P cold.
We have two ways to insert comments in P HP.
The first is a one line comment using two slashes.
Everything from the two slashes to the end of the line is a comment.
So you can use it to add a comment on its own line like this.
Or add a comment to an existing line like this.
Again most editors will help you to see what's a comment by colouring it differently.
Unlike X term l p s p comments and not sent to the browser.
This is because they're part of the p h p code and as we learnt earlier all p s p code is executed before
the results are sent to the browser.
So you don't need to worry about any comments in your pitch peacoat being visible if the user views
the source in the browser.
The second way to insert comments is to use a slash and an asterisk to start a comment and an asterisk
and the slash to end a comment.
The difference with this style of comments is that they can span more than one line.
Like this.
Now while it's a good idea to add comments to your code it's only necessary if it's not obvious what
the cold is already doing.
For example these comments I've added aren't needed a Tal as it's clear from the code what's happening.
That's why it's a good idea to give you variables meaningful names.
We'll see some examples later on.
Of how comments and necessary to make our code more readable.
As far lay out just like in eight to AML you should use white space wherever possible to help improve
readability.
For example on this line we're creating a variable that contains an array.
We could do it like this but without the spaces that is more difficult to read.
It looks much clearer like this.
You should put spaces tabs and newlines in your code wherever you think it makes the code easier to
understand.
It doesn't make any difference how the code executes but it does make a difference when you want to
try and understand the code later on.
Unlike Gates to mail P HP hasson recommended coding standards for how PE HP code should be written.
The lowest level kalid psa one describes some basic coding standards.
For example avoiding the use of the schadt p-h Pete opening tags that we saw earlier and some naming
standards far various elements of p p which will see later the second level called p s out to extend
this with recommendations such as how many spaces to use for indenting code opening braces for control
structures and so on.
There are further levels but complying with PSA 2 is the most common.
Following these guidelines will make your code easier to read and maintain by other programmers and
by being used to these standards you'll be able to read other people's code more easily to your no doubt
be using someone else's cold in the future.
So if you get used to writing clean easy to read code now it will save you a lot of time.
As with s amount there are online tools like this one that will fix your code for you so it conforms
to p s add to standards.
There's also this p p coding standards.
Fix a program that you can download and run on your code and it will fix it so that it conforms to the
PSA to coding standards.
There are several different ways to install it but the easiest is to download the file.
Then on the command line of terminal you can run the program.
Passing it the P 8 p script file name and when you run it it will refilm at your code so it complies
with the piercer to standard.
However if you're familiar with the coding standards you can use them as you write your code instead
of having to run this afterwards although it doesn't hurt to run it if you like.
While the cold shown on this course complies with the PSAT coding standard.
So you shouldn't have to worry about running this program on it.