The Modern .NET Show

Episode 85 - Clean Code in C# With Jason Alls

Embedded Player

Episode 85 - Clean Code in C# With Jason Alls
The .NET Core Podcast

Episode 85 - Clean Code in C# With Jason Alls

Supporting The Show

If this episode was interesting or useful to you, please consider supporting the show with one of the above options.

Episode Transcription

Hello everyone and welcome to THE .NET Core Podcast. An award-winning podcast where we reach into the core of the .NET technology stack and, with the help of the .NET community, present you with the information that you need in order to grok the many moving parts of one of the biggest cross-platform, multi-application frameworks on the planet.

I am your host, Jamie “GaProgMan” Taylor. In this episode, I talked with Jason Alls about clean code, what clean code is, how to keep your .NET code bases clean, and his recent book Clean Code in C# - so you could say that he is a bit of an expert. Along the way Jason helped describe what clean code actually looks like, and shared some of his top-tips for keeping you code clean, and why that’s important in long-lived code bases.

The audio for this interview ended up a little rough in places, but our Editor (Mark) has done the very best that he could. So I ask that you stick with it, because Jason has some really good points to make.

So let’s sit back, open up a terminal, type in dotnet new podcast and let the show begin.

The following is a machine transcription, as such there may be subtle errors. If you would like to help to fix this transcription, please see this GitHub repository

Jamie

Thank you ever so much, Jason, for joining us today, I really, really appreciate when anyone could take some time out to talk to us because, you know, everyone’s really busy. Regardless of what’s going on in the world, everyone is really busy, right? And so I really appreciate it. We’re gonna talk a little bit about your career, and a little bit about the book that you’ve just released. But like I say: welcome to the show, and thank you ever so much.

Jason

Thank you.

Jamie

Okay, so would you mind, maybe just letting the listeners know a little bit about you? If that’s alright, a little bit maybe about your a little bit of background? Or maybe, you know, things like that just so that then the listeners know a little bit more about you as they’re listening to the show. Is that okay?

Jason

Yeah, it’s great. I’ve been programming since 1999. Now, the main programming languages I’ve used are Visual Basic Six, Visual Basic .NET, when it first came out, and Visual C#, HTML, JavaScript, CSS, and Angular, as well as some Java. My preferred programming language is most definitely C sharp. And my favourite programming environment is Visual Studio. You have used them over environments. But I just really like Visual Studio, with the way it’s got debugging features. And with C# it is so nice and so clean, and it’s really powerful. I like the way you can organise your C sharp files, the syntax works well for me. Plus, I like the tools and capabilities, especially when it comes to desktop applications. I juse love developing, like your WinForms, WPF; just really, really nice tool to use.

I’ve developed a number of applications that include reporting applications, back end software, mobile job tracking software, for field engineers, document management systems for law firms, banking software for data migration between Oracle and SQL Server databases, and educational software, which I’m currently working on now that tests for dyslexia, through the use of tests are like games, which is quite interesting to work on actually. And on a personal level, I like walking, gardening or doing astronomy, I have also dabbled in making a bit of music, which you view on Bandcamp at mebsuta.bandcamp.com. And also used to take part in chess competitions and did win a few. So that’s a bit about me.

Jamie

Awesome. I always do like to hear a little bit about what people do outside of development; because I’ve noticed that there are a lot of people who work as developers, technologists, in technology, however you want to put it, who are also really creative outside of that. So I mean, the listeners can’t see it, but earlier on before we started recording, I moved my camera around, and I don’t know whether you noticed, but I do have a bass guitar sitting right next to me and a flight case. Because, you know, I dabble with bass a little bit. And I found that, that there’s almost like a, I would say around a 50/50 split I think, of developers who are also interested in music. And I wonder if that’s because, you know, music is one of those wonderfully creative things that you can, just like with programming: you start with nothing and end up with something, right?

Jason

Yeah.

Jamie

But it also follows a really strict set of rules, as well. And I think programming kind of helps with that, too. You know, there’s only certain… that you have so many data types. And you know, as we’ll maybe discuss later on, you have rules about how to make your code clean and be usable. And I’m sure that there are probably rules about how to make your music - for want of a better phrase - clean, but not any music sense. But like clean, easy to listen or things like that, you know, I’m sure that there are similar rules in place.

Jason

Yes. A lot of as well is actually driven by mathematics from what I’ve read up.

Jamie

Yeah, I remember. So before, like, straight out of uni. I spent a little time and did some teacher training and I was in the maths department. And one of my tasks was to build connections between maths/math - depending on because there are a lot of American listeners - between the math department and different departments throughout the schoo. And one of the things that.. I made like a big poster about was, “music is kind of just maths but for your ears.” You know, a musician uses maths to great wiggly air, and the wiggly air is then picked up by your ears and converted back into the sounds that the musicians originally envisioned, you know. And somehow that affects your emotions and stuff like that. So there was this one, like, big, I want to say A2 poster that I described how maths and physics and music are all sort of intimately related.

But okay, so we are here to talk a little bit about a book that you’ve released recently. And I was wondering, do you have like a maybe an elevator pitch for the book? I know that it is called “Clean Code in C sharp.” And, you know, for the background of the listeners, I have read the book full disclosure, I have read it. But obviously I’m going to be asking some questions as if I haven’t read it right. So would you would you mind if you have an elevator pitch for it, giving us an elevator pitch for “Clean Code in C sharp.”?

Jason

Yeah. From my experience in working with various pieces of software in different companies, you see a wide variety of code. Some of it’s like really easy to manage, really easy to expand. And people love working on it. Then you go other code, and it’s really intermingled, really hard to untangle. You can’t expand it. And it’s just so hard to work on. And so when your company and your livelihood is actually the code base, the one thing you don’t really want is a high turnaround, because your code base is really horrible. And people just don’t want to work on it. And the last thing you need as well is to be having a flagship product, where it’s absolutely your bread and butter. But it starts creaking. And getting to a point with capacity, for example, where we just cannot take the strain, where you can’t really do anything with it other than completely rewrite it from scratch. So you’ve got two potential ways forward.

One is to actually refactor your code, so that it’s really nice and clean and tidy, where you take all the dead code, and where it’s like properly laid out so that anybody who comes in, can read the card, easily find where things are, and start working on it and maintaining it. Or you can go down the road of starting from scratch, writing code, using clean, and solid principles, for example.

But also, as a developer, there’s been like situations where programming teams have developed software thinking is what the customer wants. And then when it comes to delivering the software, it’s like, “well, we didn’t ask for this.” Well, that’s what the specification says. You see because with human language you can have the same thing, but different people can interpret it differently. And so that’s where the beauty of like TDD and BDD comes in. Because with test driven development, obviously you know what the code needs to do; to do so you write your test. And obviously, it fails at first. And then you write the code, just the bare minimum to me about code work. And then once it’s working, you refactor as you need to. And we’ve behavioural-driven development, obviously, you’re given a specification, and you are only writing your code to that specification. So when you actually have finished writing your code, whatever to deliver to the customer, that is exactly what the customer wants.

And so with this book, there’s like, tips and tricks for like writing clean code, just in general terms. But also as an aspect of writing code, using like TDD, and BDD. And so that, as a programmer, you’re gonna have a confidence, one that your code works, when you actually release it to the quality assurance department. But also, you know, that whatever the business has asked for, is exactly what you’ve developed. And so in that sense, your code is clean, because it only contains the work the business requires of you; it doesn’t require anything else. But also, if you like, come to work on code, and is thinking like, well, I need to refactor this, because obviously, the code is creaking. And we’ve been asked to make it work better, then there’s lots of tools and tips and techniques to help you to actually do that. And there’s also like addressing cross cutting concerns, for instance, like security, that sort of thing, where you can’t really put in a particular layer, but if some of us got to be addressed across layers, and there’s tools in there that will help you actually use Aspect Oriented Programming, so that you can actually take care of us concerns about cluttering your code as well. There’s also like, information, identifying poor quality code that needs to be refactored. And how you can actually secure your API keys to protect your data using things like Azure KeyVault. And also, it talks you through as well, various tools that are really good at helping you to refactor your code.

So yeah, so there’s quite a lot in there. The book itself is, it’s not so much a theory book, but it’s more geared towards giving giving you like practical experience. So that once you’ve gone through it, you’ll have the confidence to actually look at your own code. And maybe think about ways in which your own code could be tidied up. But also when it comes to like working with legacy code within a business, or if you’re looking for ideas like on sites like GitHub, where you’re looking at third party source, you can take that source, and look at it, and then just see if there’s ways you can actually improve upon and actually do better. Because a lot of code when you working, like a lot of the places where I’ve worked, we’ve been that much under pressure. having to meet targets and deadlines, sometimes you just have to sacrifice clean code, and then come back to it and refactor when you’ve actually got the space to do so. That’s usually when you have like a technical debt release that kind of thing. But this book will certainly help you, one to understand code smells, and the kind of things to look out for; how to actually refactor to make such smells clean. And also how, from the start, to implement solid principles so that the code that you do actually write is actually clean from the actual start. But also how to use tools that can actually identify problems that you even dream of actual issues so you can actually improve your code. So that when you’ve actually got your finished code base it is actually a really nice code base; it’s clean, it’s easy to understand, it’s easy to maintain, and it’s also a pleasure to work with.

Jamie

Excellent. Like I say, I’ve read the book. And I’ve got to say it’s a, that’s a really sort of succinct way of describing it if I’m honest. So the yeah, brilliant.

So if I’m thinking, “I’d better pick this book up,” do I need to know any of like, what clean code is and solid principles, and things like that? Do I need to know that these tools exist already? And these practices exist already? Or is it more a case of, “okay, so let’s talk about what solid means?” You know, a lot of people throw that word around. And, you know, I was in a conversation with someone a few days ago, and they’re like, “yeah, just using solid principles.” And I’m like, “okay, let me stop you there. What’s S mean?” And they’re like, “err…,” and that’s not a bad thing. It just, I feel like it’s just a term that gets thrown around. But does someone who’s reading this book need to know about those beforehand? Or are you taking them through what these things are?

Jason

The thing I don’t like about a lot of books is you’re required to have a lot of knowledge beforehand on a particular subject, before you’re actually attacking in the actual book itself. So the approach I’ve taken with this book is to introduce people to topics, so they don’t actually need the knowledge upfront, and provide enough to lay whet their appetite, give them some practical experience as well. And then, if one would like in the book, and we can actually just take it further. So ideally, this is written for people who are maybe new to programming, or they’ve been programming for many years. But it’s a great introduction to such topics as solid, and a few other methodologies as well. And then what it is, soes the seed in their minds, and then they can actually go away and look up I mean, like greater depth, because I mean, it’s like called books written on the topic of solid that people can actually buy to really go to the nth degree of making sure that they know exactly how it works, what it does, and they can actually apply it in the real world.

So there’s a lot of topics where it’s like, introductory; gives you the knowledge of what it is, and why you would want to use it. And then, other topics, they actually have, like, practical experience associated with them. Because as you’re working through a lot of steps, what I actually take you from, in using a particular technology, and even applying it, and such as the refactoring tool ReSharper, what you will end up with is you’ll have no prior knowledge, you’ll end up having the knowledge by the time you’ve actually used the tool, but you’ll have the confidence to go with it. So that when it comes to being in a workplace, you will actually be able to actually apply the knowledge, what you learn for the book. So the thing is, you don’t really need any prior experience in reading this book, other just a basic knowledge of C sharp, and the wanting to actually write code that’s nice and clean, that you as an individual like to work on.

Jamie

Okay. I mean, that makes sense, right? Because I have read technical books in the past, where like, a lot of people talk about the Gang of Four book, right? I feel as though Gang of Four, which is the refactoring through design patterns, or whatever the full title is - I’ll make sure that all titles in the show notes, but I can never remember the full title. But Gang of Four, really, really requires you to very quite deeply understand C++ and SmallTalk, I feel. And as someone who’s done a little bit of C++ in the past, I was like, “oh, yeah, yeah, I totally get this.” And then the next patter, I’m like, “I have no idea what’s going on here.”

Jason

Yeah.

Jamie

So I’m glad to hear that I don’t really need to have much more than - for one of a better phrase - a sort of basic or rudimentary experience with .NET and Visual Studio to actually get some use out of this. That’s refreshing, I think.

Jason

Yeah.

Jamie

Okay. So what about, a lot of technical books, sometimes just have reams and reams and reams of code attached. And some of them say, “hey, go to this repo or whatever.” Do I need to have a GitHub repo of my own code ready to refactor? Or is there some like, pre-provided code that’s like, “hey, here’s some bad code, and we’re gonna fix it,” or something?

Jason

No. Basically, what I have a tendency to do in my writing, is I’ll provide you with examples to actually go through. Sometimes that is actually writing the code from scratch. So you’ll, if you’ve got code and you’ve got your own repository, I’m talking you through things, you can always apply it to your own repository. But the book does come with its own GitHub repository. And I don’t require you to have any code, you just read through the book, work through it. And I’ve tried to provide as much of a code as possible, without you having to like keep going and looking elsewhere, looking elsewhere, looking elsewhere. As long as you’re in front of a computer, and you’ve got your environment, you’ve got the tools - and if you haven’t got the tools, I’ll even talk you through getting the tools so you can set it all up - you don’t really have anything to worry about. The book is pretty much enclosed. Everything you need is within the actual book itself. And if you need to go anywhere, I just guide you, and give you instructions. And you should have no trouble.

Jamie

Excellent. Tthat’s really useful, because I’ve been, you know, like I say, I’ve read technical books before where it’s like, “okay, go find a repo of your own and make some changes,” and I’m like, well, that kind of, whilst they agree that there’s nothing better than practical experience, I prefer to be sort of walked through a few things.

Jason

Yeah.

Jamie

So what was the impetus? What was the drive to write this book, then? If you don’t mind me asking?

Jason

It’s a good question, actually. It’s funny how it came about. I was approached, first of all by Packt Publishing. So I’ve never actually approached them to write a book, they actually approached me. And I had ideas about, “yeah, I’m writing the book, I’m probably like to write a book about soemthing I’m into, like reporting, that kind of.” Well, they says, “actually, we’ve got a book in mind, it’s a book on clean code.” And I thought, “well, that’s interesting. In all the places I’ve worked not one of them has really done clean code. We don’t use like practices like TDD, BDD, or anything like that. And it’s just like, just get the code done. I get it out the door, it doesn’t matter if it’s got bugs, we can fix them later on.” That sort of thing. Or you can leave leave refactoring until later, but then the refactoring never happens, so the repository just gets worse and worse, and worse and worse.

But when I was in such places, and we had like, issues were like code is slowed down, I was called upon to like,, make it run faster, whether it be SQL code or VB Six code. And in some cases, I was getting like a thousand percent increase, because of the way I was writing, cleaning the code or getting with a dead code, and all that lot. So I thought, I’ve got a bit of experience in this," but I thought it would really be nice to actually, because obviously you pick up bad habits as a programmer when you’re working in certain teams, because you’ve got to like mould yourself into that team. And then basically, because you programming them in with on a day-in-day-out basis, obviously you develop the team’s habits. So I thought, “well, yeah, it’d be good to actually write a book on clean code, because apart from applying what I already know and that I’ve picked up, I can actually really study the topic in depth for myself, and put as much goodness in this book, one for myself as I programmer so that I develop my own skills. But as I’m developing myself, also develop the reader along with me.” So it’s like a journey, we both tote together, essentially. And so that’s what prompted me to say yes to Packt Publishing.

Jamie

I like that. You know, one of the reasons that I got initially into blogging stuff and then pivoted into podcasting is just quite literally, to force me to learn more. Because I was finding that, you know, I was sitting around doing nothing - that’s probably not the right word. But you know, I felt like I was spinning my wheels and not learning much. And then I decided, “you know what, I’m gonna write a blog post on this thing. So that means I’m going to go and learn it,” and just learning, and turning that information round and teaching someone else is - I’ve got a background in teaching , right. It’s one of the best ways to learn, or rather to reinforce that learning.

Jason

Yeah. Actually, I received that advice when I was looking at a website, and it did say that if you really want to learn something, teach somebody; and I thought, “yeah, that’s a really good way to do it.” And so for me to learn clean code, the best way for me to learn is to teach. And the best way to teach, in this regard, is to actually write a book on the subject. And that’s why this book exists.

Jamie

Excellent, I have to say, it’s a brilliant reason for writing a book. Like I say, my own experience as a teacher, we used to always get the kids to echo back to us what they learned, but in their own words. Which is essentially, you know, it’s reducing what you’re saying, but it’s essentially what you’re saying, you know, “I’m taking my experience and putting it out there for people to read, and it will help me to remember it, too.” I like that.

Jason

Yeah.

Jamie

So then, okay, so the book is, is called “Clean Code in C sharp”, and it’s about refactoring code. So I guess the important question to start with is, what is clean code, right? Because I feel like clean code to one person may not be clean code to another person. And I found that when I’m trying to talk to juniors or mentoring people who are maybe not in the business and talking about clean code, I hav to use really amorphus. phrases like code smell, right? Because these feel like they are things that you don’t really, there is no real description of them until you’ve got experience. So I’m wondering, you know, what is clean code? And is it all about hard and fixed rules? Or is it more sort of malleable?

Jason

It’s malleable. First and foremost. Well, I think the best thing to do is to first of all, say about a project I worked on,. It was a marketing application, and it was really bad spaghetti code. And you couldn’t really extend and you had to work around things. And if you was to change and refactor the code, it was that badly entangled that you would actually introduce like bugs like in loads of different areas. And so it was, prior to me they tried to redesign, and rewrite the application, like, three times. But they failed, they got me in on it. And even I failed, I said, “look at end of the day, the only way you’re gonna actually do anything with this application is to just have it as a maintenance release. So that basically you just keep it going in its current form, you rewrite an application from scratch, that’s properly spec’d, and that meets your requirements, but you write in a clean way that’s object oriented. And then that way, you’ll be able to like, put extension points in where you can easily grow the software. But also, if you make sure that the code is it has comments where it needs them. But other than that, the code itself is like, you can read it like a book, like you can just follow through the code and you know exactly what each piece of code does. You’ll have a better chance of success doing it that way.”

So I think in some ways, clean code is maintaining existing bad code, where you keep it going. And you don’t introduce new bugs. But when you actually haven’t to like maybe just add a few things here and there. And it only does what it needs to do. No more, no less. When you look at the names of things, they’re not cryptic, so you know exactly what they are. So if some thing is a people counter, you know, some people counter; and if something’s encryption, you know it’s encryption; if it’s decryption, you know it’s decryption, etc, etc, etc, etc. In other words, you don’t have to second guess, what’s meant by the name of a method, or a variable, or a class, or a namespace.

Another aspect to clean code, I think, is properly packaging. Like, making proper use of namespaces, grouping things together. And also, it’s keeping your class minimal, so it only contains what it needs to. It doesn’t do more when it needs to. And it does exactly what the name suggests. So if you’ve got, say, for instance, you’ve got file system helper class. in that class, you would only expect to see things to do with file help like for your file system, like checking if a file exists; reading files; writing to files, etc, etc, you won’t have anything outside of that within the file. And then also with your methods, trying to keep your methods as small as possible. so that they don’t have reams and reams of code. And your methods, when they’re doing like, things like iteration, you try and keep iteration as small as possible. And you don’t have like levels, and levels, and levels, and levels of iteration where basically you can get lost.

And maybe thinking about if you’ve got like a massive switch statement: is it possible that you can actually program that piece of code in a different way? Maybe using like some other client kind of design pattern, whereby you’re not having to like go through a big massive cast statement? Because yes, they do work. Yes, very easy to manage, and all the rest. But is it really the best way forward? And so really, with a method if you can try and keep methods below 10 lines, if possible; it makes it readable. It makes it more manageable. I mean, I’ve worked on methods - I mean, single methods - which I’ve inherited, which have just been lines, and lines, and lines of code; and the amount of nesting in hem has made them really unreadable and unwieldy. And on top of that, you’ve had, like, cryptic names. And it just adds to developer stress.

So I think part of clean code as well is making it so that you reduce the complexity of the code, like you try to reduce the number of pathways through the code; you keep a code as simple as possible; it is human readable; where even if is the words are human readable it’s not quite clear what’s going on, you just add comments. And things like that. To me, that is what clean code is all about.

Jamie

That all makes sense. The the two things that I usually say is, I, I caught a TV show, and I called Steve McConnell, from code complete to one of the things that he says is the the most important thing for a code that you write is that it has to be understandable by human beings. I believe he uses the word Prime Directive, so he’s, he’s riffing on startrek. But you know, the code that you write the code that I write the code that someone else writes, has to be readable by someone else, and that someone else could be you tomorrow, right? Because you aren’t tomorrow, you’re not going to be the same person that you are today, you know, you’ll have the same experience, but you may not have the same sort of short term, short term working knowledge contents, right. And I think I completely agree with you about classes having, you know, the, the bare minimum of what they need to do. And the way they explain that is a riff on a TV show called mash. He was a character called chosen as an adjuster, the third and he says, gentlemen, I do one thing at a time. I do it very well. And then I move on. And obviously, he’s being really facetious and horrible. But I like to apply that to classes and methods that are right that the method will do one thing, that’s all it does, the class has the bare minimum that he needs to do whatever it needs to do. Right. And I think I think I think those sort of fit well with what you’ve said. Yeah. And I think the the point about writing code for other people to read is is a bit of a disarmer. I think it disarms people who want to look at how clever I am, I’ve written a multistage ternary or something, and you’re reading it and you go in, I’m actually getting a headache from reading this. Yes, the compiler will probably turn into that. But you’re not writing code for the compiler, right? You’re writing code for other people.

Jason

Yeah, and then we’ve been in my work time I’ve experienced in one place, those are going to be found really, really clever, and far cleverer than ours. But people did actually come play that even those code was clever. He needed to actually add your comments just so that we knew what the code was actually doing. And so if performance is an issue, and you need to write such code, but to a normal everyday human who’s maybe not as advanced as what you own your skills, they’re not really gonna understand what’s going on. Then I think the best thing to do is to most definitely make it human understandable to the normal macro. By just simply stating, what is storing

Jamie

and why. Absolutely, absolutely. And I think I think you’ve, you’ve hit on, from my point of view, a really, really important point about comments. And I’m sure you cover it in the book, and I’m sure I’m sure I’ve had read it 100 million times elsewhere. And I’m not trying to say that this is something that is not unique to you. But what I mean is, when somebody writes, I don’t know, VA, I equals zero, and then they put a comment, sets it to zero. And I’m like, that’s useful. But you’re not telling me why you did it. Right. Yeah. And I think that’s the important thing is to explain why you’re doing what you’re doing and what it’s actually doing, like the, the the idea behind what it’s doing, rather than, you know, I could run a method that poses some obscure data format, right? But someone else reading that, that code will likely not understand what the data format looks like, just by reading my pausing code, right?

Jason

That’s right. And the other thing you got to be careful of as well is, and I’ve experienced this in the workplace, where, when there’s like an excessive amount of comments, and unnecessary comments, and you can get developers wherever get really upset, Bava can actually get very angry, and even explode within the workplace. And so comments can actually be an actual source of like, real severe stress on fellow programmers. And so that’s why it’s important to get the balance between having not comments with code that’s readable, and having comments wherever actually needed.

Jamie

Yeah, absolutely. And there is something that you mentioned a number of times in the book about, about developer stress coder, stress code, reader stress. And I absolutely love that because you, you talk in the book about, if you do it this way, it will reduce the chances of someone who’s reading your code becoming stressed. And I feel like, that isn’t something that’s touched upon in many other books about, you know, solid principles, clean code in and all that kind of stuff is not a it’s not mentioned, but I feel like it should be right. Because if you’re reading some code, and you don’t know what it does, and you don’t understand it, and it’s not well written, and it isn’t documented, and there’s no comments, and there are, you know, va a VA B, you know, and you literally don’t know what he’s doing, you can get stressed.

Jason

I mean, such I mean, I’m working on one now. And it’s massive project, there’s loads of different libraries all over the place. And we’ve got stuff in like C sharp, you’ve got stuff in Java, and you’ve got a different reporting mechanisms. And the actual company has quite a high turnaround. And I believe that part of the reason why it’s got a high turnaround is because there’s hardly any documentation. The code is so disparate. And there’s people have like, permission to see certain passport and other parts. And there’s, like, lack of like, team communication and focus. But the thing is, there’s no real documentation. and with a high turnaround, you have a lot of brains come in gaining knowledge and and leaving without knowledge. bobbin when they leave, that knowledge is gone river, but it’s no longer in the company. And like it’s can be so stressful, trying to actually reach your targets and your deadlines, when you’ve been blocked because of lack of information. And because nobody knows what the correct way to actually do something actually is. And that’s why when you write in clean car documentation is a really important part of that. And so yet, the documentation is like twofold. First and foremost is having your good specifications, which are not ambiguous and which do not lack information. And secondly, is making sure that whoever is responsible for the architecting of the actual system and properly documented, whether it’s themselves a combination of themselves and the people working on the system will actually produce the actual various sections of the actual code. It pays to actually have it properly SPECT and properly document and form a high level document overview like quiver diagrams. For instance, if You’ve got loads of moving parts, how all these parts fit together and have a link to the database, etc, etc. But when it comes down to the code level is when we knew would be like your API documentation for use of ramaala, that kind of stuff, and swagger. So it’s important to do these kinds of things. And they do actually reduce stress. Whereas if you don’t do them, and people don’t know what one part of the system does our, our carnita fixes book web hosting, and, and the trend of follow through, and it’s heavily into dependency injection, that you’ve got so many moving parts. But because you’re using dependency injection, there’s no overarching architectural diagrams. And it’s not clear what’s been injected, and where what has been injected is coming from. Again, it’s like, so unbelievably stressful. And you can eliminate a lot of that stress, if you have got a really well architected system, that’s wellspect. And well documented.

Jamie

I agree completely. Because there’s something that I always say, and that’s the the customer and customer can be an internal customer, it can be an external customer can be, you know, Bob down the street, it could be the project manager, it could anyone, right, the person that you are writing code for, doesn’t know what they want, until you give them what they don’t want, right. And that’s something that I’ve fallen into the trap of many times over my career. Because like you say, human language is so ambiguous, right? You end up building something, and then you build on on on that thing with assumptions. And then you build more assumptions and more assumptions, and then you end up completely in the wrong place. And I think I think it’s so important to have the documentation and to have specifications to hand and to build the software, perhaps, I mean, some people don’t like to do TDD and BDD. But if you are doing TDD and BDD to build those things from the spec, and then build the software from that, like you say, because then you have the confidence that what you’ve delivered, is what was requested, right?

Jason

Precisely. That’s one of the reasons Well, I think can be Scrum software methodology is quite good in doing things in two weeks sprints, especially on like, Greenfield projects. Because right from the start, you might have a specification from a customer that’s been signed off. And the customer might be thinking, yeah, this is what I want. So Deliver me. Now, the thing is, if you’re only developing in two week, time firms, when it comes to actually releasing a total worth of work, to like, a test environment for the customer to look at. When you demonstrate what you’ve done, they can then say, well, nice one. Yeah, that’s good. You’re quite understood what we’ve been asking. And so you really need to change. It could be well, I know that’s what we asked for, but thinking about it, no, really, we don’t actually know what we really need is this. And so I think that’s why properly implementing Scrum, but where you are actually doing an actual release, at the end of that two weeks to the customer, not necessarily into a production environment, but into some environment where you can actually demonstrate it to the customer. And that can also work to watch a clean system. Because rather than say, like develop six months worth of where it goes and gets released. And when you found out there was a major architectural flaw for because a customer finally realised the need some think doing in a certain way, what we architecture now no longer is able to actually cope with making a simple change for expansion. You’ve got to do like a major architectural change by staying up on the right foot using something like the scrum methodology where you actually do an actual physical release every two weeks and demonstrate to the customer. You can be serving yourself and the customer merger merger headaches further down the line.

Jamie

Absolutely, absolutely. I think this will with this will age me But I’m from the very, very, very tail end of waterfall, and the beginning of agile and Scrum. So the very, very beginning of my, my journey into development, there was lots of, you know, waterfall was slowly becoming out of out of sync with the rest of the world. Because in, in waterfall methodology, you literally work on a project for one to two years, maybe even three or four, and then deliver it to the customer. And that’s when you find out like you said that it doesn’t fall in line with what they want. And that’s why I’m always always a big proponent of regardless of whether you do agile Scrum or some other way, have these sort of frequent deliveries, maybe two weeks, maybe a month, maybe a week, whatever it is, that fits with, with the rest of the team, and how you can deliver those, those deliverables. And I’m very much a case of always have code in any position, everything that’s checked in, at the very least in source control, is in a state where it can be delivered if needed. So you’ve not got like a feature that’s half built, or whatever, there’s already in source control in your main trunk or whatever. Your main branch that live is built off of live should always be buildable and deliverable, I guess. And I guess the only way that you do that is by doing very short iterations. Yeah.

Jason

I mean, we do that here, we have like two experience. And they work really, really well. We do a hit blocks, sometimes where it goes off sprints, but the majority of the time we do actually meet and, and then at the end of a month, we’ll have a monthly get together. And then that’s when we demonstrate to the senior management. And then that helps them to see how progress is going on behalf of the development team. And it works really, really well. We don’t necessarily release out to the customer, as in the external customers. But internally, because we are the ones who provide the schools with the senior management will actually have schools that will release like this too, just to see how it goes. And then it does actually show when there is actually problems. I mean, just recently we had to scrap a certain project, well not so much scrap it, but put it on hold for the time being. Because in the time frame, it was required, there is no way we could have delivered. Because what the customer wanted, would require, like a really big architectural change. And so it wasn’t really practical. So if he was designing systems from scratch, that’s why it really pays to sit down, have a blank canvas, think about what you really want document or you know, any ambiguity with specifications. And then when it comes to actually develop in any project, it’s probably prudent to go down the TDD stack BDD software development paradigm. Because that way, if you do that, and you only do two week sprints, and every single sprint, you are actually through discipline, release into the customer. And you only check in in code, one that works. And that tool is feature complete, then you’re going to end up with a more robust system, a system that the actual customer actually want. But also, you’re gonna end up with a system that you developers actually end up enjoying working on. Because at first when it comes to doing anything client TDD or BDD, you do meet with a heck of a lot of resistance. Part of that resistance as well. is I am what TDD is to have constituted Oh, yeah. But it requires a lot of work. When you actually write the proper code, as in like your tests that fail, and then only the amount of code you need to actually make it work and then refactoring, you can actually end up proving less code. But if you don’t just jump into it and start developing, because I mean, for instance, writing all that code on a customer doesn’t want means you’ve wasted all that effort by writing all that code. When you could have read this card and given a customer walk along.

Jamie

Absolutely, absolutely. And it also means that you’re you’re creating, I guess a maintenance requirement on the code that you’ve written that wasn’t needed, right? Yeah.

Jason

So with code as well, if it, if you ever have to like common blocks out to try something, if it works, what you’re trying out, and you no longer need that, like common acted out block, like where we work now, that’s got to be removed, you can check that into version control. And that’s good. Because if you look at your keeps your source file smaller, you’ve got less to read, you’d have to go through loads of scrolling if you spend commenting out late load a card. So again, that’s to like making it more readable, more maintainable, as well.

Jamie

Absolutely. And, you know, when, when I’ve seen coming to that code in the code base, I’ve said, Hey, you realise your source control provider. Good, give you that code back if you need it in the future, right? Yeah. Yeah. So I guess one thing I’d like to ask if that’s okay is like, let’s say I’ve got, I’ve got a block of God, maybe a class, maybe just a method. And I want to refactor it, right? I’m looking at it, I’m thinking, this isn’t a very clean to me, I think there’s a code smell layer, I think there’s perhaps something we didn’t touch on but an anti button there, and maybe I can make this better, maybe I can make him more testable? Do you have any prescribed steps of how to tackle that, because I can imagine that if I’m looking at a method, then and thinking I need to refactor this. That could be, you know, a monumental task if I don’t know what the, the common steps are. So let’s say you’ve got a method in front of you, and you need to refactor it, what are your your common steps?

Jason

Well, first of all, I look at the size of it. And I look at the naming plus been employed, does the names actually correspond to the coding standards, what the company has, because sometimes it’s surprising how many times especially if you get new developers coming, that the naming and the webinar has been carried out, it’s not in keeping away coding conventions. And obviously, you would make sure that that code is renamed to use a coding standards within the company. A good way to automate that would be to use linting. And so that every time you could build, any of the coding standards are actually not met. that constitutes an error in the code, and it will not build a not run, and so you will have to fix it. And so that’s where to actually negate having to go through and fix somebody’s code where we haven’t actually use the correct name and stanza where you self may have even let it slip, which is quite easy to do if you’re under pressure. So first of all, it would be too if when we try to encourage professional do is just try and actually put in place some kind of linting tool and make sure that the coding guidelines are agreed by the actual team. And when the team agrees, then obviously the linting gets put in place, then is to actually look at the class, what you’re working with. Can that class actually be split out into more specific classes? If so, do that. And then give it a run from just make sure you don’t break anything? And then once you split your classes out, and you’re happy about your class on yours in what it needs to do, can the methods be made smaller? And can you find out if it’s a big method? Can you break it down into smaller methods? And give them methods, meaningful names for what the task is for actually performing? Also, does the class have a lot of sorry, the method have a lot of parameters? If so. Does that mean that the method is actually doing more than it needs to? And is there a way to actually reduce the number of parameters that that method actually needs? Again, maybe by maybe even like creating the property class or whatever, and things like that. And do you have anything like magic numbers? If so, and how about we place in magic numbers with enumerations Do you have multiple clusters that are actually doing the same thing? But maybe a bit differently? And would it pay to actually have them actually implement an interface? Would it be fair to actually have a first class virtually has the best functionality that implements so much of what you want? as well? So, but mon Ma, you find that you write in smaller classes with less functionality in them? And is there any patterns Is there any thing where you’re doing something of a repetitive nature, but you may be doing the same thing differently in different areas, could you actually use a design pattern for that, and if seven, Deuce, and just things like that, and one of the best things I can recommend when it comes to a factory, is have a look at tools like resharper. resharper, is an excellent tool for helping you identify dead code. And code that’s not really performance best. Identify in areas, which are bottlenecks, and all that kind of thing. additive as a whole lot of different code smells, and helps you to refactor them. And it’s a really, really good tool.

Another thing is, if you see some code value thinking, I don’t know if that’s the best way to actually do something in performance is really an issue, then you could maybe look at using something like benchmark dotnet. And like with benchmark dotnet, for instance, you can write two different methods, maybe five or more different methods, that all do the same thing. And you can benchmark, and then out of all of them, you can actually pick the best method. And from that, so that when you’re refactoring your code, you know that your code is going to be fast and does exactly what you need it to. If you’re using test driven development, and you wanted to refactor a piece of code, if it doesn’t actually have any tests in place, you could actually add them to actually testing. And obviously, you’ll need your perfect path through the card, you’ll need your RAM, invalid data values, and you’ll need like, you know, value to be passed in, et cetera, et CIE and tools, all those different aspects. If your team is against test driven development, and very against using things like BDD, then really, yeah, probably just gonna have to use your best judgement on like refactoring, making sure the car does what it does. But I think the key however you’re doing is to make it so but it’s isolated, in that it doesn’t, it’s loosely coupled as possible. And it’s enclosed and encapsulated. And it only does what it needs to do. And if it’s doing it, even if it is only doing what it needs to do, if you can find the internals out to have a method so that you reduce the readability of the size of an effort. But the methods are the meaningful names of what that parent method is actually doing. That can also be really, really good. And so yeah, by some of my tips, excellent.

Jamie

Those are some some really, really good tips, I have to say, when I started my career, and somebody said to me, refactor this to make it smaller and cleaner and more efficient. And I was like, I mean, just rewrite it. That’s how do you know how do we know what he’s actually doing? You know, but yet, to have someone actually say, these are some tips. These are some places to start. That I feel it’s quite useful. And there’s there’s everything that you’ve said there makes a whole bunch of sense as to where to start and how to go forward. So yeah, I think that’s, that’s a that’s a wonderful answer to that. And of course, of course, there’s also you know, by the book, as well. So, so, so talking about the book, Um, could you Would you mind reminding the listeners the name of the book and maybe where they can get it from? I know that it’s available from pact or packet or however they pronounce their names, right. But you know, I know it’s also on Amazon and stuff like that. So. So is that, would you would you mind just sort of reminding people the name of the book and things like that.

Jason

So the book is clean code in C sharp is by packet publisher. And myself, Jason halls, you can buy tickets, bands novel, Amazon packet. And figure is also available on over booksellers as well. I think it’s also available on Kindle books.

Jamie

Right. Okay. So it’s, I would say that’s practically everywhere. I mean, yeah. You. If we don’t know about it may be available in the Apple store as well. We don’t know it. Have a look? Let us know if it is let us know if it’s not I’m okay with you reaching out and let us know. But I also, I’ve heard through a through a birdie, that you’re working on another book? Is this a super secret project? Or is this something that you can talk a little bit about, and maybe whet the listeners appetites and get in clamouring for that second book?

Jason

Yeah, Sam highperformance card in C sharp. And basically is taking different ways of doing card, benchmarking them, and letting you see that they’re doing the same thing. But where you can actually see from the benchmark, report, the performance, so you see how many milliseconds or nanoseconds it takes to run a piece of code. You can also see like memory allocation, etc. And so when you’re writing code, where performance is essential, but there’s many different ways of writing that code. And I talk you through step by step, writing the actual code, to actually show different ways of doing something. And using benchmark to actually produce a report to show you exactly which method, our evolvers were ways, is the best way of doing things. I also use things like tress stop memory, and things, just so that you can actually see like memory allocation. And for where a piece of card affects, like your network traffic and that kind of thing. And so it’s just really helping you to understand different tools, and ways of identifying the best possible card that you can write for your particular situation, to make it that your card runs at its best. And that’s basically what the book is about.

Jamie

I like it. I like it. There’s, there’s, there’s not many books, I think out there about high performance dotnet. And I think it’s something that, I guess doesn’t really get talked about, at least in my experience, where the places where I’ve worked to the customers I’ve worked for, where you know, the tests have been visit, do this thing. Again, we do an end to end thing, can I call this API and watch it go all the way through? Can I check the database, but they never really been on sort of throughput? Which I guess is where performance comes in, right? Because if you’ve, if you’ve written some wonderful dotnet code, and maybe it’s in a function, maybe it’s in a micro service, maybe it’s an a monolith, because let’s play a buzzword bingo, you know, and and suddenly a million or a billion or quintillion, or whatever the numbers are users hit that piece of code. You need to make sure that it’s actually it’s not going to blow up the server, right?

Jason

Yeah. And so that’s why, like your performance monitoring, and your health monitoring is like really important. So using things like analytic analytics can help you actually see exactly what people are using to access your system, how many? What terms are actually peaking. And that allows you then to actually allocate more resources. Well, from a programmer perspective, there’s lots we can be doing, because we can actually be there, benchmarking our car with can be checking load balancing, like doing like a testing phase. And so we can load balance, we can write code that’s been benchmarked to make sure what is the most performant card. And we can pass that up into our testers, who can then make sure that through the load balancing, they can actually mimic, say, for instance, like schools in the UK, we know that schools in the UK are going to be using the system from anywhere from like eight o’clock, all the way up to we’ll say, like five o’clock, and, and the peak times probably going to be between Nan and free. And with a lull between labour different work terms. And so what we can actually do is we can model our systems, and to learn stress testing around that kind of capacity. So I’d say if we know, roughly like maybe how many schools have got, how many students are going to be having. And we can put our software for that stress testing, and to see where it’s going to fall over. But within the application itself, it can also have health monitoring, and exception logging. So that we can actually identify if there’s problems. And if his problems were about they actually. And, for instance, maybe have like, an over 500 server visit etc. Well, we know that that means it’s too many people are actually accessing the system at that moment in time. And so obviously, record and cannot handle that number of people at any one time. So it’s like, right, is there anything we can do with this same card, but we can actually do to improve performance? Other than just get more hardware? More load balancing? is actually anything we can actually do with the actual card? Well, first of all, it Sam hitting the database hat, or Kevin, right on the database? Can you actually improve the queries by such an agenda? Can you add things like indexes? Can you actually change the ordering of a query server is still bringing back the correct information over filtering is actually and reducing the number of records that aren’t to be processed? So that the query executes faster? And is returned faster? And is there any particular code that’s actually a bottleneck that could be found out elsewhere? So but it’s not under so much stress? And are you using the best query method? For instance, if you benchmark? Are you numerable versus a iqueryable? so it knows ienumerable versus enumerable? Are you ienumerator is a lot faster than using ienumerable. For instance, when you’re going through loops, and once you’ve actually got your data and you actually person on the actual c sharps. And so there’s lots of things we can actually be doing to make sure that when our card guys out, it is unblocking customers. Excellent.

Jamie

Well, you know, I’m gonna look forward to seeing that getting his release, because that’s something that I’m always looking to do, I’m always looking to make, you know, to tweak my code to get as much processing throughput for a CPU cycle as possible. And I’m terrible at it. So I am definitely looking forward to that. Jason. Thank you. So as one last question, then how can the listeners get in touch with you or learn more about you read after let them get into Israel? That’s fine. But you know, how can the listeners learn more about you and some of the projects you’re working on or find out more about when this second book will be released? Because obviously, it’s going to be done when it’s done, right?

Jason

Yeah, it will be done when it’s done. I mean, it’s quite technical and I’m hitting a few problems, especially since some of our code is still in preview. So obviously, things change as you’re writing, you got to redo code, etc. But you can reach me on LinkedIn - I’m on LinkedIn. I also have a blog, jasonalls.wordpress.com - I post articles on there. So I mean every so often if we come across like technical issues that I hit, I’ll put them on my blog and that’s just a reminder for myself but also it has actually help a fair few people from around the world; well if they actually ever want to ever contact me, they can you get in touch on LinkedIn

Jamie

Excellent stuff. I will have links to all of those things - everything we’ve discussed in the in the episode, there’ll be links to all of that in the show notes. So you know do click through and check those out; there’s always a section you know, links or interesting links towards the bottom of the page so do do check those out. And I guess all the really remains to say is thank you ever so much Jason.

Jason

Thank you

Jamie

You’re very welcome. I really appreciated you taking the time to talk to me today and I’m sure the listeners will too, because you know clean code is one of those subjects that I feel like everyone should be aiming for. You don’t have to hit it every time but you know you should be aiming for it because it helps to your your your code quality. And as a software craftsman, or craftsperson rather, I’m always looking for, “how do I make this better? How do we make this easier to read? How do I make this easy for the CPU to run through? What’s the best way to improve this?” So thank you ever so much, Jason.

Jason

You’re welcome.

The above is a machine transcription, as such there may be subtle errors. If you would like to help to fix this transcription, please see this GitHub repository

Wrapping Up

That was my interview with Jason Alls about clean code and his book Clean Code in C#. Be sure to check out the show notes for a bunch of links to some of the stuff that we covered, and full transcription of the interview. The show notes, as always, can be found at dotnetcore.show, and there will be a link directly to them in your podcatcher.

And don’t forget to spread the word, leave a rating or review on your podcatcher of choice - head over to dotnetcore.show/subscribe for ways to do that - reach out via out contact page, and to come back next time for more .NET goodness.

I will see you again real soon. See you later folks.

Follow the show

You can find the show on any of these places