Coding Standards: Understanding Their Importance in Software Development

Welcome to Building Better Developers, the Developer podcast, where we work on getting better step by step professionally and personally. Let's get started. Well, hello and welcome back. We are continuing our developer journey and we've actually sort of like shifted around with the developer journey is this episode, we're going to talk about basically coding standards, development standards. How do you get the team on the same page when they're doing implementation? I and Mike across the internet here are on the same page and on the same team, co-founders of Develop and we're Building Better Developers. My name is Rob Broadhead. I'm also a founder of RB Consulting, where we help you assess your technology, where you at, give yourself a starting point, find a good like go from point A to point B and find ways to take all your technology through simplification, automation, integration, get that stuff manageable, get it maintainable, get it scalable, and then get you off and running on your roadmap into the future. In the world of good thing and bad thing, a bad thing I will go with first is that because it covered it was just in the last episode, some people will know, some people won't, is that a bad thing is starting a conversation on a podcast or something like that and not turning off your notify. So hit your do not disturb. If you wonder how it could go, I think it's only going to be on the record on the YouTube side, but you can see where we reference one of us did that or failed to do that and it causes some issues. So that's a bad thing is sometimes knowing how many times you do this stuff, you do stupid things like that. Good thing. Oh, let's see. A good thing was I have done like, it's a little bit of a. I've done like a spring cleaning kind of thing. I've gone sort of like my spring cleaning for my systems and servers as having this consulting company. There's multiple servers out there that we maintain. Some of them are essentially production servers for customers. Some of them are production servers for our own stuff. There's development servers, there's demo servers, there's all these different things. And we rotate through them a lot. There's a lot of stuff, things like move around and things like that. And sometimes that ends up being a pain in the butt because the next thing you know, you've got, if you're like me, you move stuff around because you move it from, you have like a multiple environments. You have a test, you have a development, you have a production, and those are on different machines and different machines have different things going on on them. And over time you've got just hoed all over the place. Now you've got it all in a nice social code repository and stuff like that, but you basically, it's like going in and playing with all the toys in a kindergarten room and you didn't put your crap away. So the good thing is I was able to spend a little bit of time and like put some of that crap away and clean some of that stuff out. So now I have like, you know, much more smoothly running servers because I finally got around to catching up with a little technical debt. I know I took too long on that. I apologize. So I'm going to have Mike to jump in and introduce himself. Hey everyone. My name is Michael Milosz. I'm one of the co-founders at DeveloperNer. I'm also the founder of Envision QA where we help companies unlock their software's potential through a comprehensive software quality assessment review and test services. You know, discover how assessing all areas of your software development teams from sales to QA can enhance customer satisfaction and improve software quality right from the initial conversation with your users. Good and bad. Well, the good summer situation. I have been in the process with my wife of decluttering the house. And so I decided to move into my office and start decluttering my office. And I probably just got rid of about a thousand CD DVDs that I had stacked up that I have not touched in a decade or so. Just quickly went through them. I did find some pictures that weren't digitized yet, um, or not stored in the backup summer. So that was good. Uh, bad side. I have so much more to go. Okay. I've got terabytes of hard drives just sitting around that I still have to go through and figure out what I need, what I don't need. So like you said, it can get out of hand. If you don't keep up with this. I just recently did a similar kind of cleanup and there were, I had, uh, floppy disks, three and a half inch floppy disks. I had five and a quarter inch floppy disks. I had, uh, I had the Microsoft developer network stuff where they used to be able to subscribe and you get all other things. So you had office and you had all the development tools and you had all the operating systems and you had all the databases and it was from like the late nineties. So I had like windows 95, windows 98, windows, blah, blah, blah, blah, blah. I just had, I mean, there's just big boxes full of CDs or DVDs, whatever they were. And it was just like, okay, I guess I can't, you know, I could, I guess I could try to donate them somewhere, but I don't know who even would even be able to use those. So done the same thing. This episode, we got to continue. We'd probably actually get back to our topic and our topic. I totally forgot what our topic was. No, actually I did a little bit. Give me a sec. Our topic is we're going to talk about voting standards. There we go. Sometimes we get really off the rail. Do not cut that out. I think everybody knows that we all sometimes get off track. The train goes off the rails and we got to get back on track. Coding standards. So this is something that every one of us, I think, complains about when it's not followed. We also complain about when we have to follow them. It's like, it is a love hate or a hate hate relationship, however you look at it, because whenever we walk into a new project, we're going to say, gosh, it looks like 15,000 developers were coding on this. There's nothing that makes any sense. It doesn't have any rhyme or reason. You can't find stuff. Well, you know how you fix that problem is you have coding standards. You have something that says, this is how we are going to name things. This is how we're going to lay stuff out. This is how we're going to, even a lot of times you can get it like, this is how we're going to approach certain usage of like frameworks and problem solvings and things like that. And yes, it can be things like a code template that says every time you create a class for this language, you start with this template and you're going to have a header and you're going to have some footer stuff and you're going to have all these things and this is what comments look like. These are the tags that you should have. And all of that stuff is very useful, but along those same lines, which it's and say, okay, well, what do I do? Do I just like walk through code and say, this is how you code everything? No, what you want to do is you want to make sure that you are going through and essentially like, think of it almost like a punch list of if I wanted to set this project up, what are the things that I need to do? And that's where you're going to get, you're going to lay out your development standards, your programming standards, because this is going to tell people when I'm writing code, what should it look like? Where should it go? How does it progress through coding, testing, and all those kinds of things? And those are the pieces that you need to have as part of your, whether it's your document or these days, it could be part of your CICD flow. There are sometimes things you can automate a lot of this. You can process, process size. You could turn into a process. A lot of these things that is an automated process of some sort or another. And some of the things you want to look at, and we have talked about these in the past, but there are tools, like I mentioned, there's like CICD kind of stuff, continuous integration and deployment. There are things out there that can help you force developers into following standards. Now there are automated tools, like there are like Lint tools and stuff like that. There's static code analysis stuff that you can with a lot of, in a lot of places, you can actually build that into your commit process. So it's things like if you do a pull request, you can, you know, you commit your code up, then it's going to run through some processing and kick some stuff back and say, Hey, you didn't follow the pro the code, you know, the coding standards properly. There's a guy, there's a project I work with that it was so strict that it was things like all of the formatting of the code was built into it. So you could not successfully commit code into the version control. This, how old it was, was SVN into SVN without it passing this essentially like sanity check. And it did, it did like spelling checks. It did spacing. It did, it made sure that everything followed the right format. So if you, you know, not to get too deep in it, but things like, you know, do you put something on the same line or do you have to put another if, you know, a line after every if, or do you do a, at the end, like an open bracket, is that on the same line or do you push that to the other line? How do you indent? Do you use tabs? Do you use spaces? All of these things that a lot of your IDEs will now provide that for you. That can be part of it. And that's the nice thing about these IDEs is you can actually build these into IDE properties. So you just basically say, upload this thing, this file, and it's going to set all your defaults. It can set all your warnings. It can set errors and things like that. So as a developer, they're going to be able to see that, Hey, I am falling out of the standard. You also want to make sure that you have the, the path of code is also part of your standards, besides just the actual coding process that we talk about, like writing code. And is it, you know, is it readable? Blah, blah, blah is what do I do? How do I go from a requirement into implementing something and then eventually getting it deployed that you may not have all of that as part of your coding standards, but these days, particularly if you're in an agile environment, you actually will, or you should, you should have some sort of a process that's documented or in some way to say, Hey, I am, I've grabbed a ticket, I'm working on this ticket. I'm coding this ticket. I've committed code for this ticket. It has been tested or like maybe it's, I have tested, have been submitted for it. It's been tested. It's been verified. It's been pushed into a release and blah, blah, blah. With all of that, there are things like just, I mean, you can go a little bit nuts, but there are things that are important like that, like what does, depending on how you control your version control repositories, what does a branch look like? When do I branch? When don't I branch? When, you know, how, what is, what is involved in a, a pool request, a pool request and in accepting one of code reviews, what does a code review look like? How many people needed to code do a code review? These are all things that I think we, we don't think about when we're coming out of school because we don't have teams at that level of professional development. And a lot of times we get into the real world. We don't think about it because we're so focused on our project, our tasks. And so it almost has to be the organization or the manager or whoever it is needs to like push that forward with the team. As you get further along, as you're doing side hustle projects, as you're doing, maybe getting to consulting and you're jumping in and out, then that's one of the first things that you should think about if you're doing your side hustle project is like take notes along the way and craft your, you know, your coding standards, so you have a template and you've thought about it. If you step into something at a customer, whether it's a new job or consulting or something like that, that should be one of the first questions you ask is, are there, is there some sort of coding standards document? Are there templates I need to use? And it, those kinds of things are going to help you immensely. I don't know how often I've walked into something where there's not a standard, for example, like standard coding structure. And so one developer has got all their code in one place and another one's got in another, and then they've got all these I and I or setting files or whatever they are, sometimes it's hard coded in it. All of these paths that then you've got to go and, you know, undo those. Now these days, usually people are extract those out to setting files, but then it's still, it's like, okay, I got to go tweak all my setting files and I gotta figure out which setting I can use and which don't I, and when do I can, when can I connect to this database and when I do I need to connect to my local one? Those are all factors. Those are all facets and properties of a good coding standards document or process. So I've thrown a lot out there and now I'm going to let Michael sit back there with his big baseball glove and catch all of that and, you know, play around a little bit and give us something back. That's a little bit more, maybe a little bit more intelligible. Sure. One of the things I would like to add on is a coding standard. If you're in an agile environment and you're really building your quality controls in your processes within your coding standards, it also becomes like a code of conduct for your team. Everyone agrees to these. So when you're doing those code reviews, everyone's hold, hopefully holding everyone to the same standards that you all agreed to. So if you have good quality standards to find, you should all be following that. And then you should hold each other accountable for it. So I want to take this a slightly different direction. So we've talked about what are good coding standards. If you are new to larger enterprise corporations, you're just out of school or you have been working at one company for a long period of time, and you're kind of set in your ways based on the coding standards of where you're at. Going into a new job, a new company, or even a new side hustle. There are some other things to consider about for coding standards. One, if you define really good coding standards, it doesn't matter what type of development tool you use. IDE could be visual code, could be Xcode. Doesn't matter. If you define the styling you want, you can, all these ideas these days can ingest in the XML style sheet standard, and then apply the same coding styles to whatever IDE you use. So if you like visual code, you can use visual code. You like Eclipse, use Eclipse, Xcode, and so on. The other thing though is, so as I was talking about coming into a new job or switching to a different environment, one of the things from a new employee's perspective is treat your coding standards. If you don't have them, treat your environment as if it's a new person coming in. How are you going to train them on using your system? If you have really good coding standards, you should almost be able to hand that to them, walk through the code, walk through the coding standards, and boom, your employees are quickly up to speed writing code, hitting the ground burning within days, not weeks or months. If you don't have that, what typically is going to happen, you're going to bring in a new employee, you're going to say, here, go look at how, or go look at the application, figure out how it works. And then we'll slowly have people sit with you and kind of walk through what they do and here's how the code works. Here's how we do our development environment, et cetera. Good coding standards from a new install, a new employee perspective, you're forced to kind of write that checklist. How do I set up my development environment? How do I check out my code? How is the code style? These are some of the basics you need. And if you think of it from the mindset of a new employee for training, it's so easy because all you literally are doing is you're building your checklist. You're walking through how to essentially do your job at this company. And you're essentially writing the handbook, so to speak, in these coding standards. Now, when you get into the continuous integration, using different frameworks, things of that nature, having these kinds of templates is very crucial to keeping things moving quickly. So if you do a lot of API development, a lot of backend development, having good standards around what is an API. What are the protocols you use? How do you return response messages? When do you hide certain response messages so you're not returning critical customer data back to the end user? Or how do you handle SQL injections? How do you log into an application? How do you pass things? There are other things with coding standards that are not just about the basics, but also about the functionality within the system. How do you handle things? If you're having to deal with medicine, you have to deal with HIPAA. How are you applying the HIPAA guidelines to your coding standards to ensure you're basically protecting all that patient data and not having logs, log, you know, social security numbers or credit card numbers and things of that nature. So those are some of the other things that you can unpack within good coding standards. And like I said, you know, as you bring new people on board, it's so easy to hand it to them. They can get up to speed real quickly. Or even if you're working across teams, if the organization has good coding standards, it should be fairly easy to go from one team to work with another team. And your project should hopefully integrate smoothly together. Now, a couple of bonuses here I want to mention is one these days, as Michael mentioned, it is very it is easier than ever for you to put these standards into your ID, whatever it happens to be, and effectively hit, you know, reformat or something like that, or look at the output. The we'll call it the problems and be able to walk through and see where did you fail to follow the standards. Another thing that we haven't touched on, there's actually a way to maybe make this stuff even easier is through containers or infrastructures, a code or something along those lines. Well, yes, you can use you can use all of these things, you know, Docker and all of that. And, you know, K8 and all of those guys, you can use all of that to do a very an enterprise system that's got all of these nodes and all this stuff to scale something up. What you can also do is you can scale your development environment. And this is sometimes a very easy way, particularly if you think of like Docker desktop or one of those things where you just say, you know what? We're going to have you we're going to give you a Docker compose, just a little YAML file. And you go watch that thing and it goes out, it grabs all the code down from, you know, from whatever your repository was, sets everything up, puts it in all the right folders and everything else. And it's just like, that's where you live. You can try to copy stuff out and have your own separate development environment. But really, you live there. And it's so much easier for developers to do that. Actually, it makes it a lot easier if you are a if you're in a team where you're you know, you've got multiple members and you especially if you've got people sort of flowing in and out, or if you've got people who's going to work on something for a while and then they need to be done and you move, you know, move on to something else. You don't have to spin up machines. You don't have to even spin up your own VMs. You can just say here, take this, install Docker, execute this thing. It's going to run. Here you go. Boom. Everything's going to be the same. You're you're able to say, here's where we're at. And at least your your infrastructure, your structure and a lot of that, those kinds of things that become a pain. Things like even things like the the system setup. So what are my system settings? What's my time zone? What are like those kinds of things, particularly if you're dealing with web development, for example, like what sort what version or actually almost any development of these states, what version of all of these libraries and all these frameworks am I dealing with? And, you know, I mean, you're sitting there probably pulling your hair out if you've done like a React app that's got 18 different or that's actually a small one. It's got like 40 different modules in it or Python. It's got a, you know, a requirements. Text. It's like a hundred lines long. Or if you're dealing with Java and you've got all these imported little libraries or you deal like Ruby, if you've got all the gems and all that kind of stuff. It is so much easier to just have that environment, particularly when you start dealing with like upgrading and things of that nature, because then you could just do it once, get it fixed, get it working, and then just go, here you go. Here's the environment. Knock yourself out. It allows you to really focus on the configuration types of things that take up so much of our time. You can just get that done and knock that out of the list of things that you have to worry about as far as a developer. Closing thoughts from you? Yeah, I'm glad you brought that up because I have actually built that and I've talked about that in prior podcasts where we have built custom development environments and we essentially rolled it out as either images for desktops or containers and so on. Only caveat with that, and this will be my final thought, is if you're going to go the automated route and use containers or automation, make sure you document and standardize what it is that you're going to be doing with that. I have been in situations and in a couple of different companies where they didn't have a standard for that. Someone implemented it a year or two ago. They left and now no one knows how it works. It starts becoming unstable and then you actually spend more time trying to keep your development environment up versus actually doing your job. So again, coding standards help with all of this. Standardization is key regardless. It can be for continuous integration, how your code styling is, but just make sure you do document whatever you agree to do. And that's, I know everybody hates to use the D word, but yes, document that stuff. Honestly, even if you've got something, these kind of situations, if you get into automated environments and things like that, then just make sure that you've got something that says, here's the scripts that you run and just make sure that you don't have magic stuff in those scripts. I have dealt with those. I've been in the same situation where you've got the developer disappeared long ago and particularly, I'll just throw one example up and then we'll go out there and we'll move on. But it was a combination. So you had these containers that built up your environment and it wasn't a simple environment. There was three or four servers involved and there was a Jenkins server that was involved that did some of the building to some of this stuff. And those things had to be in sync. And there was some calls back and forth that if you didn't have everything in place, it's going to be a little bit of a problem. And there was some calls back and forth that if you didn't have everything in place, it didn't really make sense. And those are the things that you need to make sure, for example, like if there's like settings files that are required or if there's path, that's probably the one I've seen more often than not is there's path or environment variables that are expected to be there. And if they're not, it just blows up. So make sure that you document it, make sure that you have proper error codes and make sure that you've got ideally that you've got a document or a video or something that says this is how you walk through the process and what it should look like. Those are the kinds of things are going to save other people in the future. Even if you walk away, you can just say, hey, that document, if you walk through that, it should work. If it doesn't, then something went wrong. And of course, the nice thing is you can test that by just give that document to somebody and say, okay, just take this or do it yourself. I've done this several times. When I build those documents, I go to a completely clean machine, walk through the steps. And if it doesn't work, then I got to fix it or I've got to update the document. You, if you don't think that we work, can update the document of us by sending us an email at info at developer.com. Yes, that is quite a stretch to get to that, but we got there anyways. Just like however far you have to go to get to the internet, which shouldn't be very far, go out to developer.com and you can check out all of our content. You can go to school.developmentor.com, then check out the more organized content that's there. You can leave us comments. You can leave us suggestions and wide open on that. Whether you want to look at some of the topics we should cover, some of the things we shouldn't cover, some of the things that you'd like us to go back and do as part of our mentoring series or part of our training type series, you name it. We're more than happy to hear from you and see where we can use this platform. So help us help you become a better developer. As always though, I want to go out there and become a better developer, a better human being, even have yourself a great day, a great week, and we will talk to you next time. Amazon, anywhere that you can find podcasts, we are there. And remember, just a little bit of effort every day ends up adding into great momentum and great success.