Improving Programmer’s Testing Abilities

How to reduce bugs while coding

1) Enable all of your compiler warnings.

This will help you to detect many of the potential bugs even before the code has started execution. In fact, it might be even better to set up your compiler so that it will include a warning as an error so that all warnings must be resolved for a successful compilation.

2) Use a static analysis tool.

A static analysis tool like ‘lint’ can help detect suspicious language usage. Suspicious usage includes: variables being used before being set, conditions that are constant, and calculations whose result is likely to be outside the range of values representable in the type used.

3) Writing robust, defensive code to prevent bugs.

Defensive coding helps in preventing a plethora of bugs that might occur due to garbage values present in variables. This holds true especially if variables have not been initialized and passed into functions. Having a strict check of what is allowed into a function goes a long way into prevention of potential bugs.

4) Debug through your code.

Perhaps one of the most important steps in an attempt to write bug free code is to always debug through your code instead of directly executing it. Stepping through your code is a form of self code review that will help you weed out a lot of potential problems that the developer would not notice just by a normal execution.

5) Using asserts in the debug version.

Usually, when developers work on a project, it is in debug mode. This mode supports debugging the source code by adding breakpoints. Also we could add asserts into the debug mode that would be disabled in the release version. But having asserts into the debug version, we ensure that all the possible bugs due to improper conditions in the source code will be caught before the release of the software.

6) Get a code review.

Code reviews of the software you write by your peers is a good way to detect potential bugs that may  be in your programmer’s blind spot.

7) Using unit tests to find bugs.

Unit testing is a method of writing tests for each of your units (usually functions) to check the behavior of the functions when the inputs are of various types(correct, erroneous, upper/lower limits, etc).

8) Keep it simple.

Many programmers tend to write complex codes as they want to show off their coding skills. However each line of code that you write could be a potential bug .
The easier it is to understand the code, the lesser will be the number of bugs. Even if they are bugs, they can be found easily.
In short, while writing a code, don’t be a lawyer, be a programmer.

9) Avoid unnecessary refactoring.

While reading code written by others, programmers are often tempted to try and fix what may seem “different” from their programming style.
This type of refactoring can be dangerous because trying to change working code is again a possibility of introducing new bugs

10) Fix bugs – don’t introduce more.

Fixing bugs is always a battle between resolving the earlier ones v/s introducing new ones. Extra care has to be taken while fixing bugs as not to introduce new ones perhaps even more critical than the older ones. Try to fix the bug with minimal change to the code as possible.

11) Test frequently.

Testing frequently will allow finding problems early.

This will save development time for 2 reasons –
a)     Late bug fix may take longer to fix and test. The smaller bug might grow into bigger one as development advances
b)     If the bug is found while the final release is due it will delay the release.

12) Test before starting to work with old version.

One common scenario is when you need to start work on old or recent version. You take the version into your computer and start adding new featuring and you encounter an error. You debug it for long only to find that the problem was in base code. Hence it is always a better idea to do small testing before starting coding on old version.

13) Write test before fixing a bug.

When you uncover a problem in your code, write a test case that exposes this problem before fixing the code. This way if the problem appears it will be caught with the test.

14) Debug the problem.

Often when you have written a bad code, you have a much better idea of what the good code should look like. Remember that just because you have written it does not mean you should keep it.  While debugging the problem first convert bad into good code and then carry on with debugging. This will make debugging the code even easier.

15) Minimize potential problems by avoiding copy paste syndrome.

If a part of code having a bug is copy pasted at many locations then same problem of debugging will be repeated at many places. Hence before using a part of code at other location , debug that part of code properly to ensure its bug free before using.

16) Fixing the symptom and not the problem.

Ask yourself how many times you have fixed the same type of bug. It only indicates that the symptom is being fixed and not the root cause of the problem. This will lead to bugs coming up at different locations in different forms and hence increase debugging time.

Referred link :
code.rkevin.com
blog.interviewstreet.com
msdn.microsoft.com
stackoverflow.com

Challenges with Delphi XE2 Migration

We have been through two migrations (to Delphi XE2) in last few months so why not share our experience of XE2 migration with you all.

Some of the features that attracts you towards XE2:

1)  Unicode Support: Delphi XE2 has Unicode support. Unicode support for Delphi applications helps the applications to support characters from different languages including Chinese.

2)  Rich Interface for Applications:  Different styles can be applied to the UI components to get new look. FireMonkey helps to create 3D and highly interactive applications.

3)  Application level Validation made easy: Some of the components have extra properties for the validation purpose, which will help us to reduce the code and the application will be faster.

4)  Cloud Support: Easily setting up cloud database, so that the database  can be kept in the cloud and could be accessed by different devices.

Follow for more XE2 features.

Well before we start with the migrations we need to make sure few things:

1) List all the components that have been used in Application.

2)Check if any changes have been made to any of the Delphi or any third party component that you are using.

3)Check if all of the third party components that have been used in your application have support for Delphi XE2.

First thing that you need to do before migrating is to check all the components that are required and install them. This becomes one of the tedious tasks(especially if you are using trial version components) when you notice that some of the components you use in your project do not support XE2, in that case there are just two options left:

1) Inquire component vendor regarding the XE2 support and hope that they would (If you are using a trial version).

2) Search for an alternate component to do the same task, downside of this is you will have to make changes to your existing application code too.

If you already have the whole source code of your third party component then what some people do is they try to migrate that to the newer environment.

Now if there were any changes that were made to your third party components and you have installed newer version of third party component then you will have to reintroduce the changes made in previous third party source file in the newer version. While making the changes in the newer source file its better to compare the changed source files of the previous version with original source files on previous version and then introduce the same changes.

While compiling your old code most common error encountered is    ‘Datatype InCompatibility’.

1)  String is now UnicodeString  (Till Delphi 2009 it was Ansistring)

      UnicodeString  features :

•       Strings as large as available memory.

•       Efficient use of memory through shared references.

•       Routines and operators that evaluate strings based on the current locale.

Follow UnicodeString.

2)  Char is now Widechar (Till Delphi 2009 it was Ansichar)

AnsiChar – with an 8-bit representation (accounting for 256 different symbols).
WideChar – with a 16-bit representation (accounting for 64K different symbols).

Same way  PChar pointer is now an alias of  PwideChar, rather than PAnsiChar as it used to be.

On the other side we can see that EXE size increase as compare to other versions , reason can be change to unicode strings, which by themselves double the size of every string in the project.

So that all from our side regarding Migrating your existing code to Delphi XE2 hope it helps you all and “All the Best” to those who are looking to migrate their existing Delphi code to Delphi XE2.

 

 

Software Development Best Practices

What is ‘Best Practices’?

• —  Method or process followed to deliver results successfully and effectively

• —  The process differs from organization to organization.

• —  In software programming it could used for gathering requirement, maintaining code, debugging code, or delivering the end product.

Common Problems of Software Development

• —  Lack of understanding in system requirements on the part of customers and designers
• —  Large gaps between time estimates with actual delivery time.
• —  Lack of Experience leading to either over Estimating or under estimating.
• —  Difficulty in monitoring progress in a software projects
• —  Poor communication among groups working on the same project
• —  Newly trained and  under skilled programmers
• —  Dependence of software on hardware
• —  Lack of inventories of reusable software components to aid in the building of new programs
• —  Too many Change of Requests

Best Practices in Development

1. REQUIREMENT GATHERING
2. PROJECT GOAL
3. CODING
   a) NAMING CONVENTIONS
   b) COMMENTING
4. DEBUGGING
5. TESTING
6. DEPLOYMENT
7. MANAGEMENT

1)      Requirement Gathering

• —  Challenges in Requirement Gathering
  • Scope and Vision not clearly defined
  • All requirements are critical, no priority is defined
  • Signed-off requirements keep changing
  • New requirements get added in the middle of the project
  • Users/customers are busy and not available to specify requirements / Review

• —  Organize a demo meeting to understand Client’s Requirements
• —  Present a Understanding Document(UD)
• —  Present HLD or LLD, if needed
• —  Finalize the Scope of work

2)      Project Goal

• —  Never begin coding without understanding why the code Is being written and what is it being written for.
• —  Always document the project goal in the code, so that a new programmer in future, doesn’t find it difficult to understand ‘what the code does’ and ‘why is it there’.

3)      Coding

• —  Building the code is really just a small part of the total project effort even though it’s what most people equate with the whole process since it’s the most visible.
• —  Best coding evolves from following proper coding standards and guidelines.
  • Naming Conventions for forms, units, variables, functions/ procedures, and components.
  • Appropriate Comments for each and every line of code makes code maintainability much easier.
• —  A best code should have reusable components

a) Naming Conventions

• Instead of using Form1 for forms or Unit1 for Units
  • Use login_frm, home_frm, or formula_unit

• Instead of using temp1, temp2, newtemp, x1, text1
  • Use _ prefix for local temporary variables
  • Use survey_num or stationlst for Tstringlist.

•  Instead of using Button1, Label1, Combobox1
  • Use btnSave, lblUsername, cbCountry

• Instead of using Calc1, Add1 function
  • Use XYaxisToLonLat_Calc, Concate_StationGear

b)      Commenting

• Name of the module.
• Purpose of the Module.
• Description of the Module (In brief).
• Original Author
• Modifications
• Authors who modified code with a description on why it was modified.

4)      Debugging

• —  Programmers usually tend to write the complete code and then begin debugging and checking for errors
• —  Tips
  • Know your IDE’s debugger limitations and features
  • Obvious places may not be the culprits
  • Check for Memory Leak
  • Output  messages
  • Last working code

5)      Testing

• —  Analyze your test results
• —  Think positive
• —  Writing test cases
• —  Performance testing is the critical part
• —  Programmers should not test their own code
• —  Keep developers away from test environment
• —  Involve testers right from software requirement and design phase till deployment

6)      Deployment

• —  “The Project always has last minute problems or bugs during deployment”
• —  Never test the Delivery on programmers computer
• —  Never assume what not tested
• —  Try testing in real time environments
• —  Engage the Client or the user during the Testing(UAT) phase

7)      Management

• —  Discuss Understanding, Assumptions and risks during requirement gathering even during change of request
• —  Prototyping Requirements
• —  Create internal deadlines much ahead of the Delivery
• —  Document Analysis at every stage
• —  Brainstorming sessions
• —  Monitor  status with Review meetings
• —  Client Interaction and Reviews
• —  Timely Delivery

Days to Deadline MIDI world

It was May 9^th and my colleagues were busy with work, I was also doing my pending project work .One of my colleague was struggling with something called “MIDI”. Which I had never heard of.

Out of curiosity I looked on to her screen, my God what was that!!! It was sort of musical keyboard and some complex GUI .I Googled it .. an acronym for “Musical Instrument Digital Interface”. So the MIDI stuff was about sound and it is data communication protocol. It allows electronic devices to interact. Back to work as curiosity itch was itched.

Deep into my coding, a message from the Technical director popped up “Come in”. Took deep breath and went into the cabin, it was just a meeting discussing status of my project work. At the end of the discussion the director said “you will be on a new project from now on”. And started explaining to me in brief and I realized it was the same “MIDI ” based project. I was astounded when I heard the deadline was 11 days away! .This meant I had to take a grip over the concept in a day or two, the same concept with which my was mate struggling for last doze days.
Had no problems with Delphi, but the Great Wall of China for me was “MIDI”. I put on the thinking hat and everything was only “MIDI”, “MIDI” and “MIDI”. Quick start with basic research, browsing through the clients documents, a little of Google, a quick chat with team mate and the MIDI project was ON..!!

“The best way to get a project done faster is to start sooner….” Once my team was clear with requirements, work was divided.

With Google and Skype, we shared knowledge and research without a hint of noise (shhhhhh…Not to disturb the others  :P) .The basic skeleton was up. A thumbs up from the client, that we were heading in the correct direction.
I was a bit happy and scared too as we hadn’t yet started the main thing..!!  “MIDI”.

The main challenges were
1) To send and receive MIDI notes using Delphi
2) Interaction of two applications using MIDI.

My team started with simple Delphi application and by the EOD we hit the jackpot. Our MIDI Wall of China was beneath our feet.

Two and a half day later the sending and receiving part was done.

Done with the point 1…now heading for challenge 2.

“Integration” (hoping for it won’t be a headache) we started integrating both applications and testing on it. And yes it worked. With some guests (access violations) without which my project is incomplete. Fixed the bugs/AVs and now it’s time to give a demo to the Technical director.

Technical director was very happy with the result. This was not all .It was client who should like it, or it should be up to his satisfaction.

A 20 mins meeting with the client, the application was according to his requirements and was up to his satisfaction. With a request some minor changes in application and good comments the call ended.

Inspired by the client comments and boss’ comments, we completed the requested changes in a half day and successfully delivered to the application to the client

MIDI in action

Delphi XE2 and FireMonkey… 3D Application Development Review

While browsing through Embarcadero tweets, I just came across the word ‘Firemonkey’. I had heard about Firefox, and Seamonkey, but whats this FireMonkey all about?? I was curious…

http://www.embarcadero.com/products/firemonkey says ‘FireMonkey’ -The Next Generation Business Application Platform. Imagine a next generation platform that helps you build visually spectacular business applications that are faster, more visually stunning, and more connected – all with native performance on Windows, Mac and iOS…Wow!! Can we do these miracles with DELPHI?? You’re Joking??

I thought of giving myself a break from usual work and explore this Monkey!!

The Videos uploaded on youtube by Embarcaderotech were mindblowing.  They just made me feel, I have the Delphi knowledge, andEmbarcadero has given a such a fabulous platform, why don’t I take the advantage of this and do Miracles in Business/ Graphical/ Mobile world. Delphi as a language had lots of ups and downs over the years; But for sure FireMonkey has made Delphi stronger today.

I have worked with .Net Silverlight and WPF earlier, always liked the rich interfaces you could develop with them. But I always had a fascination towards Delphi Language. I am sure once I start my work with FireMonkey, I will never walk towards the Silverlight, if given a choice of technology.

I downloaded the Trial Version, and following is my review:

FireMonkey is going to be a whole new world of possibilities for Delphi and C++Builder developers. The platform itself is flexible, customizable and multi-platform; all components behave the same on Windows and Mac.

Key Features of the Delphi XE2:

1)      FireMonkey Application Platform for cross-platform applications that run on Windows (both 32- and 64-bit), Mac OS X, and iOS.

2)      VCL supports 64-bit Windows and 32-bit Windows

3)      The Delphi RTL now supports Mac OS X and both 32-bit and 64-bit Windows

4)      Cross-platform application development

The XE2 release supports cross-platform application development for the following platforms:

Mac OS X platform (both Delphi and C++)

Win64 (Delphi only)

The native Win32 platform is also supported by both Delphi and C++Builder in XE2.

• Compilers

Three compilers are provided for cross-platform application development:

1.  DCC64.EXE, the Delphi Cross Compiler for Win64
2. DCCOSX.EXE, the Delphi Cross Compiler for OS X
3. BCCOSX, the C++ Cross Compiler for OS X

• Libraries and Platforms

The XE2 release supports three major libraries and three platforms. The following table lists the target platforms supported by the libraries in XE2:

1. FMXis FireMonkey
2. RTL(run-time library) contains the convenience and utility functions and types (found in System.SysUtils and System.IOUtils, among others) that support both VCL and FMX.
3. VCLis the longstanding Visual Component Library.

5)      LiveBindings in RAD Studio

LiveBindings is based on relational expressions, called binding expressions, that can be either unidirectional or bidirectional. LiveBindings is also about control objects and source objects.  For example, you can bind a TEdit control to a TLabel so that, when the text changes in the edit box, the caption of the label is automatically adjusted to the value evaluated by your binding expression. Another example is binding a tracker control to a progress bar so that the progress rises or lowers as you move the track bar.

I look forward to using the new versions of Delphi !