Status: 26.9.2014 pdf version:

Programming.pdf

Programming.docx

• First of all, you need a SPECIFICATION for every programme, i.e. a description of what the programme is supposed to do.
• In this first step, it is not yet a question of defining how the problem is to be solved, but only what its tasks are.
  
• The specification can also serve as a help text, which should be written for every programme.
• In companies or university courses, a task or question is often specified by the client, the company director or the lecturers involved in the course. The task usually only corresponds to the specification in broad outline; normally, the programmer still needs to make some further specifications - possibly in consultation with the client.

2. what data is needed and what data should be generated?

• The specification includes defining the DATA FLOW:
• What data is needed and where does it come from? Should it be imported from a file? Or will it be provided by another programme?
• What data should be generated and what should be done with it? Should it be written to a file, for example? Or are they to be used by other programmes? Or are they perhaps only displayed graphically and are then superfluous and can be deleted again?
  

3. how is the problem subdivided?

• Once the question and the data flow are clear, the task is broken down into smaller subtasks. The overall problem can often be broken down into small chunks, each of which is easy to handle and then only needs to be put in the right order. (This important programming concept is also known as "divide and conquer").
  
• Many of these little morsels can be used in different contexts. It is then worth writing your own little script or function that you can use again and again.
  

4 How do you go about solving the problem?

• The aim is to set up an ALGORITHM, i.e. a generally valid sequence of operations for the problem that are to be executed one after the other
• It often helps to run through an example by hand
• It is a good idea to first think about the algorithm independently of the implementation, preferably on a piece of paper, if you like graphically as a flow chart.
  

5. what is the context of the programme?

• Before you can really get started, you need to consider whether you want to write a SCRIPT or a FUNCTION: Should all variables be visible in the workspace or do you want to encapsulate them?
• Functions are usually the better choice if you want to use them in a larger context. They have defined input and output values and their auxiliary variables cannot conflict with other parts of the overall programme.
• As mentioned in the last point, it often makes sense to write more than one script or function. A programme is then used to coordinate the work of the auxiliary functions or scripts.
  

6 How do I convert the algorithm into a programme?

• Only when all these steps have been completed does the IMPLEMENTATION begin, in which specific commands are written.
  

7. is the programme secure against incorrect operation?

• If a programme is to be used by persons other than the programmer himself or herself, any (foreseeable) operating errors must be intercepted by the programme. (And even if you only use the programme yourself. After one or two years, nobody knows exactly which values are expected in which order when the function is called). Better one case distinction too many than lost data in a complex experiment...
  

8. does the programme do what it is supposed to?

• Of course, the first step is to ensure that no more red lines appear when the programme runs - but that's not the end of the story.
• Before you use a programme seriously, you have to test its function. Firstly, use it for simple examples where you know the correct solution. Then you use it in your standard application and see whether the results are plausible. In addition, you should consider which marginal areas of data could possibly pose a problem or which types of "incorrect operation" could occur.
• For important programmes, it is a good idea to have someone else test the programme after you have tested it yourself. Other people often come up with different ideas about what could go wrong.
  
• If in any cases difficulties arise during testing, you must go back:
• to step 6 in very easy cases, if it is only a syntax problem
• to step 4 if, for example, certain cases have not yet been considered in the algorithm
• to step 1 if the general approach is not yet correct and, for example, a different type of modelling or data analysis must be used.
• Caution! When changing the programme, remember to also change comments and programme headers to keep them up to date!

9. is the programme well documented?

• While you are writing the programme, you should comment on it so that you can go through your code yourself if you want to continue programming later.
• When the programme is finished and tested, you should go through the comments again, complete them and write them in such a way that other people can also understand the programme through them. (Unfortunately, many people don't take this step, which is why a lot of code is unnecessarily written multiple times - sometimes even by the same person who can't remember what it was supposed to do...)