Since 2014, my conference sessions have consistently revolved around the topic of code quality, emphasizing its significance in my work. I have strived to incorporate this concept extensively into my coding standards book. During this period, I have engaged with developers through online surveys, seeking insights into their approaches to implementing and upholding coding standards. Among the inquiries posed, one stands out: “How can we enhance code quality?” While I have a plethora of ideas on this subject, I am eager to hear what fellow developers have to say.

In this article, I will showcase their responses, accompanied by my commentary. My sincere hope is that this article reaches the Visual Studio and .NET teams at Microsoft, inspiring them to facilitate the adoption of sound code quality and standards practices. Let’s dive in.

1. Emphasizing Unit Testing Integration and Code Commenting in Software Development

Always need to test the latest features with unit testing integration. Proper code commenting.

I wholeheartedly concur with this sentiment. I would like to emphasize that every feature should include integration with unit testing. The .NET Framework provides valuable support in this regard through the IntelliTests feature in Visual Studio, simplifying the addition of encapsulation tests—the cornerstone of Object-Oriented Programming. IntelliTests dynamically assesses code paths while running the code, helping to ensure robust encapsulation.

During my discussions with the Product Manager of this team, he advocated for teams to strive for a 75% code coverage, a goal I endorse. Furthermore, I believe that all public and protected methods should, at a minimum, be accompanied by encapsulation unit tests. Unfortunately, IntelliTests is not available in .NET Core, which means .NET Core developers must perform these tasks manually. This manual approach significantly hinders the achievement of the 75% coverage goal, explaining why I often encounter code lacking comprehensive unit tests in my professional capacity.

In today’s coding landscape, I observe a noticeable absence of code comments or a scarcity thereof. Modern code should aspire to be “self-documenting,” which undoubtedly aids comprehension. Nevertheless, it does not eliminate the necessity for comments, especially from the developer who authored the code. Maintaining these comments up-to-date remains crucial.

2. Promoting Coding Standards: Training, Meetings, and Collaboration for Team Alignment

Better standards, better training, team meetings/training on coding standards.

This recommendation holds immense significance in ensuring that all team members, including contractors, are aligned in their approach. Regular meetings of this nature should be a recurring practice. In my present team, I take on the role of instructing on coding standards during our weekly meetings, and each team member possesses a copy of my book for reference.

3. Promoting Constructive Code Reviews: Fostering Growth and Collaboration in the Development Community

Code isn’t looked at by another party enough. Even when it is, egos are huge in the development community. People think that “attacks” on their code might as well be attacks on their skills or person. Developers need to let that go.

Let’s be honest; we all have egos, and they come in various sizes. Consequently, when someone criticizes code we’ve poured days, weeks, or even months into, it’s natural to take it personally. Such feedback can feel discouraging. What exacerbates the situation is the manner in which developers provide feedback or critique the code. Regrettably, some developers employ this as an opportunity to assert their superiority or establish their value within the team. These individuals incessantly attack without offering genuine solutions or constructive criticism. This approach leads people to withdraw, cease listening, or, in more severe cases, seek new job opportunities, resulting in a loss of valuable talent for the team.

It’s noteworthy that there isn’t a formal education on how to conduct code reviews without demoralizing the developer who authored the code. I certainly didn’t encounter this in any class or workshop I attended. If you find yourself in the role of reviewing code, it’s essential to approach it with composure and professionalism, just as you would want your code to be reviewed. Provide helpful examples, direct the developer to relevant resources, and aim to assist rather than condemn. Remember, our primary objective is mutual growth, regardless of our experience levels. If you are the one receiving feedback, maintain composure, actively listen, and don’t hesitate to seek clarification on aspects you find challenging to understand.

4. Enhancing Code Quality: Enforcing Strict Check-Ins and Analysis in Source Control

Do not allow code check-in if the standard check fails. Strict coding editor to follow standards. Regular coaching and mentoring. Code review and sharing the improvement plans.

I find the concept presented in the first sentence of this suggestion particularly appealing. Given the consistently subpar code quality I encounter in most of the projects I evaluate, it would be a game-changer if source control platforms like GitHub incorporated checks preventing code from being pushed to the repository until these standards are met. As far as I’m aware, no existing source control program currently offers this functionality. I conducted a thorough review of GitHub actions and found no such feature.

For Microsoft .NET repositories, implementing this could be a straightforward process, enabling the seamless execution and configuration of Microsoft’s StyleCop and Analyzers prior to code inclusion in the repository. Furthermore, having the flexibility to run third-party analyzers, such as CodeIt.Right from Submain.com, would be a valuable addition. Here’s to hoping that the GitHub team comes across this article and considers these suggestions.

5. Fostering Developer Engagement and Cultivating a Culture of Code Quality

Engage developers and develop a culture of quality.

I make a concerted effort to promote this approach within the teams I collaborate with, and I consistently incorporate it into my conference sessions. I’ve also applied this philosophy during my tenure as an instructor at a local university. However, it’s important to acknowledge that such initiatives are often attributed to individuals like myself. Sadly, I seldom encounter an environment where this mindset is actively cultivated within teams, primarily because code quality is not typically perceived as a marketable feature.

In fact, I’ve previously authored a comprehensive article titled “Code Quality Is a Feature, Not an Afterthought” to address this very issue. Unfortunately, many managers prioritize features over code quality, as they believe features drive product sales. As developers, it becomes our responsibility to advocate for a balanced approach, emphasizing the importance of code quality alongside feature development, as we ultimately bear the burden of bug fixes and feature enhancements in the long run.

6. Cultivating a High-Performing Development Team through Passionate Hiring

Ensure you have a team of developers who care about their craft and who care about the product they are developing. There is an intangible yet distinct difference between a developer punching the clock yet adhering to team coding standards; and a developer who truly cares about the work he/she is doing, and funnels that care and concern into creating the best solution he/she can.

This is an essential concept, and in my opinion, it should be integrated into the interview process from the outset. I delve into this topic in greater detail in my book titled “Rock Your Career: Surviving the Technical Interview.” In every interview I conduct, I ask specific questions to assess this quality in developers. Hiring a developer who lacks dedication to their craft can be highly challenging, and in certain cases, even impossible, especially if the team operates within a government context. Therefore, evaluating this aspect should be an integral part of the interview process.

In today’s landscape, the typical team size ranges from 2 to 5 developers, as per my survey findings. Even a single developer on the team who merely “punches the clock” can significantly impede the entire team’s progress and project timelines. While I understand that there is a shortage of developers in America, this shortage should not serve as an excuse to hire individuals who do not align with the team’s values and the company’s ethos.

7. The Importance of Continuous Learning and Evolving in the Software Engineering Profession

Learn, learn and learn more, never stop learning. Keep evolving. Practice by refactoring your own code.

If this quote doesn’t resonate with you, it might indicate a mismatch with your chosen profession. I emphasize this point extensively in my conference sessions and in my books. Our world evolves continually, and to stay relevant, constant learning is a necessity. That’s one of the reasons why I’m passionate about being a software engineer – the infinite opportunities for learning. No one can possibly know everything, which means the journey of discovery is unending. It mirrors my love for playing the guitar; there are countless songs to learn.

However, it’s crucial to acknowledge that this pursuit can also be quite stressful. I recall one of my professors referring to it as “techno-stress,” a term that has stuck with me and one I can relate to wholeheartedly. Being an “older developer,” I’ve found that keeping pace becomes more challenging with age. It often necessitates a more selective approach to learning, and sometimes it might take a bit longer, which is simply a part of the aging process. When I began my career, programming was far less complex. As software proliferates, it naturally becomes more intricate. This is why I advise beginner students or developers to initially concentrate on the specific technology stack that piques their interest. For instance, if mobile app development fascinates you, become proficient in that domain before branching out. Attempting to master all the stacks right from the start can lead to frustration and possibly a reconsideration of your career choice.

During the interview process, it is equally crucial for interviewers to pose questions that assess whether they are hiring developers who have a genuine appetite for learning and personal growth. I make it a standard practice in every interview I conduct. For example, one of my go-to questions is, “How do you stay updated with technology?” If the interviewee cannot provide a compelling answer on the spot, it raises concerns for me. I approach it from the perspective of being a teacher, trainer, and conference speaker. I can teach almost anything, but only if the individual is willing to learn. Given my past experiences, I prioritize hiring someone with less experience but a strong willingness to learn over someone with more experience but a resistance to growth. I learned this lesson early in my career, and it’s a principle I firmly uphold.

8. Balancing Perfection and Humility in Programming

Some of the old school programmers think they code perfectly.

This brings us back to the ego aspect discussed earlier. As developers continue to learn and advance in their profession, it’s natural for them to aim for excellence, and this is indeed a positive aspiration. However, it’s their attitude that can potentially become a roadblock. I’ve been part of teams where a developer holds a senior position primarily due to their longevity at the company, yet they have failed to evolve from their initial stages.

I want to clarify that I don’t want my readers to assume that I believe I write flawless code because I do not (and no one truly does). I readily acknowledge this because I maintain a constant willingness to learn and improve. While my articles, books, and conference presentations may convey a sense of perfectionism, it’s essential to understand that neither I nor my code is infallible. Instead, I approach my work with a deep sense of care and passion, striving to produce the best code possible, especially in my contracting roles. I recognize that my time with a project is limited, and I aim to leave behind code that is not only effective but also easy for others to comprehend.

9. Fostering Coding Standards and Code Quality in Computer Science Education: An Advocate’s Journey

Teaching kids from the start when they are learning in school, that standards and comments are critical and if you can’t follow acceptable standards, don’t apply. I see students naming their variables so stupid, and they should get a grade based not only if the code works, but in general… standards are practiced.

During my nearly 18 years of teaching programming classes at the University of California, San Diego, instilling good coding standards and architectural practices from the very beginning held great significance for me. In all my classes, including beginner-level courses, I made it mandatory for students to acquire my coding standards book. While I did make a nominal profit of around $2 per book, that wasn’t my primary motivation. My goal was to ensure that students would be well-prepared for employment opportunities upon completing the program, especially if they were interviewed by me, which did occur. Moreover, I consistently evaluated students in all my classes based on their adherence to coding standards and good architectural practices.

During one speaking engagement in St. Louis, Missouri, an attendee informed me that they were teaching coding standards at a college there. I was pleasantly surprised and heartened to hear about this practice.

Similarly, another college in San Diego, California, invited me to join their computer science advisory board. During our initial meeting, I candidly expressed my frustration that I couldn’t hire any of the graduates from their program. I half-expected that this would be my last interaction with them. However, at least one of the directors showed receptiveness and engaged in an extensive discussion about my concerns. Together, we devised a new program that would require all seniors to complete it before receiving their degrees, aimed at enhancing their employability. Unfortunately, just as they were about to implement this program, the college lost interest in the advisory board, leading to its dissolution. This is an unfortunate outcome for the students who continue to enroll in their degree program.

I firmly believe that teaching coding standards and code quality should be a fundamental component of any computer science degree or program. However, I recognize that this is not a widespread practice. If you have experienced a program that did teach these principles, I would be eager to hear your story. Conversely, if you are currently enrolled in a program that neglects this aspect, I am more than willing to offer assistance to any educational institution looking to incorporate these vital concepts into their curriculum.

10. Importance of Prioritizing Code Quality for Effective Software Development

The coding standard should be predefined in terms of both technical and non-technical aspects, including business test cases. Standard coding practices should be followed to ensure secure, robust, and maintainable software. It is important to incorporate comments and documentation in the code, and early discussions among developers, managers, and users, preferably documented on paper, can help establish coding standards.

Great caution should be exercised when making changes or adding features to the live system after deployment, as hasty modifications without proper documentation can lead to serious issues. It is not recommended to write CSS, HTML, and server-side scripts all in a single page; instead, they should be separated into their respective files or modules. When using third-party controls or libraries, it is crucial to conduct a thorough inspection, considering factors such as version compatibility and support. The code should be aligned with the specific business requirements. Additionally, it is essential to consider the target browsers and devices on which the software will run.

This comment encapsulates the essence of this article perfectly. I’d like to emphasize that the entire team, including management, must prioritize code quality right from the project’s inception and continue to uphold this standard throughout its lifecycle. In my experience, most developers recognize the importance of this aspect, but often, management fails to do so, as it’s not a feature that can be directly marketed to customers.

In today’s landscape, where data breaches, cyberattacks, service disruptions, and other critical issues are becoming increasingly common, the need for robust code quality is more pressing than ever. These challenges are only expected to escalate. Consequently, it is imperative to embed a commitment to code quality in all software development, even when end-users may not be immediately aware of it.

Summary

I trust that this article provides you with actionable ideas to implement within your team. You can find additional valuable insights in my coding standards book. Does your team adhere to good code quality practices? If so, I encourage you to share your experiences and thoughts in the comments below.

You can participate in my survey by going to the following link http://bit.ly/CodingStandards2020.