Swift

Paradigms Imperative In the imperative approach, we have a sequence of instructions that describe step by step how the program’s state is modified. Let’s look on the example ⤵️ var value = 0 func increment() { value += 1 // Mutating the state } print(value) // 0 increment() print(value) // 1 In the code we have a mutable variable value and a function increment that mutates the state (value). We first print the initial value, then increment it, and finally print the updated value. ...

Do You Know the Difference Between Imperative, Functional, and Reactive Programming? Test your understanding of imperative, functional, and functional reactive programming with this interactive quiz. These questions cover the key concepts from the main post to help you solidify your knowledge for your next interview. --- primary_color: green secondary_color: lightgray text_color: black shuffle_questions: false shuffle_answers: true --- # What is functional programming about? 1. [ ] Writing functions that may modify state as needed 1. [x] Avoiding side effects and state mutation 1. [ ] Relying on side effects to manage state transitions 1. [ ] Emphasizing object-oriented design patterns # In functional programming, why must functions avoid side effects? 1. [ ] To improve performance 1. [x] To prevent unpredictable state changes 1. [ ] To enable state mutation 1. [ ] To allow recursion # Which paradigm describes a sequence of instructions that modify the program’s state step by step? 1. [ ] Functional 1. [ ] Functional Reactive 1. [x] Imperative 1. [ ] Declarative # What is considered a side effect in a function? 1. [ ] Returning a computed value 1. [x] Modifying a variable outside its scope 1. [ ] Calling another pure function 1. [ ] Using recursion # How is state typically managed in functional programming? 1. [ ] By mutating global variables 1. [x] By transforming old state into new state 1. [ ] By ignoring state changes 1. [ ] By centralizing state in a single object # Which pattern is used by functional reactive programming? 1. [ ] Singleton 1. [ ] Factory 1. [ ] Delegate and Callback 1. [x] Publisher and Subscriber # What is the primary benefit of using pure functions? 1. [ ] They allow state mutations 1. [x] They are easier to test and debug 1. [ ] They increase code complexity 1. [ ] They require global variables # Examine the code below. Does it fully follow the functional programming principles? ```swift var value = 0 func increment(_ value: Int) -> Int { value + 1 } value = increment(value) print(value) ``` 1. [ ] Yes, it's correct 1. [ ] No, the function has side effects 1. [x] No, it mutates state by reassigning a mutable variable 1. [ ] No, it mutates the "value" variable inside the increment function Didn’t get the full result? No worries! All the answers are in the blog post HERE ...

What’s the difference? In XCTest we relied on the old fashioned simple comments to add more context to our test case e.g link to the bug description. With Swift Testing, we now have a special bug trait that can be passed to the @Test macro. The bug trait takes a URL String as argument and optionally a title for the bug allowing us to add short description of it. The key advantage over regular comment is that the bug title is visible in the test results. Better yet, tapping on it takes you directly to the related webpage with the bug report. ...

What’s the difference? XCTest doesn’t provide a built-in solution for parameterized tests. To achieve this, we create test cases as structs or tuples, defining test inputs and expected results. Then, we write a loop to iterate through these test cases and execute the necessary assertions. Swift Testing simplifies this process by allowing tests to be parameterized directly. Using the @Test macro, you can pass test cases as an argument. What’s the benefit? While you still need to define your test cases, the iteration code is no longer needed — Swift Testing handles it for you. ...

Swift code refactor in action 👨🏻‍💻 Today, let’s talk about refactoring for clarity, maintainability, and scalability! This time, the scenario is calculating the final price depending on the price and membership status. This initial code has a few code smells: 1️⃣ nested ifs - impacts general readability, making the code hard to understand, 2️⃣ duplicated conditions - “price > 100” which violates the Don’t Repeat Yourself principle, 3️⃣ lack of scalability - not possible to easily add a new discount, it’d require to rework everything. Checkout the gif or the post on my website to see how I solve these code smells and make the code cool, clean and scalable! ...