15 recommendations to make you a better programmer

I often give the same advice over and over to programmers that I work with. Most of the time I give advice on things to do with regards to coding and that works out pretty well, but “don’ts” are just as important as the dos. Let’s look at the 15 things a programmer should watch for. Most of these are geared toward object-oriented languages, but some can apply to procedural,functional languages as well.

  1. Don’t forget the tenets of object-oriented programming, Inheritance, Encapsulation and Polymorphism.
  2. Don’t overuse inheritance. Inheritance should make sense. Ask yourself about the relationship. If “is a”, then you should inherit, if “has a” then it should be a relationship off the owner.
  3. Watch your method/function/subroutine lengths. If a method or function gets longer than 5-10 lines, you are probably missing an opportunity to abstract or extract functionality. The longer a method is, the more complex it will become exponentially.
  4. Before you start to “roll your own”, spend some time looking for open source solutions or blog articles where someone solved this problem before. There is nothing wrong with leveraging someone else’s hard work. Chances are someone else will take over your work at some point and it is easier for them if it is a solution that they can find support for by a Google search. Also, think about the testing, maintenance time with regards to rolling your own solution. Aside from that the chances that one person can produce a solution better than a community project is unlikely no matter how good you think you are.
  5. Don’t hack. There is a lot to be said for code written during a time crunch, but more often than not, programmers will use this excuse to shortcut a solution and not take time to do it the way they know it should be done. You want the next programmer to look at your code and pat you on the back for your solution, not curse you in disgust.
  6. Don’t forget about reusability. Think about every line of code you write. Ask yourself if what you are doing is going to be repetitive by you or someone else. If it is, then abstract it to a utility class and reuse it. Never just copy code from one place to another when you could extract it to a utility or utilize polymorphism to address the need.
  7. Don’t use obscure variable names. It should be very clear what data a variable contains when another person looks at your code.
  8. Don’t forget to ask for a code review or design review. No one is perfect. You should always walk through your code with a peer with both of you sitting side by side. Explain your rational, what techniques you used and ask the reviewer for recommendations. Two heads are better than one. Also, you should do this early and often. Don’t wait until you finish a project to ask for a review because by then, it may be too late to fix.
  9. Don’t use global or member variables when a local one would suffice. I’ve seen this a few times before. A junior programmer will scope their variables as wide as possible. This not only causes confusion when others look at the code, but it can cause unintended consequences in your applications.
  10. Don’t forget about threading and thread-safety. Threading is a difficult concept for unseasoned programmers. It can bite you really quick if you don’t think about it. Complex applications may have many threads accessing the same resources and if you’re not concentrating on managing this, then you can get junk data, crashes and unexpected results. And DO NOT synchronize everything as a solution to thread safety, else performance will suffer.
  11. Don’t code first and ask questions later. You should understand the problem domain and the goals you want to accomplish before you even write one line of code. Ideally, you will design the application and run through your mental sanity checks in your head well ahead of actually putting code onto a screen.
  12. Don’t forget about unit testing. Unless you just enjoy spending hours and hours testing your application or sitting with your QA resource, you should unit test your code at the lowest levels and run these tests as regression tests along with your builds. Remember that a unit test is for very small bits of code. A unit test does not take the place of actual functional testing of your application, but it sure makes it easier.
  13. Don’t forget to comment and don’t over comment. If you want to provide yourself a hint, reminder or give that hint to another programmer, use a comment to make the point. Don’t over comment your code either as too many comments are an indication of complexity and you need to revisit your code for simplification or refactoring.
  14. Don’t forget to refactor your code as you go. If you see areas of your code you need to revise, do so as early an opportunity as possible. If you wait, the problem can be compounded by other code that utilizes it. Never wait until the end of a project to refactor, you will never get the chance and by then, it is a daunting task.
  15. Don’t forget to layer and loosely couple. Do not forget to keep your code as loosely coupled as possible. A good strategy is to layer your code, e.g. DAO layer, service layer, integration layer, Controllers, UI layer, etc. For example, a UI Layer should never access classes directly from the DAO Layer, but should utilize the controllers to access data, which in turn access service layer and so on.

While this is not an all inclusive list, it does give a programmer a great advantage. Being a programmer is definitely about working smarter and not harder.

 

 

 

Java,.NET Caching with Spring

If you want a major performance boost out of your application, then caching should be a part of your strategy. No doubt you have experienced moments in coding where you needed to store sets of data so that you don’t have to go back to the source to get them every time. The simplest form of caching is lazy loading where you actually create the objects the first time in memory and from there on out, you access them from memory. In reality, caching gets a lot more difficult and has many considerations.

  • How do I cache in a distributed environment
  • How do I expire items in the cache
  • How do I prevent my cache from overrunning memory
  • How do I make my cache thread-safe and segment it

All of these are concerns that you will have if you “roll your own” solution to caching. Let’s just leave the heavy lifting to the Spring Framework and we can go back to concerning ourselves with solving the complex problems of our domain.

Spring has a caching mechanism/abstraction for both Java and .NET, although the Java version is far more robust. Caching in Spring is accomplished through AOP or Aspect Oriented Programming. A caching annotation (Java) or attribute (.NET) can be placed on a method or a class to indicate that it should be cached, which cache should be used and how long to keep the resources before eviction.

Java Spring Cache with EHCache

In Java, caching with Spring couldn’t be easier. Spring supports several different caching implementations but EHCache is the default and by far my favorite. EHCache is robust, configurable and handles a distributed environment with ease. Let’s look at how we can add the ability to cache to a Spring project.
Application-context.xml

<beans xmlns="http://www.springframework.org/schema/beans" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xmlns:cache="http://www.springframework.org/schema/cache"
   xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsdhttp://www.springframework.org/schema/cache http://www.springframework.org/schema/cache/spring-cache.xsd">
  <cache:annotation-driven />

<!-- Ehcache library setup -->
<bean id="ehcache" class="org.springframework.cache.ehcache.EhCacheManagerFactoryBean" p:config-location="ehcache.xml"/>

Now that we have our cache setup, we can start to utilize it.

@Cacheable(name="records", key="recordList") //Cache the output of records, return it if already cached
public Collection findRecords(RecordId recordId) {...}

@Cacheable(name="records", key="recordsList", condition="recordType == 2") //Only cache if record type is 2
public Collection findRecords(int recordType) {...}

@CacheEvict(value = "records", allEntries=true) //Reload the cache, evict all entries
public void loadAllRecords() {...}

In the above example, we specify through the annotation that the records collection will be stored in a cache named “records” and the key to access the collection will be called “recordList”. The key parameter is optional. We also displayed an example of using Spring Expression language to process the cache conditionally. Remember that caches are defined either dynamically like above or in the ehcache.xml. For most complex caching scenarios, you will want to define the cache in the ehcache.xml with eviction and distribution rules and Spring will find it by the name parameter in the annotation.

What about .NET?

In .NET, you have a very similar mechanism to managing a cache.

<!-- Apply aspects to DAOs -->

[CacheResult("MyCache", "'Record.RecordId=' + #id", TimeToLive = "0:1:0")]
public Collection GetRecord(long RecordId)
{
   // implementation not shown...
}

Remember that with the .NET cache, you provide the caching implementation in the XML just as you do in the Java version. In this example, we have used the provided AspNetCache.

What about controlling the cache yourself, querying the cache and more complex operations? Well even that is simple by merely autowiring the cache class or retrieving it from the context.

@Autowired
EhcacheCacheManager cacheManager;

...
EHCache cache = cacheManager.getCache("records");
Collection records = cache.get("recordList");

Built-in .NET Caching

Fortunately for .NET users, there is also a built in caching framework already in .NET. This technique is used mostly in the MVC and ASP world and I am not particularly fond of it since it is specifically geared for the web side of an application. I would prefer it to be more generic like the Spring solution, but it also has some advantages such as you can configure the caches in the web.config, you can also create custom caching implementations that utilize different mechanisms for cache management. Here is a great example utilizing MongoDB. The .NET version of the cache works much the same way as the Spring one does. Here are some examples with configuration.

[OutputCache(CacheProfile="RecordList", Duration=20, VaryByParam="recordType")]
Public ActionResult GetRecordList(string recordType) {

}

Now the configuration in the web.config…

 
//web.config

  <caching>
      <outputCacheSetting>
        <outputCacheProfile>
          <add name="RecordList"  duration="3600" />
         </outputCacheProfile>
      </outputCacheSetting>
      </caching>

If we are deploying our application to the cloud in Azure, we can use the AppFabric cache as demonstrated here.

Hibernate, Data Nucleus, JPA Result Caching

Another thing to keep in mind is that when you are using tools such as Hibernate, caching is built in with these solutions. There is a built-in second level cache implementation that is provided when you configure Hibernate and I tend to use EHCache for this as well. You must remember to add the Hibernate Cache annotation onto your objects at the class level that you want to cache as well. A properly setup ORM solution with Spring and Hibernate with a properly configured second-level cache is very hard to beat in performance and maintainability.

Conclusion

We have really done a lot with very little thanks to Spring and caching. While caching is powerful and will help improve the performance of your application, if it is overdone, it can cause problems that are difficult to diagnose. If you are caching, make sure you always understand the implications of the data and what will happen throughout the caches lifecycle.

.NET Project Blues…Java vs .NET

By Chris L Hardin
Sr. Software Architect
It’s been almost 3 years since I have written a .NET project from scratch and I have to tell you, I am getting the itch. Don’t get me wrong, on any new project, I would choose Java hands down as the technology for the job due to one major factor…money, but a architect likes to keep his skills up.

This might be a good opportunity to list some of the reasons why I prefer Java/J2EE solutions over .NET solutions. Let’s look at a nice list and I’ll event throw in a few things that .NET is better at.

1. Java is more cost effective. You can do any Java project totally on the cost of writing the code. No purchases needed. Jboss or Tomcat for the Web/Application Server, Hibernate for the ORM mapping, Spring for the business layer and integrations and choose a great open source database like PostgreSQL and let me tell you…it rocks. Run it all on Linux servers. In .NET, I am going to get stuck for cost somewhere. The windows server, the database if I choose SQL Server, other components that Microsoft wants to stick me for. .NET does have a cost advantage in the area of developers. .NET developers typically make about 15% less than Java developers. I really can attribute this statistic to any one particular reason, however it is an advantage.

2. There is typically no difference between .NET and Java that you can name that make them night and day different. If a developed two applications,one in Java and the other in C#, you’d be able to follow them both easily if you know either language alone. I’d use nHibernate, Spring.NET and Spring MVC on the .NET side just like I would use Hibernate, Spring and Spring MVC on the Java side.

3. It is very easy to build a GUI in .NET with Visual Studio. Well, this is not really a fair comparison. Visual Studio is an expensive product and there is only one way to write a page in .NET and that is ASP.net. Java is more flexible, the good ideas are free…you know. I will say this though. If I had a requirement to build a fat client, I would download SharpDevelop and do it in C# before I would touch Java Swing. I’d rather had my head crushed in a vice than write Swing. Been there and done that. Also, I’d rather write an interface in ASP.NET using SharpDevelop than use Java Server “Feces”. My main preference is to write my front end in Dojo or some other Javascript framework and keep my front end neutral of .NET or Java.

4. VB.NET sucks…enough said. It should never have been allowed to live. .NET should have been C# only and if people still wanted to write VB, they just could stay on their old platforms and not upgrade. Now everyone thinks that VB will always be supported and it probably will…unfortunately. I prefer C# just because it is so much like Java. Don’t get me wrong, I like Perl, Javascript and Ruby too…just to let you know I am not completely bias. I know enough about VB to fill a small thimble, but I have seen it enough to know I hate it.

5. Hibernate and Spring are originally written in Java and ported to .NET later. There is always a wait for the latest version of nHibernate and Spring.NET.

6. EJBs are dead…get over it. I wrote em, I used em, I evangelized them… I let em go. Spring and Hibernate effectively killed them dead.

7. JSF is dying…get over that too…and Struts is dead as well. If you are looking at EJBs, Struts or JSF for a new project, you need your head examined. I’ve done many, many projects with these technologies, so don’t tell me I havn’t used them and don’t know what I am talking about. The Ajax craze is effectively killing page technologies like ASP,JSP…etc. Don’t even bother telling me, “Well there are Ajax components in JSF (ICE Faces) and in .NET. Go ahead put together an interface weave these components together and watch the different Ajax libraries clash at runtime. Just learn the Dojo, Ext, Google Web Toolkit, YUI frameworks and learn to use the widgets or hire me to do it for you.

8. Java is always going to be more advanced than .NET. It is always going to enjoy the benefits of more open source libraries in the language than you can shake a stick at because it is freely available and runs easier on more platforms. Unix/Linux servers are more stable, try to cobble a .NET project to run on one.

9. Microsoft changes it’s own standard when it sees fit, doesn’t matter to them if you have to change all your code. They change meaningless crap in the specifications their own browser supports, but keep VB.net. For cripes sake, I’d rather write an entire application in Intermediate Language.

10. C# is a clone of Java. Java was out there long before C# was even a gleam in some Microsoft engineers eye. C# was based on Java and it is no mistake that C# looks exactly like it except for subtle changes. The changes aren’t really big enough to call it another language in my opinion. I worked on a project once where I went back and forth all day. I had a minor stutter here and there but no major issues.

I think I started telling you something interesting and it developed into a rant on top of a soapbox. Although I do love Java, I do enjoy doing a .NET project every so often to keep myself at least versed enough to be able to explain what I am talking about. Imitation is the most sincere form of flattery. I guess I should be thankful that C# came out looking like Java rather than an advanced form of VB.

I’m just waiting for that next big language to come around like Java and C# when they came onto the scene. I thought Ruby was going to be it, but boy was I fooled. Ruby enjoys a great following, but I’d call it more of a cult. Now that I have said that I am looking over my shoulder for some Ruby zealot to smite me.