Programming

3 readers

1 users here now

This magazine is dedicated to discussions on programming languages, software development, and coding. Whether you are a beginner programmer or an experienced developer, this is the place for you. Here you can share your knowledge, ask questions, and engage in discussions on topics such as coding languages, software engineering, web development, and more. From the latest trends and frameworks to tips and tricks for debugging, this category covers a wide range of topics related to programming.

founded 2 years ago

Programming Principles: Optionals Vs Null Or Undefined (www.tiny.cloud)

submitted 1 year ago by wave_walnut@kbin.social to c/programming@kbin.social

1 comments fedilink hide all child comments

Just because you can use null or undefined doesn’t mean you should. We talk about the problems that come up and how Optionals can help overcome them.

you are viewing a single comment's thread
view the rest of the comments

[–] dneaves@lemmy.world 1 points 1 year ago* (last edited 1 year ago)

After some slight frustration with the "Monadic" (Haskell/Elm) approach to null when learning Elm, I actually fully embrace it now:

unNullString : Maybe String -> String
unNullString nullable = 
    case nullable of
        Just str ->
            str
        Nothing ->
            ""

A) Now I try to avoid nullables when possible, because handling it everywhere is often more annoying than just expecting the type (even in non-monadic languages like Python)
B) This is theoretically a better practice anyway. Why have a nullable string when you can just have an empty string? Or a nullable array/list/object/dict/etc when you can just have an empty one? Why have a nullable quantity of items when you can just have 0? If you really, really think you need a nullable bool, you don't: just make a data (Haskell)/type (Elm)/enum (others) at this point. Most other things could just become an data/type/enum as well.

We null things for no reason, too often. Usually laziness.