Coding Guidelines and Removing the IDE from the Equation
Posted by Matt Rajkowski on May 28, 2009, 10:00 AM EDT
Every so often the topic of which IDE do you use comes up. I've posted about this in the past and while I passionately have a preference, as do others based on the comments to that article, I've found that given the requirement of writing good code, the modern IDE choices are interoperable. Let me explain...
A bunch of us here at Concursive pay for our IDE. Others have chosen Eclipse. From my point-of-view I'm ok with that as the developers have proven that the IDE choices are interoperable. At the end of the day I can't distinguish code done in, let's say IntelliJ IDEA (my preference) to Eclipse (the preference of our other developers). I also have friends who use NetBeans (I only mention that for completeness).
What makes interoperability possible are coding guidelines and best practices...
At the top of my list is code consistency. This includes deciding on the code formatting, file structure and package names used in the project. It also includes using standard coding conventions, like those from Sun. If you're coding JSPs, look at the JSP and JSTL documentation. If you're coding the UI layer, be familiar with CSS and HTML specifications. Make code that is easy for others to maintain with the lowest learning curve.
Another topic is resource allocation. Use resources sparingly and effectively. Use only one database connection at a time, and obtain and release it from the pool as soon as possible. Also, avoid using per-user resources like session variables. They add to the application's memory overhead and to any replication that occurs between servers. Leverage caching and services.
Write tests while implementing code. We're not striving for 100% code coverage, because that often comes at the cost of maintaining the tests, and slowing down the build process, but do write tests for complex code.
Understand the key validators of code. Reliability, security, performance and scalability, maintainability and upgradeability. Collaborate on these topics before writing code. Also strive for customizability and configurability of the application. The framework allows code to be repurposed fairly easily.
UI consistency. Expect the unexpected. A couple of arguments here... several years ago no one said that 800x600 needed to be supported based on statistics... today there's now an influx of netbooks and other devices with tiny screens. While I wouldn't go down to 800x600 as a default, I would say that 1024x768 is a good compromise. Others have said be scalable. Regardless, ensure web applications work on the major browsers: IE (6,7,8), Firefox, and WebKit (Safari and Chrome). In addition, expect that the content will be dynamic. Users can zoom in and out with the browser, and content can be added and deleted. Allow the rendering to adapt.
Log application events. The guideline might be: ERROR -- an application exception occurred and the condition needs to be reviewed; WARN -- unexpected, but handled conditions occur; INFO -- used for one-time messages that describe the startup, initialization and shutdown of various components; DEBUG -- for displaying messages that help in debugging the application, without inundating the typical developer with messages; TRACE -- for low-level in-depth messages that help in debugging the application.
Choose technology wisely. There are many libraries and frameworks out there, and deciding when to use one is important. Make that decision as a team. There's nothing more frustrating then having to maintain a library when you haven't had a chance to work with it. On the other hand, if you've got spare time, become an expert on rising technologies. This will make you a better developer.
So, while the IDE is important, it's what you do with it that's more important. What do you do with your IDE?
