5 Ways to Improve Your Code

What can you do to improve your code? Readable code, clean code is easier to work with and easier to change. So how do you get better at coding, what are some tips for coding beginners, and for more experienced developers, that will result in better code? What are the programming and coding tips that you can adopt to make it easier to create better software faster?

Being a software developer is not just about being able to write code that a computer can understand, it is about organising ideas so that you, and others, can understand it too. Writing software is challenging, software is abstract, almost infinitely flexible and extremely fragile. All this means that the quality of our choices, the design of our code matters.

In this episode, Dave Farley shows five common, really bad, examples that we see in code all the time and offers his advice on how to fix them, and how to improve your software, and your coding. Software engineering is about the continuous delivery of valuable software into the hands of our users: writing good quality code is an important part of that discipline.

-------------------------------------------------------------------------------------

🎓 CD TRAINING COURSES 🎓

📖 Dave’s NEW BOOK "Modern Software Engineering" is now available on
In this book, Dave brings together his ideas and proven techniques to describe a durable, coherent and foundational approach to effective software development, for programmers, managers and technical leads, at all levels of experience.

📖 "Continuous Delivery Pipelines" by Dave Farley

📖 The original "Continuous Delivery" book by Dave Farley and Jez Humble

📧 JOIN CD MAIL LIST 📧
Keep up to date with the latest discussions, free "How To..." guides, events and online courses.

-------------------------------------------------------------------------------------



--------------------------------------------------------------------------------------

📚 BOOKS:

[ZenoDovahkiin]

"An idiot admires complexity, a genius admires simplicity, a physicist tries to make it simple. An idiot will make everything so complicated you'll think he's a god for understanding it."
-paraphrased, Terry A. Davis

As deranged as he was, these are words to live by, both for designing software and life in general.

[ashishmishra]

*5 Ways to Improve Your Code*

1. Minimize the need for Comments, Code should explain what it does.
Write a comment to explain [why you make that choice] rather
explaining [what it does].

2. Avoid Long Methods (Avoid creating long methods it's hard to read, maintain & troubleshoot), prefer short methods over long methods

3. Avoid Long Parameter List (use max 2 parameters)

4. Avoid Duplicated Code (Duplicated code is maintenance overhead)

5. Avoid Complex Conditional code (Avoid large block of code in single condition)

[Sorc]

I'm so glad I found this channel. It's full of gold. Thank you very much for your videos.

[thomas-sinkala]

Finally a channel that offers unpaid advice. Just what I need for my new role. I hit that subscribe button faster than anything else.

[pablostraub]

This video is another jewel from Continuous Delivery. I've seen about half a dozen of your videos and so far all of them are brilliant. THANKS!

[BigKevSexyMan]

Here's what I usually do with comments:
1) Describe the business purpose of a function or method. Fellow developers can usually determine what you are doing, but why you are doing it can be even more valuable and not apparent from the code alone.
2) Describe assumptions and scenarios where the logic may break under certain data inputs (although it's generally better to just do proper exception handling)
- For instance, I had to write a service that wakes up and copies a daily file from sftp and appends the date to a very specific name. However, there can technically be more than one file since it's just an sftp server. So we decided to just overwrite the old daily file when that happens. We describe that in a comment so when people look back at the code, they know it's intended behavior, and can react accordingly.
3) Describe unintuitive bits of code you either can't re-write(ie. to make a third party's code work) or don't have time to re-write. Bring it up in code reviews! Maybe others will have suggestions.
4) TODOs if you still have more development you would like to do at a future date. Do these even if you haven't submitted your code for review. You never know when you have to pivot to a new project/bug and will need to remind yourself where you left off. Obviously you need to make sure your code works properly before it gets submitted, but there will always be things that you would like to do, but don't have time.

I think good comments generally arise out of a respect for time. Both yours and your fellow developers. If a comment gives them an easier understanding of what's going on, then do it. But don't waste their time with clutter.

[Oswee]

Use the scout rule - leave the code better than you found it. :)

[zpinacz]

I am glad I found your channel. Very clear and to the point explanation of not very simple problems !

[BBuckB]

Thank you very much, Dave, for sharing your knowledge and for the awesome content of your channel. You make your points in a very light and comprehensive way, and put our minds to work along your argumentation. Very well explained and reasoned. Once again, thank you and keep up the excellent work, I'm looking forward to more content. Best regards, from all across the Atlantic ocean!

[BlueEyedSexyPants]

1. Completely Agree.
Self-documenting code is always preferable, and comments are a last resort when you've failed to simplify the problem or when something is unintuitive like an equation.

2. Completely Disagree.
Long functions are not hard to read. Lots of indirection and file hopping is hard to read. If you're looking for a bug, you still have to follow all the code through all those little method calls to find out what the code is doing, and if you have to jump 17 files away to get to the actual code, you have made your code much harder to read. I'd be tempted to fire someone who put a 20-line limit on their functions and enforced it with CI. It is terrible for the long term maintainability of the codebase, and it is very, very bad practice.

3. Mostly Agree.
This is almost always really gross, but the only place I've seen this be useful is when operating on compound state machines where references to multiple states have to be passed to a function, and even then, grouping them into structs is usually worth the extra pointer chasing.

4. Complete Agree with caveats.
If groups of lines are used more than once, they should be factored into functions, but instead of Extract Method, consider locally-scoped functions if they are only reused inside this scope. Going back to number 2, you should have good reason to extract a method that is only used once, and that reason should be better than it "feels" too long. Remember that inlining code is a great way to find bugs when there are a lot of methods in a path.

5. Completely Agree with the Example.
Creating a connection is likely something that will be used in multiple cases in the code considering that they could have ci passed into scope. That's a bad usage of a large if block.

If anyone inherits a project written by Continuous Delivery, the first thing you should do is start inlining all the useless methods to find all those needless bugs that his indirection soup is causing. It will clean up the code and improve the long-term maintainability. 600 lines of code is far easier to manage than 100 methods of 6 lines each.

[MarceloSantos-pthj]

"If you're really good you're allowed to have an else clause as well" hahah subtle but made me laugh

[ubercorey]

As a beginner, for months I've been trying to understand what was meant by clean code or eloquent code, etc. THANK YOU!

[alschneider]

The biggest problem is that programmers code before structuring and/or understanding the data. On many contracts I am asked why I am not coding. I say I am organizing the data. That does not go over well. I get heat from management. I persist and normally finish with a very stable solution before the allotted time. I have worked on pacemakers, motor control, heat, HVAC, aviation, proprietary RTOSs, search systems and more. I am a very big fan of structuring my data like organized MUD.

[vkresch]

Thanks for sharing this informative video! Keep up the good work!

[grrr_lef]

To add to the chef analogy: You don't want your "oranges à vif" to taste like garlic just because you did not clean your knive.

[wordsworth]

Comment every line! And I mean every line. I learned this the tough way from a colleague in my first software engineering job. I hated his code for it; I kept repeating to him, like you, that code should be self commenting, etc, and coming out with all the arguments against comments that we all know very well. But after 3yrs working with him (back then) I couldn't deny an unavoidable truth - his code never, and I mean never, not once, had a bug in it! How could I tell this programmer what to do, when I couldn't say the same for my code. That was tough for me to admit. But I opened my eyes, and had a go at copying his style, commenting every line ... like you say, it's important to comment sincerely, not just flippantly saying what the syntax is doing ... and to my amazement, overnight, I went from producing typically buggy code like most programmers, to producing completely bug free code just like the guy I was now copying.

So what gives? What is making the difference? It's quite simple, and became abundantly apparent once I tried it. Pedantically commenting *every* line (when done sincerely, and *not* simply describing the syntax, etc), makes sure that you know what you are doing, and acts as a comprehensive self-review. It sounds like "well, durh!!" but I subsequently found it amazing how often I'd write a line of code, go to write the comment above it, then realise "ah, hang on, that's not quite what I intended to do", or realise a subtle short coming with the algorithm I was writing, etc. Often even going back to completely re-write the function when I suddenly realised the whole function wasn't doing quite what I intended, or that it might be subject to problematic edge cases that I hadn't thought of when I set out writing the function, but that had then sprung to mind when writing the comments. Even simple lines like incrementing a counter (index++). Once you come to write a meaningful comment for that increment, for example "move to the next element in the zzz list" (or whatever the context)... that prompts you to think... "ah... but what if we're now past the end of the array? have I put the check in?". And so on. All of this being identified and realised before the code has ever been run, not even from the development environment.

And commenting every line, forces you to make sure each line has a clear, simple role. If you have a complex line that's doing a lot, then commenting every line forces you to break it up.

And that often also reveals problems with that code that you'd written. It's funny how typically the most difficult lines to comment in this manner, are the ones where you're not really sure what you're doing. Pedantically commenting every line means there's no hiding! You can't get away with just writing a line of code in the 'hope' that it's probably correct. If you can't write a meaningful comment above a line, if you're being honest with yourself, it's usually because you don't *really* know what you're doing, and realistically you need to re-think it until you do know what you're doing.

A professional programmer should not need to step through a section of code they are writing on the debugger in order to evaluate what it's doing!! A professional programmer should confidently know what each and every line of code will do when they write it!! For that professional programmer, commenting every line of code, at the time of writing, is easy.

In fact, that's probably a good guide for programmers to self-evaluate how far they have come as a professional. If you are able to comment every line of code, meaningfully, as you write it, that's probably a sign of a good, experienced professional. The programmers you should be concerned about are the ones who can't - and therefore obviously won't - buy into this approach.

I've subsequently had lots of arguments with colleagues who think I'm just a thick, dumb idiot for doing it. The majority throwing the same arguments back at me, that I used to throw at that original colleague all those years ago. Some try to setup code style rules to prohibit it.

But I always have one challenge for them. I say I'll listen to you, if you produce code as bug free as I, and that original colleague, do. In the 20 yrs since I learned this technique from that original colleague in my first job, no subsequent colleague has yet met that challenge - though a number have listened and observed, and tried this approach and become converts.

Ironically, some of those I've argued this with over the years have also argued quite vociferously that (and I quote one them) "Software is always buggy!". They don't believe you can write bug free code. They refuse to believe you. And refuse to even give it a shot. They believe they are right - that software is always buggy - and, in practice their own code invariably reinforces their claims!

[fmitterb]

The longest function I have encountered while refactoring legacy code was around 3000 lines of code and had around 20 parameters. 700 lines of it were nearly exactly copy&pasted within the same function with minimal change.

[thingsiplay]

3:05 Also code like this, with single letter parameter names makes it hard to search for variable names or even search and replace automatically.

[DiegoAguilera]

Really good video, thank you. I’m looking forward to watch more content from you.

[ZlothZloth]

After all my years, I still don't see why I should break up big hunks of code. If you've got duplicate code then, yeah, that's no good. But if it's proper code that isn't repeated, I've got no problem with it as it saves me from having to jump around in the code. It doesn't seem any easier to maintain but maybe that's because my errors nearly always give me the line number where the break happened? If it weren't for those, finding the 'object not set' error in the 500-line Init() routine would certainly be a nightmare.

P.S. When you said the if statement was 100+ lines long, I thought you meant the actual logic portion, not the block of code. I about had a heart attack!