Coding Blocks Podcast

Coding Blocks Podcast

The world of computer programming is vast in scope. There are literally thousands of topics to cover and no one person could ever reach them all. One of the goals of the Coding Blocks podcast is to introduce a number of these topics to the audience so they can learn during their commute or while cutting the grass. We will cover topics such as best programming practices, design patterns, coding for performance, object oriented coding, database design and implementation, tips, tricks and a whole lot of other things. You'll be exposed to broad areas of information as well as deep dives into the guts of a programming language. While Microsoft.NET is the development platform we're using, most topics discussed are relevant in any number of Object Oriented programming languages. We are all web and database programmers and will be providing useful information on a full spectrum of technologies and are open to any suggestions anyone might have for a topic. So please ... Show More

After 112 episodes, Michael can’t introduce the show, Allen pronounces it “ma-meee”, and don’t make Joe run your janky tests as The Pragmatic Programmer teaches us how we should use exceptions and program deliberately.

How are you reading this? If you answered via your podcast player, you can find this episode’s full show notes and join the conversation at https://www.codingblocks.net/episode113.

 

Sponsors
  • Datadog.com/codingblocks – Sign up today for a free 14 day trial and get a free Datadog t-shirt after creating your first dashboard.
  • Survey Says …

    When you want to bring in a new technology or take a new approach when implementing something new or add to the tech stack, do you ...?

    Take the survey here:
    https://www.codingblocks.net/episode113

      News
  • Thank you for taking a moment out of your day to leave us a review.
  • iTunes: MatteKarla, WinnerOfTheRaceCondition, michael_mancuso
  • Stitcher: rundevcycle, Canmichaelpronouncethis, WinnerOfTheRaceCondition, C_Flat_Fella, UncleBobsNephew, alexUnique
  • Autonomous ErgoChair 2 Review (YouTube)
  • Come see us Saturday, September 14, 2019 at the Atlanta Code Camp 2019 (atlantacodecamp.com)
  • Are they cakes, cookies, or biscuits? (Wikipedia)
  • Intentional Code When to use Exceptions
  • In an earlier chapter, Dead Programs Tell No Lies, the book recommends:
  • Checking for every possible error.
  • Favor crashing your program over running into an inconsistent state.
  • This can get really ugly! Especially if you believe in the “one return at the bottom” methodology for your methods.
  • You can accomplish the same thing by just catching an exception for a block of code, and throwing your own with additional information.
  • This is nice, but it brings up the question? When should you return a failed status, and when should you throw an exception?
  • Do you tend to throw more exceptions in one layer more than another, such as throwing more in your C# layer than your JS layer?
  • The authors advise throwing exceptions for unexpected events.
  • Ask yourself, will the code still work if I remove the exception handlers? If you answered “no”, then maybe your throwing exceptions for non-exceptional circumstances.
  • Tip 34
  • Use exceptions for exceptional problems
  • Exceptions vs Error Handling
  • Should you throw an exception if you try to open a file, and it doesn’t exist?
  • If it should be there, i.e. a config, yes, throw the exception.
  • If it might be OK for it not to be there, i.e. you’re polling for a file to be created, then no, you should handle the error condition.
  • Is it dangerous to rely on implicit exception throwing, i.e. opening a file that isn’t there?
  • On the one hand, it’s cleaner without checking for the exceptions, but there’s no signaling to your co-coders that you did this intentionally.
  • Exceptions are a kind of coupling because they break the normal input/output contract.
  • Some languages / frameworks allow you to register error handlers that are outside the flow of the normal problem.
  • This is great for certain types of problems, like serialization problems, particularly when there is a prescribed flow, such as error pages, serialization, or SSL errors.
  • Programming by Coincidence
  • What does it mean to “program by coincidence”?
  • Getting lured into a false sense of security and then getting hit by what you were trying to avoid.
  • Avoid programming by coincidence and instead program deliberately. Don’t rely on being lucky.
  • Writing code and seeing that it works without fully understanding why is how you program by coincidence.
  • This really becomes a problem when something goes wrong and you can’t figure out why because you never knew why it worked to start off with.
  • We may not be innocent …
  • What if you write code that adheres to some other code that was done in error … if that code is eventually fixed, your own code may fail.
  • So if it’s working, why would you touch it?
  • It might not actually be working …
  • Maybe it doesn’t work with a different resolution.
  • Undocumented code might change, thus changing your “luck”.
  • Unnecessary method calls slow down the code.
  • Those extra calls increase the risk of bugs.
  • Write code that others implement with well documented code that adheres to a contract.
  • Accidents of Context
  • You can also make the mistake that you assume certain things are a given, such as that there’s a UI or that there’s a given language.
  • Implicit Assumptions
  • Don’t assume something, prove it.
  • Assumptions that aren’t based on fact become a major sticking point in many cases.
  • Tip 44
  • Don’t Program by Coincidence
  • How to Program Deliberately
  • Always be aware of what you’re doing.
  • Don’t code blindfolded, Make sure you understand what you’re programming in, both business domain related and programming language.
  • Code from a plan.
  • Rely on reliable things. Don’t code based on assumptions.
  • Document assumptions.
  • Test your code _and_ your assumptions.
  • Prioritize and spend time on the most important aspects first.
  • Don’t let old code dictate new code. Be prepared to refactor if necessary.
  • Resources We Like
  • The Pragmatic Programmer by Andrew Hunt, David Thomas (Amazon)
  • The Pragmatic Bookshelf (pragprog.com)
  • Oh mother… | Family Feud (YouTube)
  • OMG! It’s here! Oh mother… the ON-AIR VERSION!!! | Family Feud (YouTube)
  • Thunder Talks (episode 87)
  • Spotify engineering culture (part 1) (labs.spotify.com)
  • Tip of the Week
  • 33 Amazing Sites with Beautiful Free Icon Sets (blog.usepastel.com)
  • Envato Elements (Envato)
  • Relearn CSS layout (Every Layout)
  • Announcing docs.microsoft.com/samples (docs.microsoft.com)
  • Browse code samples (docs.microsoft.com)
  • Try Kotlin (kotlinlang.org)
  • Samsung DeX (Samsung)
  • Share
    Mark as Played

    Chat About Coding Blocks Podcast

    Popular Podcasts

    The Ron Burgundy Podcast
    The Ron Burgundy Podcast
    Will Ferrell reprises his role as Ron Burgundy in his brand new Ron Burgundy Podcast! Each episode has a different theme in which Ron engages in conversation with another notable person on the topic at hand.
    Atlanta Monster / Monster: The Zodiac Killer
    Atlanta Monster / Monster: The Zodiac Killer
    Atlanta Monster / Monster: The Zodiac KillerFrom Tenderfoot TV and HowStuffWorks, 'Monster: The Zodiac Killer' dives into one of the most notorious, unsolved serial killing sprees in history.
    The Joe Rogan Experience
    The Joe Rogan Experience
    Joe Rogan's Weekly Podcast