Programming Best Practices: Part 1

I ‘m targeting the Hobbyists and Junior Developers here, not the software houses that have Design Guru’s, Development managers leading teams of experienced developers.

 

Part 1 doesn’t mean that I ‘ll post Part 2 tomorrow , but means that there will always be much much more enhancements and best practices so long as developers are still there on the globe .

 

The stuff I mention here is not mandatory. You can go and code the way you like. But these best practices will make you work much more efficiently, to make professionally looking applications with much higher quality like the big software houses and professional developers do.

 

You may not use all the recommendations in each application you write. Just choose what suits the application you are writing.

 

The numbers are for numbering. They don’t mean an order. I may rewrite these items again in a different order, so just read it the way you like.

 

Rule no.1

 

I forgot, they aren’t rules

So

 

 . Best Practice no. 1: Reusable Code

 

You will never be a smart guy if you spend ten days to write code that does a simple action that somebody else did. And, I guess you will be stupid if are spending that time to ReWRITE code that you have written a similar one before

 

Make sure you rely on Reusable Code.

 

What I mean here is always have your functions / methods in a reusable form that you can further use in another project. Reuse code written by somebody else in your team…

 

Rely on source code if it is available, frameworks, like .Net, MFC …etc

 

Some big companies even sell their engines for others to use

 

Just make sure you aren’t violating a copyright when you use somebody else’s code

 

. Best Practice no. 2: Test Test Test and Test

 

Relying on reusable code saves a lot of time, because this code has been tested enough before.

 

But, when you write your reusable code, make sure you test it enough, so that you don’t bother ReTesting it when it is reused in a new project.

 

. Best Practice no. 3: Distribution

 

Distribute your Reusable code in class files that can be used later.

Also, when you are writing your new project, distribute it to classes that have related stuff. This is better in debugging and also enhances the performance of your program.

Suppose I have 1000 methods in my applications. Imagine loading a file that has the 1000 methods. A very big load on the memory. But if it is distributed on different files what you only load what you need, when you need it, this will have a boost on your application performance.

 

. Best Practice no. 4: Avoid Public stuff

 

The user’s System memory is expensive. So, don’t use the Public declaration when you don’t need it.

 

. Best Practice no. 5: Comments

 

Comments don’t increase the file size the way you may think. It is something negligible. Comments have no effect on the performance.

 

So, when you write your reusable code or even non – reusable, make sure you comment on classes and methods. So that you can remember what was that method / class supposed to do when you come to use it again. This will also help other people in your company / team using your code, to understand what you did at a glance instead of revising your code line by line.

 

. Best Practice no. 6: Be Simple

 

Don’t act like a rocket scientist when you code. The simple and smaller your code is the better it is. Perfection is Simple.

 

Again I say: Be simple. Perfection in simplicity

 

. Best Practice no. 7: Use Versioning

 

Versioning is important when you update or add new features to your reusable classes.

Don’t just overwrite the old stuff. Keep the old files and make new ones with a new version number, and write a little comment to show how this class differs from the older version.

 

This will have lots of benefits later if you begin to face compatibility issues. It will be easier to detect the problems when you use class versioning.

 

. Best Practice no. 8: No Hardcoding

 

Don’t’ hardcode the filenames, IP address numbers, FQDN machine names and credentials. Make your best to read them form files so that they can be easily changed according to the project and the deployment machines

 

. Best Practice no. 9: Bug Handling

 

If you don’t have bugs then you aren’t a developer

 

But, no need to have your program crash when the user uses it if something unexpected happens.

 

Exception handling in your code is very important. Try to handle the expected exceptions, with the suitable action, or a neat error message and an option to close the program. Don’t wait for the crash.

 

. Best Practice no. 10: Logging

 

Make sure your program is logging the actions, time, machine name, the user account doing the action …etc according to the sensitivity of your program , actions and clients your are targeting.

 

Also, have some sense. Don’t overload the processor logging useless data for non sensitive scenarios.

 

Either using text log files, xml files, Event logs or even Sql database, all depends on the size of the expected log or for how long it is expected to be kept.

 

. Best Practice no. 11: Temp

 

If you are acting on something that may cause a critical loss of data, make sure you make a temporary copy, so that you still have a rollback action that gets that temp back if something foolish happens and so, no data is lost.

 

. Best Practice no. 12: Stick to Coding Standards and Naming Conventions

 

This will decrease your typing errors. And will have a great value when you work in a team

 

. Best Practice no. 13: Avoid duplicate names

 

If I ‘m writing a C++ or a C# application,

 

MyMethod() and mymethod() are 2 different ones. But in Visual Basic they are the same.

 

Suppose you made a library in C#.net and you had to use it later to in a VB.net application so as to make the best use of the Common Language and Intermediate Language in .Net. You will have a bunch of bugs!!

 

So, it is a best practice to avoid duplicate names with different casing.

 

Another scenario will be even if my entire project is in a case sensitive language:

Avoid the unexpected errors you may have even by the typing mistakes, which popup by the compiler, but will only give an unexpected result.

 

. Best Practice no. 14: Design first then code

 

I ‘m not talking about Agile or Waterfall here. I ‘m talking about the developers who begin to write on their project without having a design.

I ‘m talking about the developers who begin to write a complicated class with lots of methods that rely on each others and other classes without having a flowchart for what they are going to do.

 

So, PLEASE: Have a clear design before writing your first line of code.

 

 

. Best Practice no. 15: Be organized, have your own library

 

As I  said before about reusable code. Be organized. Make your own folders having the classes you wrote before in an organized manner. Don’t just throw code files everywhere on your computer. Also, make special folders for the icons. Reusable forms that you commonly use (like the formsplash or the about form).

 

But, make sure you don’t have your company’s property for your private library. Also make sure you check with your legal department if you are allowed to use the code YOU WROTE for your company to use it somewhere else

 

 

Security Related best practices:

 

. Best Practice no. 1: Code in Low Privilege

 

. In a business like environment, admins deploy the application, either manually or using a group policy, or automated installs ..etc

But for security reasons, the users aren’t admins on their machines.

Some software doing some critical stuff like editing on registry or so , can be denied by the system , as the user doesn’t have enough privileges to run it, and the admins then have to escalade the user privileges, or in some very restricted environments, your project may be even rejected and denied access.  This is especially if you are writing windows based applications. Similar stuff sometimes happens in web applications when they have complicated scripts that may look malicious sometimes. Similar stuff too happens when you write applications for Microsoft Office that have Macros. These macros may be even denied by your antivirus software.

 

This happens because developers are Administrators on their machines.

So, it is better to begin writing your project using an account with the similar privileges and environment like your expected user. This will make you overcome lots of problem at the coding phase.

 

. Best Practice no. 2: Encrypt the web.config file

 

The web.config file has lots of sensitive information for your web project. Just make it encrypted. Don’t leave it in the plain text form.

 

. Best Practice no. 3: Encryption and Logging

 

Log files and Temporary files are the first to attack. Developers don’t bother them selves to encrypt their application’s temp and logs.

 

Make sure you encrypt them if they have sensitive information. Also make sure you handle the security issues for who is allowed to view the logs.

 

 

 

I’ll wait for your comments to make more improvements and post Part 2

 

Technorati Tags: Programming developer Best Practices Code Enahancement CMMI