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