Code Consistency for Better Software

Welcome to Building Better Developers, the Developer podcast, where we work on getting better step by step, professionally and personally. Let's get started. Hello and welcome back. We are continuing our season. We're getting near the end, but we are still continuing forward and we are talking about a couple of seasons back. We went through a lot of goals and suggestions for developers and now we're doing it with AI. We're throwing it out to chat. You'll be asking it what it thinks and we're having some pretty good conversations along the way. Who are we? Well, we are the developer podcast. We are building better developers is also known as I happen to be Rob Brodhead, one of the founders of development or also the founder of RB consulting where we are. We are a organization that helps you do technology better. Our goal is to step in, explain, help you explain what your business is, make sure we go through your processes, things of that nature. And then we're going to help you find a, you know, craft a roadmap basically is find a way to take you from where you are to where you want to be. And we're going to use technology to get there because once you have your processes defined and nailed down, then you can do things like simplify, automate, innovate, integrate. You can do all these things that allow you to change those processes around in a way that they become faster to, you know, faster to get done, more efficient. And of course that allows you more time to work on your business and also make your customers very happy, which makes everybody happy. Good thing, bad thing. Good thing is, is I've got a new, for those who haven't seen, I've got a new little mic that I'm testing out. The bad thing is, is that my setting that my setup that I'm working on as a mobile person and being able to just do this anywhere, haven't completely got it nailed down yet because zoom has some stuff that it doesn't like to do, which is one of the things we use for our recording. And I'm going to have to work on that and figure out, or I may just have to load some crap onto my phone so that I can be very phone centric. But someone who is not phone centric, although he is out in the middle of nowhere doing this, Michael, go ahead and introduce yourself. Hey everyone. My name is Michael Milosz. I'm one of the co-founders of Building Better Developers, also known as DeveloperNR. I'm also the owner and founder of Envision QA, where we help businesses run better by making sure that their software works the way it's supposed to. Whether you're managing customers, selling online, you know, running a clinic, we make sure that your software is reliable, it runs efficiently and it's easy to use. We do that by helping you, you know, improve your customer experience, more focused on growth and remove those headaches that might be in your software. And we do that by starting by getting to know your business. We kind of get in the trenches with you. We spend time really getting invested, understanding your business, understanding your processes and trying to figure out what your goal is. What is your why? What is it that you're trying to do? And then from there, we recommend the right solution, whether it's building a custom tool, fixing what's broken or automating your testing. At the end of the day, we help you prepare for a smoother launch or better improvement with your customers. Ultimately, our goal is to take care of the tech behind the scenes so you can focus on your business and not worry about your software. Let the software do its thing. You take care and focus on your business and making money and making your customers happy. If you want to learn more, check us out at EnvisionQA.com. Good thing, bad thing. So we are recording this today on September 4th, and today is the launch of Hollow Knight 2 Silk Road. And if you've been watching the news, it launched at 10 o'clock today and it pretty much took down every single game shop out there. So I have not been able to download it yet because the stores are unreliable. So that's the bad thing. The good thing is once it is reliable and I can get the software, I'm going to be able to play some new Hollow Knight 2 Silk Road, hopefully tonight. Well, good. I am not going to be playing that because I didn't even play Hollow Knight 1. So that's one of the things I'm behind the times. But I'm not behind the times on this topic. So this time around, we're going to talk about coding. The original topic's title was Coding Standards, Understanding Their Importance in Software Development. And we went back to ChatGPT this time. This is actually ChatGPT 5 that we're working on. I think early on we had a couple that were 4.5. We're now doing a little playing around with 5, just seeing how AI evolves. And this one starts out with the episode flow. It's giving us a little flow of it. Hook 1 to 2 minutes. Start with a relatable story. It loves to start with a relatable story. Imagine you inherit a project, open the code and every file looks different. Indentation, naming, even how errors are handled. How much time would you waste just trying to understand the style before you even get to the logic? Connect it to the audience. Developers want to grow their careers must not only write good code, but write code that's understandable and maintainable. Before we even jump into the next section, I want to say that I've actually found AI is really useful in these kinds of situations. If you sort it, once you've spent a little bit of time looking at the code, I've found some ways that you can get AI, some of these tools to say, hey, this is how I want it to be structured. These are some of my standards. And it can actually give you a pretty good starting point on becoming consistent because trust me, you don't want to leave the mess. You want to clean the code up that you're touching. That's just bonus material. Moving on. Defining coding standards. 3 to 4 minutes. Explain what coding standards are. A set of agreed upon conventions for style, formatting and structure. Examples, naming conventions. Camel case versus snake case file organization, commenting documentation, pro pro practices and learning how to speak English properly and error handling patterns. I think the these things can get like some people can feel like this is a little too much red tape. It's too much administrative stuff. Things like that. There's there's complaints because developers are like, darn it. I got to go make my code align with whatever the standards are. That's all fine. And Danny, I know everybody wants to be all creative and do code their way. But when push comes to shove and you're trying to look through code and figure out what it's doing, if there's not a consistency to it, then it's going to be harder to read. I like error handling patterns in particular. That's like one that drives me nuts when it's inconsistent and it has caused it causes problems like you would not believe when you get into like production and things like that. So if you're the person that's like, oh, I'm just going to like print something out to the console versus somebody that's using, you know, log for J or whatever that version, whatever the main logger is for your language or the person that's always shoving it out to messages that show up on your flow through and then show up on the interface or they get kicked back into some database table and get logged there. Actually, all of those things are fine. But pick one. Be consistent because it is really difficult when one section of code does one and another section of code does something else and then they don't always sync up because now they're doing it different ways. And then even the messaging early, early on when I was a developer, one of the things, one of the couple of the apps actually I worked with is they had every single message laid out. There was like a clued file of some sort, an I and I file or whatever it happened to be, whatever form it was in, like every single message in the system lived there. A lot of times there's errors. So you'd have an error code like a number and then you'd have a message and a number and a message. It seems a little old school and stuff like that, but it is actually really darn effective because then it's like always use the number, always grab that thing. You can use a lookup table and a database. There's a lot of different things you can do. But messaging and notifications in particular, it is so critical to be consistent. And it's even more so to do the notifications, the messaging that the users see because if they're looking all over the place and they're not seeing it right and sometimes it shows up and sticks around and sometimes you have to hit OK and sometimes it disappears after three seconds and sometimes it has an alert noise and sometimes it doesn't. People don't know what the heck's going on and they're just going to say it's broken. I think I saw something, but I'm not sure what I saw. They're going to ignore it. They're not going to give you useful feedback of it. I'm going to step off of my soap box now. But that I think is one of the areas that we overlook way too often and we need to make sure that we cover that like in code reviews and things like that. Michael, time for you to step up on that soap box. So right off the bat, file organization, it annoys me. If I want to go into an organization and they've got code that is not organized because most programming languages have some type of file structure organization that you need to follow. And if you're not following that, having new developers come onto a project can be extremely difficult. The other problem is if you don't have an agreed upon file organization, if you have things like containerization or things like that where you have specific paths for things, if you have your project one way and someone else has it another way, if you try to deploy to these containers, they're going to have to do custom configurations for where are the files located, where are you deploying them? You know, what is the path where a file is? You know, is it source? You know, if you're doing Java, you got simple maven. So you have standards that you have to follow to build a project. If you have a straight up just plain old Java application, you don't necessarily have a standard. You can do whatever you want for package naming structures and things like that. And that can be extremely difficult if you aren't all in agreement. The other thing is commenting and documentation practices. So many companies don't aren't really good at commenting or documenting their code. They either have an external to the code or they have it a little bit in the code, but it's not well maintained. They may have read me files. At the end of the day, get used to writing documented code. And by that, I mean literally write in plain English, write your code in a way that if you read the statement, you should almost be able to read and know what exactly your code is doing. It doesn't have to be 100 percent pure English, you know, because those could get long. But you can abbreviate enough or camel casings enough that you can understand what the code is doing just by reading the code. And then you don't need all these explicit or explicit additional documentation or comments in your code. But still, if you add something that has a specific meaning and it's not clear, document it, add a line comment. Six months from now, you're not going to remember what that is. And it's not like I know some people struggle. So I go, it's all this complicated stuff that I'm doing. It's like, then break it down. So it should be steps of like I do X and then I do Y and then I do Z. And then those can be function calls. So, yeah, maybe within those old functions or those methods, you've got, you know, five or ten lines of code that do something. But it should be like a nice unit of work. And you can just describe what it is. You don't have to get super detailed down to each line. But as long as those groupings have something, then you're off and running and you should have something that's going to be far more readable. And you will thank yourself in the future along with everybody that touches your code. So moving along, why they matter. We've already started on these a little bit. It says spend six to eight minutes on this. Let's see how this goes. Team communication standards are like a shared language. Reduce cognitive load. Developers don't have to decipher stylistic quirks. Maintainability, easier debugging and onboarding new team members. Avoid tribal knowledge locked in a single dev style. Quality and consistency. Consistency improves readability. Tools, linters, formatters enforce quality automatically. Professionalism and growth. Employers expect clean, consistent code. Following standards makes you stand out as someone who understands the bigger picture of software engineering, not just coding. I'm going to go right basically right to that last one. Cause I think that's one of the things is that as a coder and that's, I see this so often and there's so many projects I've picked up that that's the, that's the problem is the person that did it, or maybe it's a couple of people that did it. Sometimes it's like a chain of people that did it, but they were all individual developers. You can look at it and see that it was written by different people. I have been in situations where it's like, it was horrible. It was like, it was not only written by different people, but they use completely different libraries. They had a completely different approach. And so you have this big, nasty bloated code that covers all of these, you know, five different ways people were doing things. And you're never really sure which works. It's almost impossible to pull something out because you're like, well, if I eliminate that, I'm not sure what I break and what I don't. And it just becomes a complete nightmare. Part of being a developer of moving into being a better developer is being able to do so in a, a not sitting up in your ivory tower approach is doing it in a way that you are now much more a man of the people or of that kind of thing. It's you're part of the team that you're saying, Hey, we're going to do this together and it's going to look like it was done by a team or a single person. It's just like, if you hear somebody that you'll hear a band and everybody's playing different songs and different styles, it could be a jam session and it could be really cool, but it's probably not because even a jam session, there's still, there is a, there is standards within that. You're not going to hear a jam session that is like a waltz, somebody rapping, somebody playing jazz, somebody else doing hard rock, somebody else doing soft rock, you know, there will be different instruments and they're doing their own little thing, but there is some sort of cohesiveness to us. That's the same thing we want. We don't want to be just a bunch of random people making noise. We want to actually come together as a band, we'll call it, or as a, you know, as a group and build something that has that cohesive feel to it. It is so, so much easier to maintain something like that. It is easier to find bugs as something like that. It is easier to scale something like that. So that is where you become a professional developer versus somebody that can just write code is when you can do it and do it within a team aspect and follow some of those standards instead of just doing your own thing. Once again, I'm just stepping on soap boxes today. So I'm going to get back off and let's see what you're, where do you want to go with this one? Oh, my soap box is going to be the combination of the tools and clean and consistent code, because one of the biggest problems I have in almost any software shop I work in is when you hire on new people or you combine teams or your teams grow from one or two people. If you are not enforcing linters and formatters and having good, you know, source repositories and you are essentially managing how you want your code committed, how you want it formatted. If you do not use these linters and formatters and everyone has a different IDE and they're writing code, however they want, when you go to commit to your code repository, it's going to tell you that every single line in the file has changed when you change one line and it gets increasingly difficult over time to manage code review, know what the hell is really going on with the code per revision, really, if you are not using a linter today, start. Google has a whole library out there for just about every IDE. It's a good one to just start with. Because if you go with that one, regardless, if you've got visual code, IntelliJ, you know, Python, whatever, they have a linter for everything. And it works with just about every single IDE on the market. So you can pretty much say, Hey, go, if we're going to stick with Google, go grab the one for your language, install it in your tool and stick with it. Even if you say are using Java and you have like Eclipse and IntelliJ and visual code, even if you use the default linters that come with those IDEs, each one could be slightly different causing problems to just pick one, pick a particular format and apply it to everything. So don't rely on the individual tools. And then lastly, just make sure you document this in a Wiki or, you know, you're basically your coding standards so that everyone is on the same page. And when you bring new people on, make sure that that is one of the first things you do when you onboard them. I will just follow up on that because I did not mention this before, but I think it very much dovetails what you said is the whole idea of when you commit stuff in and it does a comparison, it's going to say everything's changed. What's worse is when you're having to actually merge stuff because one, you're not going to see the changes, but more importantly, if you don't have a standard style and approach, then you're not, it's, it is that much harder to merge code because you're looking at stuff, you're going, well, I'm not sure if this works. I'm not sure if this fits here and that fits there. And particularly then if you start to merge code that is different styles, you can have all sorts of issues with it. And I am just speaking from experience. I have cussed at many a person, sometimes myself even in doing some of these things where it's like, okay, we've got to like, let's get it straight. And using things like linters and that are static code analysis. Those tools are worth their weight in gold to help make sure that you get that stuff in place and just spend the time, just set up the hooks to make sure that when people are committing, that those things are going through their code reviews, that kind of stuff, make sure that those things are happening. It will make a difference and you will thank yourself. Common objection, objections and counterpoints three to four minutes on this one. Standards killed creativity. Creativity should go into solving problems, not inventing new brace styles. It slows us down initially maybe, but in the long run, it saves time for the whole team. Every project is different. Yes, but standards should evolve with context. Think of them as living guidelines. Having written in the last year or two, numerous standards and guideline documents and actually a lot of times they different organization, different team size and stuff like that, but there is definitely a common thread through them. And one of the things that is, I think that we haven't touched on yet is that standards can help us write better code. They can help us write stuff that is more efficient, that is easier to tune, that takes advantage of the language, the environment and things like that. If we stick to these standards, it not only makes our code tighter, but then it allows us to, it has us work within a structure that then other people have a better idea of what to expect from code they're not even looking at. There's certain things that you're going to expect. For example, an API, if every endpoint on the API is written by a developer in a different way, then you're going to get all kinds of weirdness. You're going to get some that want JSON and some that don't and some want XML and some don't and some kick out an error code and some don't and some have six different messages and one has it all in one big text that you have to parse. These things are, I'm taking it to the extreme a little in that example. However, it's not that different from what we're dealing with. I have worked in now, last few years in particular, several projects where we have not enforced stuff enough early on and that we've brought things in. We've merged some stuff. If you start bringing AI into the picture, it's not going to be standard compliant 99% of the time. And then what ends up happening is you have to like look at stuff and go, you just, what the hell is this? What, why is this done this way? And then you have to go clean it up and you have to say, okay, let's go make it look like this other stuff. You will also run into all kinds of problems if you're not doing this, if you're in one of these evolving environments, which is almost everybody now, because you may have Java that is now, you know, it's not standard. You're doing something that's been, you know, was 18 versions back and it's like, no, nobody should do that anymore. Python is like that. They're constantly evolving their stuff. React, like all of these things, Ruby, I've got all these libraries and all these tools and you're going to end up in your own little version matching hell. If you're not paying attention and making sure that the standards are also being updated and work with whatever your, your tool set and environment is. Thoughts on this one. So I'm going to go with every project is different. Yes. But standards should evolve with content. So I have talked about kitchen sinks all over the place and talked about, you even mentioned, you know, you need to make sure you refactor, you refine your code, break out those large methods. You know, if every project is different, yes. However, even if you have different languages, if you are writing something with specific functionality and you object by it correctly, be a, like a message queue or a database, your services layers, you have different layers to software, different ways of doing things. If you define your standards correctly and you break out your files and the individual implementations of everything correctly, then you should actually have a code library that you can pull from for all your projects. Everything should be standardized across the board. So like one project talks to my SQL. Well, you should be able to take that one piece of code and put it into another. You should not have to duplicate or better yet, you should be able to put that into a package and include that package into your next project. And then you essentially have your shared library that's used in multiple places. Sometimes that's good. Sometimes that's bad because you could have extensions of that, but you should be extending the code, not modifying the original code. If the original piece works, extend it. If you need additional functionality, that way you always have your core component. And then with that, you know, it slows us down. It doesn't at the beginning it does because you got to get everyone on the same page, but very quickly, you're going to find that defining standards saves the day because six months from now, if you guys are all on the same page, everything is being coded the exact way when you come in to another, an old project to pick something, you should know where to go. You should not spend a whole lot of time hunting and pecking. What is this spaghetti code? Because you followed your standards. I have nothing to contribute on that one. We're going to continue on, uh, partially from time and stuff like that. Cause this one actually gets into something I'm going to, it's a funnel area, how to implement standards six to eight minutes. Uh, it says start small, pick a winter formatter. We've beat this to death. Uh, adopt a widely accepted standard first like PEP eight for Python, PSR for PHP, Google Java style, uh, automate enforcement with pre-commit hooks, CICD integration, as we mentioned, reviewing code reviews, encourage don't police. We have episodes on that one. Uh, document standards in a contributing dot MD file. And so I'm going through this and looking at these now, one, uh, the standards I was talking about that I've done every single time I started with whatever a industry standards, I've done several Python standards and I went right to PEP eight, uh, actually use Google standards for several things. I've used Google, they've got stuff for Java, for CSS, for HTML, for PHP. I think I can't remember where all I got them, but all of those are out there and they really give you a good start and it's, you should be doing it anyways. That's part of being a better developer is doing the stuff that is industry standards. The industry norms. If you're a doctor and you're following industry standards, you're probably doing pretty good. If you're just out there doing crazy stuff, you're probably killing people or something like that, that you shouldn't. We're not likely to do it to that level, but those are things to think about. What I'm reminded in all this is back in the day, uh, many, many, many, many years ago when there was this thing that everybody was a big part of in some way, form or fashion that was called shareware. And there were all of these sites where you could go download software and do all this stuff. And a lot of these sites had standards for what you needed to include with your product. If you were going to post it on their site, if you go like America online just died, not too long ago, they were one that did that. They had, um, and I can't remember what it was, but it was things like you had to have a read me, you had to have some sort of like disclaimer, you had to have an ownership thing. You had to have like all these old things that all these documents felt like, um, you know, red tape or something like that, but they were very, they were very good about allowing somebody that gets this thing that downloads this thing to be able to understand where it came from, who to contact if they need help, what is the licensing around it? Like what can they do with it? What should they expect from it? All that kind of stuff. And we, I think got away from that too much. And I'm now seeing it again where like most tools, most IDs, they're going to, if they create a project, they're going to build you empty files for all of this stuff that you should be filling out. So like the simplest thing is, is when you next create your, you know, Java project out of the STS tool, look at the stuff that's there and like fill in the blanks. Don't cause it is mind boggling when you've got something that doesn't have documentation, but you've got a read me file that basically says, give me a copy of the project. Basically says give information for this application. This is what it should look like. These are the pieces of information. Like it walks you through it. It shouldn't take any time at all. And then it doesn't exist. I'm not even going to let you talk this time because we've, we're starting to run out of time and I know we can keep going. So the rest of you guys get to listen. If you come back, check us out on the YouTube channel. You'll get to hear more from Michael. I'm sure he's chomping at the bit to give you some bonus material. But we are running out of time. So we're going to go ahead and do our obligatory send us an email at info at develop a newer.com. Let us know what you think, where you'd like to see us go. If you have questions, I had a great question the other day that came through, uh, social media or something like that. Really interesting topic that I think we're going to have to look at at some point and figure out how to switch some of these, uh, our point of view, I guess around a little bit. And, um, these things are what make us help you better. They make us a better tool for you. So definitely send us your information, your questions, your, your feedback. Uh, you can check us out on develop an or.com. You can leave feedback anywhere there. You can leave it wherever you, wherever the fine stores that you find podcasts out on the development or channel on YouTube out and X we are at develop an or I think there's a Facebook page out there. That's the developing our Facebook book page. I forget all the places, but we're there. All the things as they say, as always, I appreciate the time that you've given us and we're going to give you some back. So go out there and have yourself a great day, a great week, and we will talk to you next time. Thank you for listening to building better developers, the developer podcast. You can subscribe on Apple podcasts, Stitcher, 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.