Rules of Programming

In my opinion, coding is an art form that requires attention to detail and adherence to best practices. Throughout my career, I have encountered various pitfalls and challenges in software development. In this article, I’ll share a list of rules that I follow to steer clear of these pitfalls and enhance the quality of my code. 


  1. Just say “No” to cfform and cfmenu. (ColdFusion programming)

    • During my experience, I collaborated with a programmer I nicknamed “Five-Tagger-J.” This individual had a preference for using cfform and cfmenu, and he employed a rather obscure programming approach, wherein all code execution revolved around the index page.

  2. Limit your use of includes statements!

    • Five-Tagger-J” had another distinctive trait – he heavily relied on cfinclude. As a result, the index page ended up cluttered with a significant number of includes, sometimes even exceeding 100 files in a single application. In contrast, a well-organized web application could typically be condensed to less than 10 files, excluding images.

  3. In the world of programming, it’s essential to recognize that learning new techniques and languages is just as crucial as writing code. Take the time to stay updated with the latest developments in the industry.

    • I must confess that I had reservations about learning JavaScript for a significant period, which led me to lag behind the latest developments. In the past, I believed it was unnecessary, but I was proven wrong. Unfortunately, it took me quite a while to eventually embrace JavaScript.

      Moreover, I’ve observed numerous experienced programmers who become fixated on a single programming language, attempting to apply it to every problem they encounter. In my opinion, this approach doesn’t yield favorable results. Diversifying one’s skills and adapting to different languages and tools is essential for success in the ever-changing world of programming.


  4. Avoid the misconception that if code was difficult to write, it should be difficult to read.

    • Maintaining code clarity and readability is crucial, regardless of the difficulties encountered during the writing process. Unfortunately, “Five-Tagger-J” had a reputation within the company for neglecting code comments in the applications he wrote. When questioned about it, he would defend his stance, stating, “If it was hard to write, it should be hard to read.” Moreover, I have personally observed him removing comments from other people’s code as well. Such practices hinder collaboration and make it challenging for others to understand and maintain the codebase.

  5. It is advisable to avoid including data elements in an application’s code base that are susceptible to frequent changes. By separating these dynamic data elements from the code, it becomes easier to adapt and modify the application without altering the core logic or structure of the code.

    • In my opinion, all programmers, including myself, have been guilty of hardcoding URLs, IP addresses, and other data into our code at some point. During my time at a company, there were three individuals who believed they were highly skilled SharePoint programmers, but their actual computer skills were somewhat below those of recent college graduates with Computer Information System degrees. We playfully nicknamed them “Fauxgrammers.”

      On one occasion, I inherited a SharePoint Out-of-the-Box application developed by one of these fauxgrammers using the End-of-Life application “Infopath.” A change request to this application revealed a drop-down list containing names of employees, which were hardcoded into the form. Consequently, any updates to the employee list required manual changes to the application, followed by re-uploading it to the SharePoint server. This lack of flexibility and automation in handling employee data posed challenges for maintaining the application efficiently.

  6. When starting new projects, it’s essential to steer clear of dying or End-of-Life technologies. Otherwise, you’ll eventually face the need to rewrite the entire project when the technology becomes obsolete or unsupported. This, in turn, adds to the overall cost of application development for your employer. By choosing current and well-supported technologies, you ensure the longevity of your project and minimize the risk of costly rewrites in the future.

    • The application mentioned in rule #5 was developed using a technology that was already labeled as “End of Life” at the time. Moreover, Microsoft had announced the discontinuation of InfoPath services in SharePoint Online. Despite being in the process of migrating data from SharePoint 2013 to SharePoint Online, our “Fauxgrammers” insisted on maintaining support for this outdated technology. This posed significant challenges and potential issues for our team.

      The “Fauxgrammers” wrote many Infopath forms, including this one, were created with the intention of establishing Infopath as the company’s standard for forms. However, the decision to rely on this technology proved to be problematic n the long run once our on-prem SharePoint 2013 server was shutdown and InfoPath impending obsolescence.

  7. When you’re coding, always remember that you might encounter your own code again in a week, a month, a year, or even five years from now. So, it’s crucial to anticipate the need for future fixes or updates. Aim to write quality code that is easy to read and understand, not just for others but also for your future self. — It’s your mess; you clean it up! (Gibb’s Rules #45)

  8. Pay attention when companies like Microsoft and Adobe demonstrate or provide coding samples that differ from your own programming practices. These demonstrations can offer valuable insights into alternative approaches, best practices, and insights to where the companies are taking the technology. Incorporating these learnings can enhance your coding skills and efficiency, allowing you to stay up-to-date with the industry’s direction and technological advancements. Being open to learning from industry leaders can significantly contribute to your growth as a programmer.

    • Some years back, I started noticing Microsoft’s shift towards using C# in their code examples, moving away from Visual Basic. Likewise, Adobe began favoring CFScript over ColdFusion Tags in their examples. Admittedly, I was initially hesitant to embrace these changes, but eventually, I found both C# and CFScript appealing due to their resemblance to other familiar programming languages.

      These code examples and company demos provided valuable insights into the direction these technologies were heading. Surprisingly, many people in the local helpdesk industry overlooked these announcements. For instance, server administrators were caught off guard when Microsoft made significant changes, favoring PowerShell over GUI applications for administrative tasks. Staying informed about the direction companies take with their technologies is crucial to stay ahead and adapt to emerging trends effectively.

I’ll make sure to update my rules periodically to ensure they stay relevant and effective. Additionally, I’d like to clarify that the terms “Five-tagger-J” and “Fauxgrammers” are simply playful nicknames I use to describe these individuals while keeping their real names confidential. These nicknames serve as a light-hearted way for me to refer to them without revealing their identities.

If you have any rules or insights you’d like to share, feel free to comment below! Your contributions will be highly appreciated, and together, we can foster a supportive environment for learning and improvement.

Leave a comment