Walking backwards in Arrays
Three main ways to do this, take your pick.
for ( int n = max; n>0; )
A[--n];
for ( int n = max-1; n>=0; n-- )
A[n];
for ( int n = max; --n>0; )
A[n];
Joel Anderson
Filler
Keep your code short and your patience long.
The larger your program is, the more maintenance required. It’s best to reuse code as much as possible because this will reduce maintenance/debugging time. Sometimes optimisations mean breaking this rule, but remember that only the critical/timely parts of the program need to be optimised.
Joel Anderson
D arrays can be sorted
int[] A;
...
A.sort;
Joel Anderson
D arrays can be resized on the fly
int[] A;
...
A.length++;
Joel Anderson
Comparing arrays
D allows you to quickly compare arrays with “==”.
int[] A;
int[] B;
...
if (A == B) //Then both are equal in length and items.
But don’t worry referential testing is still supported with “===”
if (A === B) //Then both references are equal.
Joel Anderson
D newsgroup
Did you know that there is a D newsgroup on news.digitalmars.com server? Here you can ask/suggest anything about D and even talk to the creator Walter?
Joel Anderson
HTML imbedded code
D can automatically extract code from html pages and compile it like normal code. What are the advantages of this? Apart from beginning able to keep code with documentation future D IDE’s may be able to use this feature for automatic syntax highlighting and object link embedding.
Joel Anderson
Notes
If you have any notes you would like to share, email Mathew Wilson dmd@synesis.com.au or Joel Anderson anderson@firestar.com.au. They must be between one-sentence => two-medium-paragraphs and/or small snippets of code. Otherwise they’ll be considered for the hints and tips section for the Journal.
Joel Anderson
Which comes first?
Design is the key to good programming; but if you don’t to program (sic) then how can you design?
On a more serious note UML is a great designing methodology for object orientated languages like D. Here are some links to get newbie’s started:
Rational’s UML Webpage
Introduction to OMG's UML
Another UML webpage
(Your suggestions)
The above are pretty technical and I’d suggest a small amount of programming experience before attempting these.
Joel Anderson
High Cohesion and Low Coupling
Programs should be lowly coupled and highly cohesive. Why? What does this mean?
Coupling
Programs are highly coupled when they are heavily reliant on one another. This is considered NOT A GOOD THING. For example a car that only uses one type of tyre and that tyre only being useable on that car. In this case the tyre is not reusable. You can’t very well take the tyre and use it on another car. High coupling make programs less reusable.
Cohesion
Cohesion is the way things work together. Take the car example again. Suppose the tyre was so generalised that it even works on your-next-door-neighbours billycart. The car may be reduced a maximum of 10km/h. Low cohesion makes components less flexible/efficient together.
It’s often difficult to get the balance just right between these two concepts but just it in the back of your mind and your programs will be all the better. Remember, high cohesion and low coupling = good thing but low cohesion and high coupling = bad thing.
Joel Anderson
When to Optimise
There are two main types of optimisation speed and size. Optimisation only needs to be used when things have to be fast or small.
1. Optimisation should be an iterative process. In the design stage optimisation should be on a global scale. As the project progresses focus should narrow.
2. Focus on the areas in the code which are bottle necks (optimisation problem areas).
3. As the project moves along continually look for optimisation opportunities. Ask yourself:
How frequently does this operation occur?
Is it worth spending my valuable time optimising this?
How will this change the overall design?
Will this change make things lowly cohesive or highly coupled?
4. As the project develops, attempt to group simular functions/tasks together. This will mean less optimisation, because code is more centralised.
5. Don’t over optimise. If the code meets its optimisation needs (in all cases), then it’s time to spend energy elsewhere.
Joel Anderson
The KISS and the KINAS rule
Keep It Simple Stupid.
Keep It Neat And Sweet.
Break things down and commenting could actually save you time in the long run. On the other hand, if you break things down or comment too much complexity begins to rear its ugly head again.
Joel Anderson
Localisation
Keep everything localised.
The benefits of keeping things localised are not always obvious to a beginner. What is localisation? It means to keep things within the fields/blocks in which they are used. This rule does not just apply to public/protected/private but also to variables with blocks. Localisation reduces complexity but it does however mean that more things have to be passed by parameter/argument.
I had a friend who grew sick of typing “int” every time he/she made a loop. So he/she decided it would be a good idea to declare “int n” as a global (so every function has access to n). UMM... Has his/her program grow the “for (n=0; nJoel Anderson
GOTO is Evil
If you mention GOTO on just about any programming website, you’re likely to get flamed. Goto’s breaks the structure/flow of the program and compliers find it more difficult to optimise goto statements.
There is just about always a better way to write something without using the dreaded GOTO statement. Many modern languages don’t even have goto. Although as Walter (“Programming in D for C Programmers”, Apr 21, 2002) said:
“Many C-way goto statements can be eliminated with the D feature of labelled break and continue statements. But D is a practical language for practical programmers who know when the rules need to be broken. So of course D supports the goto!”
Joel Anderson