Since 2014, all my conference sessions have been wrapped around code quality. It has always been very important to me and I try to include a lot of that concept in my
coding standards book. Since that time, I have had developers participate in an online survey to see how they implement coding standards and enforce them. The last question I ask is “What can be done to make code quality better?”. I have lots of ideas on how to make it better, but I want to know what other developers think.
This article features those answers along with my comments. I really do hope that the Visual Studio and .NET teams at Microsoft will read this article so that they can make it easier to implement good code quality and standards. Let’s get started.
“Always need to test the latest features with unit testing integration. Proper code commenting.”
I totally agree with this. I would add that all features need to have unit testing integration. The .NET Framework does help with this by using the IntelliTests feature in Visual Studio makes it easy to add encapsulation tests (the first pillar of Object-Oriented Programming) by running the code and tries to break it the code paths. When I was working with the PM of this team, he told me that teams should strive for %75 code coverage. I agree with this and would add that all public and protected methods need to have at a minimum encapsulation unit tests. Unfortunately, the Visual Studio team did not make IntelliTests available in .NET Core. I hope they do, but I haven’t heard that they are. So, .NET Core developers are back to doing it all manually, which makes it very hard to reach that 75% goal and is why most code I see as part of my job have no unit tests or very little.
These days, I see no code commenting or very little. Code these days should be “self-documenting” which does help but does not remove the need for commenting the code from the developer who wrote it. Of course, keeping these comments up to date is also important.
“Better standards, better training, team meetings/training on coding standards.”
This suggestion is very important to make sure everyone on your team, including contractors, are on the same page. This kind of meeting needs to happen often. In the team I currently work in, I am the one that teaches coding standards in our weekly meetings and everyone on the team has a copy of my book.
“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 face it, we all have egos, some bigger than others. So, when someone attacks code we wrote, it’s very tough to not take it personally. We could have spent days, weeks or even months on the code and when someone points out all the issues, it can feel very defeating. What makes it worse is the way developers point out the issues or attacks it. Many developers use this to make themselves look superior or prove their worth in the team. These types of developers just attack and attack with no real solutions or helpful criticism. This just makes people shut down and stop listening or even worse, find a new job. Now the team has lost a valuable resource.
I’m not aware that the proper way of reviewing code so it does not attack the developer who wrote it is taught in any class. I certainly didn’t learn it in any class or workshop that I took. If you are the one reviewing the code, make sure to do it in a calm and collected manner in the same way that you would want your code reviewed. Give helpful examples, point the developer to resources that can help, etc. The more you can help, the better the developer will be. We are all there to train each other, no matter what level you are at. If you are the reviewee, also stay calm, listen and ask lots of questions on the parts that you do not understand.
“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 really like the idea in the first sentence of this suggestion. Since the code quality I see on most projects I analyze is pretty bad, wouldn’t it be great that if out of the box, source control programs like GitHub, would not allow code to be pushed to the repository until these checks were done? I’m not aware that any source control program does this. I checked GitHub actions and didn’t see anything.
For Microsoft .NET repositories, it should be very easy to enable and configure running Microsoft’s StyleCop and Analyze before the code is added to the repository. I would also like the ability to run third-party analyzers such as CodeIt.Right from Submain.com. I will keep my fingers crosses (I hope the GitHub team reads this article).
“Engage developers and develop a culture of quality.”
I try very hard to do this in the teams that I work for and I do this in my conference sessions, and I did it when I taught at a local university. But that’s me. I rarely seen this fostered in teams since code quality is not considered a feature. I’ve already written a full article about this titled “
Code Quality Is A Feature, Not An Afterthought”. Most managers do not care about code quality, only features since that is what sells more product. It’s our responsibility as developers to push back and make sure this happens since we will have to fix bugs and add features.
“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 important idea, and to me should be done during the interview process. I do talk about this more in my book titled
Rock Your Career: Surviving the Technical Interview. In
every interview I perform, I ask questions to try to evaluate this quality in developers. If a developer that does not care about their craft is hired into a team, it’s very difficult to remove them, sometimes impossible if the team works for the government. So, it must be done as part of the interview process. The typical team these days is between 2–5 developers (based on my survey). Even one developer on the team who is there to “punch the clock”, can really hamper the entire team and delay the project. I know that in America we have a shortage of developers, but that is not an
excuse to hire developers who won’t fit in the team and company.
“Learn, learn and learn more, never stop learning. Keep evolving. Practice by refactoring your own code.”
If this quote does not apply to you, you might be in the wrong profession. I talk a lot about this in my conference sessions and in my books. Our world changes every day! If you want to keep up, you have to be learning all the time. This is one of the reasons I love being a software engineer. There is no way to know everything, so the opportunity to learn is endless. It’s the same reason I love playing guitar… I can’t learn every song.
At the same time, this can be and is very stressful. I had one professor call it “techno-stress”. I’ve never forgotten that term and I suffer from it 110%! Since I am an “older developer”, this gets harder and harder as I age. I must limit what I want to learn and sometimes it might take me longer. This is just a part of aging. Back when I was starting out in this world, programming was a lot less complex. The more software is around, the more complex it gets.
This is one of the reasons I suggest to beginner students or developers is to first focus on the “stack” you are most interested in. For example, if you are really interested in mobile apps, become proficient on that stack and tackle another one later. If you try to learn all the stacks right from the get-go, you will get very frustrated and might want to find a different profession.
It’s also important that during the interview process that the interviewer asks questions to try to learn if they are hiring a developer who likes to learn and wants to evolve. I do it in every interview that I perform. For example, one of the last questions I always ask is “How do you keep up with technology?”. If the interviewee does not have a really good answer, off the top of their head, I won’t want to hire them. I approach it like this… I am a teacher, trainer and conference speaker, I can teach anything, but only if the person is willing to learn. I will always hire someone with less experience over someone who is more experience but is unwilling to learn (I’ve been burned by this early in my career).
“Some of the old school programmers think they code perfectly.”
This gets back to egos discussed earlier. The more developers learn and grow in their profession, the more perfect they think they become. Hopefully part of this is true, I hope they do get better. It’s their attitude that might get in the way. I’ve worked on teams where a developer has a senior position (mostly due to the time they spent at the company), but they have never grown from their beginner days.
I hope my readers do not think that I think I code perfect… I do not (no one does). I freely admit that since I am always willing to learn. I’m sure in my articles and books and even when I speak at a conference, I might sound like that, but I am not perfect, and neither is my code. I just have a lot of care and passion to make it as good as I can, especially since I only take contracting jobs. I’m there for a limited time and I want to leave behind the best code I can that is easy to understand.
“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.”
Since I taught programming classes at the University of California, San Diego for almost 18 years, teaching my students good coding standards and architecture right from the beginning was very important to me. In all my classes, I made my
coding standards book required, even in beginner classes. Sure, I made around $2 per book, but that wasn’t the reason why I did it. I wanted to make sure they would be hirable once they completed the program. Especially if they were being interviewed by me (which did happen). Also, in all my classes, since I taught them coding standards and good architecture practices, I did grade them on it.
Once, while I was speaking in St. Louis, Missouri, one of the attendees told me that they teach coding standards in college there. I was very surprised but very happy that it was being done.
Another college here in San Diego, California asked me to be on their computer science advisory board. At the first meeting, I told them that everyone I interviewed that went through their program I couldn’t hire. I thought that this would be my last meeting. But at least one of the directors there seemed receptive and talked to me at length about my thoughts. I came up with a new program that all seniors would have to go through before getting a degree, to help them be more hirable. They were about to implement my new program when they lost interest in the board and it was dissolved. This is very unfortunate for the students that continue to go through their degree program.
I do believe this should be taught in any computer science degree or program, but I really don’t see it happening. If you went through a program that did teach coding standards and code quality, I would like to hear your story. Also, if you are going through a program that does not teach this, I am more than willing to help any school get this added to their program.
“The coding standard should be predefined in terms of both technical as well as non-technical such as business test cases. We should use standard coding in the way such that it would result in secure, robust & more maintainable. Comments & documentation both should be used as well as early discussions between developers, managers & users on paper help to make our software code more standard. We should be very careful to add or remove even the small changes, features on the live system after deployment as several small changes in a hurry without documentation leads to serious issues. We should never write everything in a single page as some developers write CSS, HTML, and server-side scripts all in a single page. Using third-party control and can reference after careful inspection i.e., version and support. The code should be written as per business requirements. Browsers & devices should be kept in mind where the software will run.”
This comment, to me, sums up this article. I’d like to add that the entire team, including management, must make code quality important, right at the beginning and throughout the life of the project. In my experience, most developers are on-board with this, but management isn’t since it’s not a feature that can be sold to customers. It seems now that everyday companies are being hacked, data is being stolen, important services and sites are going down and more. This is only going to get worse. So, it’s important to build in code quality for all software, even if users are unaware of it.
Summary
I hope that this article gives you ideas that you can implement in your team. There are more great comments in my
coding standards book. You can participate in my survey by going to the following link
http://bit.ly/CodingStandards2020. Does your team practice good code quality? If so, please make a comment below.