Defensive Programming & Guard Clause Hell (write more stable code)

In this video, I delve into the nuances of defensive programming and the concept of "guard clause hell" to help you write more stable and reliable code. Drawing from my personal experiences and practical examples, I'll explore how recent JavaScript features, such as conditional operators, can lead to unstable interfaces, unpredictable return types, and problematic APIs.
Github repository: github.com/Pro...
#softwaredevelopment #webdevelopment #programming #softwareengineer #defensiveprogramming #programming
📽️ Live Stream - / programmer_network
👽 Github - github.com/agjs
📡 Programmer Network - programmer.net...
ℹ️ LinkedIn - / aleksandar-grbic-74670263
💬 Discord - / discord
🏫 Bootcamp - • Web Developer Bootcamp

Interesting and practical

[@emreaka3965]

Thanks.

[@MailarYT]

Interesting video incase of user is null I usually set user to empty object if it doesnt exist so in frontend I check if Object.keys(user).length === 0 then (redirect to login page) etc.

[@kamilk.3182]

Hey Alex, on one of your streams I found js library that enables collaboration features you used on letter T as I remember. Can you tell me what it was? I can't find it :(

[@bertrodgers2420]

I do like this approach and it's not something I utilise enough. I'm a big golang fan and it handles "missing" data in a similar way, that being just returning a concrete class but with empty fields similar to your empty username check at the end

[@programmer-network]

Exactly, Go really shines at this. I'd say, anything one can do at any given place, that being a utility function or a class, makes the code and the data "cascade" way better throughout the entire system. One simple check and "normalization" can ruin the entire path, and make the code convoluted with unnecessary, and as I call them, lazy/convenient checks.

[@bertrodgers2420]

@programmer-network would you say you'd always rather a call return a concrete type then it's up to the invoker to determine whether that is valid data to continue? Thinking about default values against a type vs a null return. I suppose this breaks rest conventions if a not found is now an "empty" 200, but rest is fairly arbitrary these days anyway

[@programmer-network]

I'd say, null is also fine to return in most cases, as I illustrated in the video, it's very common and clean to check for the presence of something. E.g. if this thing is null, handle that as a separate case. As I also showed with the HTTP example, often times, one could return just the status code, e.g. 404, but it's purely contextual. I'd say, the most important thing is though when the data is actually returned. This is where interfaces get messed up, as often time, the data you get is unstable, aka, you might get this, or that, who knows? But I'd say, as long as these are broken into services, or [Insert Pattern Here] and properly used/composed together, things will workout fine. What I've seen a lot, especially past couple of years, a lot of developers fail a lot understanding the importance of stable frontend facing API, and importance of delivering as perfect data to the UI as possible. A lot of business logic and transformations are being moved to the client side, which is why modern client side Javascript is so messed up and bugged.

[@bertrodgers2420]

@programmer-network yeah makes sense to me thanks, full object or nothing is probably the best approach

[@jeroenadamdevenijn4067]

I'm noob in JS, but wrote down a quote from Primeagen: "if you want to build robust programs, you have to use errors as values, you can make it work with try catch but it is a ton of handling". Note: JS is a try catch language.

[@programmer-network]

Hi Jero. Javascript uses exception handling, and is vastly different than e.g Go, where errors are treated as values. "You have to use errors ad values to build robust..." is a false claim, as there are various ways to handle errors. You can of course achieve similar results in Javascript by wrapping each function block in try/catch and return an object with value/error but that has other performance implications. I wonder though, what in this video made you think of error handling, as what we discussed in this video was not related to errors? Thanks a bunch for commenting.