What are Loops For In Programming?


programming-loopsIn programming, we often get situations where we would like to repeat a certain piece of code again and again.  Of course, we could just copy and paste this code one after another – however there are many negative elements to this.

  1. You’d have to know how many times you wanted to repeat the code at compile time – i.e. you could not calculate this at run time as you’d have to know beforehand how many times you need to ‘paste’ your code in.  You may know the number of loops that you want to do at compile time, but then again – you may not.
  2. Your code becomes a monstrosity – picture the scene, block after block of code with the same things repeated over and over again.  This becomes very hard to maintain, your code takes up more disk space (not as much of an issue these days as it once was when there was very limited hard drive space but still there should be a drive, as a programmer, to ensure that the code that you right is as clean and efficient as possible.
  3. It’s not maintainable – you’ll spend hours and hours maintaining one block of code that is actually now 1000 blocks of code that could have just used a loop.  Imagine you need to change one calculation in your block of code.  Now you have to do it 1000 times, 10,000 times, 100,000 times, maybe even 1 million times – you get the picture.

Loops can be used in programming languages where we want to do the same (or similar) set of actions (lines of code) multiple times.  All modern programming languages support looping and most support the different common types of looping such as For Loops, While Loops and Do Loops.

Two Main Types of Loop

There are two main types of loops in programming – when we say types we don’t mean, for example, ‘for’ is a type of loop.  We’re a level higher than that.

The first type of loop is where you are repeating a block of statements for a known number of times (iterations of a loop).  For example, if you know before you enter a loop that you want to loop around it 365 times, one for each day of the year – then you are using this type of loop.  This type of loop is known as a deterministic loop.  This means that the number of iterations is known and defined prior to entering the loop.  This loop will run the specified number of times unless it hits an ‘exit’ statement – which you can use in your code, for example to exit a loop if an error has occurred.

The second type of loop – and you may have guessed it already – is where you are repeating a block of statements for an unknown or indeterminate amount of time.  For example, where the loop being completed depends on variables and results of a calculation being performed in the loop.  While a condition is true, or untrue, the loop will continue until the condition is satisfied.  As a programmer, you have to be careful with this type of loop – as there is the possibility for chaos.  Remember the golden rule:

Indeterminate iteration loops where the number of loops is unknown until the loop is executed should always have an exit strategy!

What does this mean?  It means, don’t get caught in an infinite loop (even the best get caught out sometimes)!  Infinite loops not only hang your application – causing much annoyance to the user, but also can cause the system they are running on to run out of memory and crash – again this causes an even more infuriated user.  Remember, defensive coding is king!

As an example, if you have an indeterminate iteration loop you obviously don’t know how many times it will loop – but we can take precautions to some degree in almost all circumstances where they are used.  Firstly, errors and error handling.  Can your loop continue if one of the passes encounter an error?  Technically, a lot of the time it can – but from a programmatic logic point of view – should it continue and is there any point in it continuing.  If a loop is going to occur hundreds of times but on the second loop pass there’s an error and this means your final result will be wrong, exit the loop and display an error message to the user rather than leave them hanging (in the application sense, literally!).

Secondly, for some indeterminate loops there’s a sensible ‘maximum’.  For example, if your loop on average iterates 50 times, occasionally iterates 100 times and rarely iterates 250 times then it’d be sensible to code in your application that if we get to the 500th pass of this loop, somethings probably gone wrong – exit!  You’d rather have a small bug to patch that is very infrequent for a minority of users than to have users banging their heads in frustration against the keyboard!

Another example would be reading a file.  You might want to loop line by line through a file and output it to the screen.  You could loop 50 times – but what happens if there are 66 lines in this document.  This is another example where the indeterminate loop is your friend.  The number of loop passes is indeterminate as the number of lines contained in a file that the user passes to your application is indeterminate.  Whilst you may want to set maximums in your application – i.e. only files 1000 lines or less, you application won’t be very useful if you say “yes it can process files, as long as they are exactly 12 lines long!”.

Web DynPro ABAP – Context Menu Not Showing?

For the developers and programmers among us adding a context menu to an application is a fairly basic requirement of many pieces of software.  Adding a context menu in Web DynPro looks on the face of it to be an extremely easy process – and it is, as long as you don’t forget anything ;).

Although there are a fair few guides on the Internet that explain how to add a context menu in Web DynPro they all seem to miss out one important detail, which without knowing it, means that your context menu fails to appear at all and can make the process extremely stressful.

That’s why I’m sharing this top tip with you today.  Firstly, follow one of the many guides available such as this one.  And while using this or another guide don’t forget our…..

Context Menu Top Tip

Firstly, note that whether you are implementing a dynamic or a static context menu in your application this tip applies to both.

In newer versions of the SAP GUI, according to reports at least from version 7.00 – maybe even earlier, there is a new option to add a context menu to most User Interface elements in the properties tap (i.e. this no longer has to be done programmatically).

However, most, if not all guides seem to have missed out the fact that as well as setting the context menu you want to use in the properties menu you also have to change the ‘ContextMenuBehaviour‘ property to ‘Provide’ rather than the default setting of ‘Inherit’.

As the name suggest, if you leave this on ‘Inherit’ you will be left puzzled by the fact that no matter what you do, you context menu simply won’t appear – only the default one will.

When this property is pointed out, it becomes fairly obvious – however it can be frustrating until you figure it out and waste time!


The conclusion to all this is that it is frustrating but understandable.  Technically however, I think that the SAP GUI could help you out by ‘defaulting’ the ContextMenuBehaviour property to Provide when you actually pick a context menu in the properties.

However, until that happens, every time you set the context menu on a UI element, don’t forget to set the ContextMenuBehaviour property as well!

Image: mynetx.

Rapid Application Prototyping

SoftwareIn the previous article we discussed the iterative design model, which leads very nicely onto the topic of rapid application prototyping.

Rapid application prototyping is the main model used for iterative design.  It is also the model that is most suited to iterative design.  Rapid application prototyping is a dynamic method of software development, contrasting to the more linear waterfall model, which we have also discussed previously.

Rapid application prototyping will involve several iterations of the software development process, as with other iterative models.  The production of prototypes is not intended to be fully representative of the final system.  In fact the final system may be very different from the prototypes.  The focus isn’t so much on the prototype itself, but what we learn from the prototypes.

A prototype is a representation of an idea or a system (or part thereof).  It may be a full mock up of the system.  Equally it may just focus on one or two features of the system.

Prototypes are a very useful tool, especially when working for a customer or company which doesn’t have a lot of technical expertise and experience.  Non-technical customers find it hard to understand complex design documents, technical specifications and modelling diagrams.  However, they find it much easier to see and interact with something – such as a prototype.

There are two types of prototype – throw away and evolutionary.  Throw away prototypes are, as the name suggests, “thrown away” after they have been developed, tested by users and then evaluated.  The next prototype is then created based on the results obtained from the evaluation.  With an evolutionary prototype the same steps are followed, but the prototype isn’t thrown away.  The results and knowledge gained from the evaluation are reincorporated into an updated design which is then used to update and improve the prototype.

The ultimate aim of rapid application prototyping is to create the best system possible, over as many iterations as it is possible to fit within the defined project time.

The benefits of prototyping can be very large – it might make it obvious that the final system would not function correctly or not be fit for purpose.  It may indicate that certain planned functionality isn’t possible on the target operating system or company network environment.   It’s better to find out these things sooner rather than later!

Interactive Systems Design Using An Iterative Model

Iterative Design ModelFurther to our previous article on the Waterfall Model, we will now discuss interactive systems design using an iterative model.

The iterative design model is a fairly new model when compared to the waterfall model, however it is growing in popularity for a number of reasons.  Firstly, what exactly is the iterative design model?

The iterative design model is a dynamic model of design that involves multiple iterations of the design process, rather than just one (such as in the Waterfall model).  The iterative design model implies repeated design, implementation and evaluation of a system.  An aspect which is often feature in and works well with iterative design is prototyping, in the form of rapid prototype development.  Iterative design also lends itself to User Centred Design (UCD).

Rapid prototype development has multiple benefits and as many prototypes as can fit into the allocated project time should be created.

The first benefit of iterative design is that it allows initial design mistakes to be overcome.  It is rare in any project that a design is right the first time – in fact, it is usually hard to know the exact requirements of a project before implementation has started.  In a linear model, after the design stage is over, it’s over.  There’s no going back and modifying the design during the implementation stage.  Whether your design decisions were good or bad, you are stuck with them and this can impact the final system you create.  With an iterative approach, this problem is solved (partly).  You set out your requirements, design the system, produce a prototype and then evaluate the prototype.  You can then use what you have learnt from that prototype to redesign the system and produce another prototype.  The idea is that the system improves with each iteration.

Secondly, as previously mentioned, during the requirements phase of a project you are unlikely to know the exact requirements of the system.  As you realise more requirements or changes to your requirements later during the iteration, you can make modifications to the design on the next iteration.

Another benefit is that, in many cases, you will be working for and with a non technical customer (and possibly non technical users).  They may not necessarily understand complex design documents or technical specifications.  However, they do understand prototypes that they can play with!!  It’s a lot easier for them to test a prototype, see it in action, and see the implications of decisions made during the requirements and design phases.

One thing that does have to be noted though is, as with any other design model, this isn’t perfect.  And you most certainly can’t make huge errors due to carelessness and expect their to be no implications.  Sometimes, initial bad design decisions cannot be overcome due to design inertia – basically some decisions made in the early stages of the project can have such drastic consequences or be so fundamental that it cannot be changed significantly enough to negate the initial bad design decision.

Overall, the iterative design model is a good design model, that is currently underused.  Some businesses have become aware of its potential and have started using it with their software products with some promising results.  The iterative design model is likely to increase in popularity in the future, but there will also be a place for the Waterfall model as well.

When choosing a design model for a project it is always important to consider which design model best suits the project and the circumstances surrounding it.  There isn’t one model that is good for every project – some models benefit some projects better than others!


Name ArgoUML
Category System Development – UML Modelling
URL http://argouml.tigris.org/
Rating (out of 5) [rating:3]

ArgoUML LogoDescription

ArgoUML is a freely available, open source, UML modelling tool which is popular with system developers and is used to create diagrams based on the Unified Modelling Language (UML).  It can create Use Case Diagrams, Class Diagrams, Sequence Diagrams, Activity Diagrams and many more.  While still garnering much support, it is coming under fierce competition from rivals such as the developers of Visual Paradigm who offer a product of a more commericial standard.


ArgoUML is a great tool for UML modelling, however it does have its limitations.  Firstly, its support of the newer UML 2.0 standard is, well, non existent.  Despite this, a lot of developers can cope with it being compliant to UML 1.1.  Something which appears to become increasingly annoying as you use it however is the bugs that are present and the features that are missing from the software.  Simple activities like copying and pasting cannot be completed, which can leave many a developer completely frustrated.  Some menu options and buttons are displayed but are only part functional, or completely missing altogether.  In addition, Argo allows you to include things in your diagrams which are not legal in UML.

However, it does and continues to do well as it is not a product developed by a huge computing company but a community driven open source project.  It’s main rival at the moment is Visual Paradigm who offer both a commericial and a free ‘community’ edition.