Neat Coding

Green blocks show indentation, the red lines show skeleton code that
Delphi creates for you when you start coding for a new procedure in the
event handler.

When you are coding, particularly if your program is complicated or makes use of many if and case statements, it is vital that you are able to read your code quickly and easily. Understanding what you are typing through neat coding means that you can code faster and that others will be able to help you if there is a mistake in what you have typed.

The most important thing to remember when keeping your code neat, is proper indentation (<Tab> key). The green on the picture to the left shows indentation. It is easiest to understand if the only text that touches the grey line is the skeleton code that Delphi gives you, the Procedure, Begin and End code.

Assigning of values to you variables and all basic processing and output should be indented once, and everything that goes below the first line of an if or case statement should be indented once more. The begins and ends of an if statement should line up, as should the then and else sections, as shown below.
The next way to make your code easy to understand is to use comments (//) and line-breaks (<Enter> key). Put comments above each different section of your code and separate these sections with line-breaks: The assigning of values to variables, resetting everything on the form, initialising variables, your processing and your outputting. Also place comments above each piece of more complex processing, such as case statements. It can also be helpful to place a comment on the same line as each begin and end (after the end, use "//" and say what piece of code the end is for).

If statement where begin and end are indented to the same degree, as well as then and else indented to the
same degree. This makes it easier to follow normal and nested if statements.

Another aspect to neat code is spacing, capital letters variable naming. Look at the if statement above, between the operator and the variables (iSecondsPassed  >  iSeconds) there is spacing, this makes it easier to read. Between the variable and the divide sign, there is another space. This again makes it easier to read, particularly if you have a long mathematical equation that you are using.
Capital letters help keep your code legible when you have a variable or component with multiple words in the name, putting a capital letter at the beginning of each word makes it that little bit easier to read. Also when converting data types, Such as with StrToInt or FloatToStrF it is easier to read and see what you are converting if there are capital letters.
When naming variables, use your capital letters, and give them names that make sense to you. Give the variables names that describe their function and what is held by them. Use a small letter in front of the variable to denote what type of variable it is. For example put a small r in front of a Real variable or an s in front of a string.

Finally, if you have many extra numbers in your code, such as 30 for the number of seconds or 0.14 for VAT, don't simply leave these as numbers in your code, as they will seem arbitrary if you need to look at the code later. Declare these as constants between Procedure and Begin and give them values there.

Thank-you for reading and remember that neat code is the only code that you can understand more than a month later.

Naming Your Components

A structure tree showing organised
components.

This is a point that cannot be emphasised enough. In order to understand your own code and form layout, you must have a good idea of what everything is, where it is and what it does. 

The first step to making your code easier is using the basic naming convention in which each component gets a 3 letter name followed by a description. For instance Label = lbl; edit = edt; panel = pnl; checkbox = cbx; radiogroup = rgp; button = btn; timer = tmr; bitMapButton = bmb et cetera.
The description will normally be along the lines of input, output or explaining which input or output where necessary.
This alone makes it easier for you to code and for someone else to help you if you are unable to spot your error.

To truly make a difference in a complex program with many components though, you naming system needs more than just a basic description and 3-letter code, in a complex program it is often useful to know where the component is and to group components accordingly, this is made easier using components like panels and groupboxes, which will add a "branch" to your structure tree (you can see a structure tree on the left, each new colour shows a new level where it "branches" off). You can also simplify what you look at in your structure tree if you have panels and groupboxes by minimising the panel or groupbox. You can see on the left how all the components in panels under tabsheet 2 (2 {tbs2}) are hidden and how all the panels and their components are hidden in tabsheet 3 (3{tbs3}).

As previously stated, sometimes the component description will need more than "input" or "output". Often you will have multiple labels or edits that all serve different functions, and it is useful to give them names that describe exactly what these functions are. If you look at the labels on the left for frmMathLogic -> pgctrl -> 1{tbs1} -> pnl_pg1_Results you see that there are two result labels, One for the number entered and one for whether or not the number is real, differentiating between the two in the name of the label allows you to code faster and more easily as you will not get confused and thus not have to check your form.

It is also important to make your code easy to read and recognise, meaning that your component names have to be easy to read and recognise, stick to one convention for all components of a certain type or location in all your forms ( for example, don't use "output" in one program and then "result" in the next ), and use capital letters and underscore signs ( _ ) where you feel necessary.

When you combine proper naming of components with other useful tips and functions in and for Delphi, you can code a lot faster and more easily. You can understand your code at a glance and can get help if you go wrong as anyone can understand your code if it is neat and self-explanatory.

Thank-you for reading and I hope this proves helpful.

A Few More Things

After that rather odd introduction, I just need to add a few more things:

-1: Sorry about the background pushing around the edges of the page, if that is happening to you. I tried, Blogger even said 1800p would be wide enough... ah well.

-2: I will not necessarily be posting to a rigid schedule, if any at all. I will post if it is requested, when I feel I need to, and when I am bored.

-3: If I offend anyone in any way, sorry, but you do choose to read this, and I will not necessarily edit my post or pull back my comment. 

-4: Yes, it is Blogger. What? Don't look at me like that. I am honestly just too lazy to even go find anything else. And Blogger is convenient, I don't have to know any more than <img></img> to get what I want out of it. 

Thank-you, and I hope this helps to at the very least make your programs / sense of humour shinier.

Wow... Finally... The Introduction

As far as things that are overdue are concerned, this post serves as a role-model to the rebellious masses that have terrible role-models. I think I began designing this thing weeks ago. First there was that design... you know... the dark, horrifically contrasting, eye-bleedingly annoying to look at... thing that had a colour scheme worse than clown puke. Then eventually it got to this, not great, but you can read it without your head spontaneously exploding.

Now that that is out of the way, hello. I guess I had to get to, you know, the introduction some time in the introductory post...
So here it is, Delphi Newbie, probably 1 of the only 3 comprehensible blog names not yet devoured by the masses of people using this thing. The idea behind this, if it doesn't fail horrifically and lead to my dead body hanging limply from a broken window 5 stories up, is to help some people in my IT class with Delphi coding. I also intend to throw a little bit of Image editing (limited knowledge is still something useful...) to those willing to read it.

If you want details, fine, I am Brandon, not that the bar at the bottom of the blog wouldn't tell you that. If you want to criticise, be constructive about it please, if you have anything to add, I will listen and may include it in the posts.

So thank-you all, hope this doesn't lead to my bloody end, enjoy and name your components.