Structured Programing

Introduction

The following is a collection of design principles related to considerations which might be taken into account when structuring a program.

Background

Creating a program from scratch requires a lot of design considerations. Recently, I decided to create a program from scratch, without any design in mind and see where it went. Although my code seemed clean, I found that it had a lot of dependencies and could become very difficult to change. So I set out on the internet to do some researching and try to find a better way. The following is an outline of some basic programming principles I have compiled from my research.

The General Consensus

Dos and Don'ts

If you ask any programmer, they will probably have some good tips on what you should not do, when it comes to writing a program. During my research, I came across the following tips:

1. Don't use global objects as they will conflict with other programmers and future changes.
2. Don't use singletons as other programmers will hate you if they try to use your code.
3. Don't make repeated file access requests as this will slow down your program.
4. Don't use repeated database accesses as this will slow down your program.
5. Don't pass arguments around your program as it creates too many dependencies.
6. Don't create god objects as it makes the code too hard to troubleshoot.
7. Data should only need to be loaded once and any changes should be saved to a file or database, for easy reloading in the event of failure.
8. Code should be modular in design, so that a class is responsible for one task, and one task only. This makes the code more flexible and easier to troubleshoot.
9. Once written, a class should have only 1 reason to change, bug fixes. Any further additions to functionality, should be made by extending the original class.

Now, I could go on forever with this but suffice it to say that there are a lot of different views on what is good programing practice. Should you listen? Well, that's up to you but I would suggest that you don't try to follow them to the letter. With do's and dont's, it's entirely possible to paint yourself into a corner, where it can become impossible to do anything.

Design Patterns and Frameworks

A design pattern is a way of writing code, to suite the task you wish to perform. Some examples of design patterns are Factories, Abstraction, Dependency Injection, Events and Listeners, Such design patterns have been developed by advanced programmers, over the course of their career by trial and error. It is a good idea to research these beforehand and try to identify any which might be relevant, to the type of program you wish to create.

Frameworks are a pre written set of classes which simplify certain mundane procedures, which are commonly used by many programmers. Some examples of Frameworks you may or may not be familiar with are JQuery, Spring, Angular, Backbone and Zend. I won't go into more specifics about any of them, as this is outside the scope of this article. Instead, I will leave it up to you to research them and learn from their documentation, which is more focused on those specific topics. Which ones you choose, will depend on your intended application.

Conceptual Design

Conceptual design is the very first phase of design, in which drawings or solid models are the dominant tools and products. - www.ata-e.com/services/conceptual

Couldn't have said it better myself.

If you have ever wondered how people know what classes to create and how they should be linked to other parts of the program, this is what you are looking for. This stage is where you will be putting pen to paper, or texter to whiteboard and drawing up a basic model of the program you wish to create. You will need to identify the main elements of your program and what they will be responsible for. Any file and or database access points will also need to be clearly defined. If your program does need to store data, it's good practice to make a list of the types of data you might need to store and any structures they might employ. There are many different models available such as Schema, dataflow diagram, flow chart and entity relationship. Exactly which ones you will need depends greatly on the elements your program will employ. Again, I will not be going into details about this, as there are many good, well written tutorials online, about this very topic. So get down and start drawing!

Business Rules are another important aspect of conceptual design, they govern the flow of data in your program and its interaction with other objects. It's a good idea to write some basic rules about your program, so that you can try to stick to them during the writing process. Some basic rules for a merchant store might be, Customer has many invoices, Invoice has only one customer, Factory has many raw materials, Raw materials have quantity, Dispatch has many orders, Order has only one dispatch. Writing rules will help you avoid writing code that is redundant before you begin, such as subroutines for invoices generating customers. Now I know that's a bad example, but I wanted to make the point as obvious as possible.

Versioning

To the beginner or hobby programmer, versioning might seem a bit of overkill. However, my research has found otherwise, in fact it can be an important aspect of the programming process.

The first issue which can occur for any programmer, is that there will always be better ways, more efficient methods, refined code, new features and better patterns, the list goes on. Sometimes as programmers, we can get locked in this headspace, where we need to refine our code to the n^th degree and make sure we include every feature available. This is a bad place to be in and can lead to a down spiral into an endless void of refinement.

The second issue which can occur, is after writing a section of code, a new feature might become available in another program, which your code is not written to take advantage of. Users will be suggesting changes to your code, that they want implemented in the next release. Stopping and going back to modify code that you have already written, could happen so often, that you never actually complete your program.

The solution is versioning. Once you begin writing code, you should close the project off to any further modifications of that version. Any new modifications may be noted but should not be implemented, until your next release. During your first release, there will be many bug fixes. This is a perfectly normal part of the programing process and should be implemented in pre-release or snapshot versions. You should always complete your current version before moving on to the next, even if you think it's pointless. This will ensure that you always finish your programs and don't get lost in the code.

An example of versioning is 1.0.1. This is broken down into sections, the first digit symbolizing a full release of a program, which breaks compatibility with previous versions. The second digit a minor release, this is for any new features which you have added. The last digit is for bug fixes and refinement of code.

Conclusion

That concludes this article about Structured Programing, I hope you have enjoyed it. If you have found it useful, I would love to hear from you.

Points of Interest

1. Try not to adhere too closely to what other people say is good or bad programming practice. Instead take their suggestion as advice and consider the underlying reason for the advice. Otherwise you could paint yourself into a corner where it's impossible to do anything at all.
2. A design pattern is a way of writing code, to suit the task you wish to perform. Some examples of design patterns are Factories, Abstraction, Dependency Injection, Events and Listeners.
3. Frameworks are a pre written set of classes which simplify certain mundane procedures, which are commonly used by many programmers. Some examples of Frameworks you may or may not be familiar with are JQuery, Spring, Angular, Backbone and Zend.
4. Conceptual design is the very first phase of design, in which drawings or solid models are the dominant tools and products. - www.ata-e.com/services/conceptual
   There are many different models available for software design, such as Schema, dataflow diagram, flow chart and entity relationship.
5. Business Rules are an important aspect of conceptual design, they govern the flow of data in your program and its interaction with other objects.
6. Once you begin writing code, you should close the project off to any further modifications of that version. Any new modifications may be noted but should not be implemented, until your next release. This will ensure that you always finish your programs and don't get lost in the code.
7. An example of versioning is 1.0.1. This is broken down into sections, the first digit symbolizing a full release of a program, which breaks compatibility with previous versions. The second digit is a minor release, this is for any new features which you have added. The last digit is for bug fixes and refinement of code.