When Feedback Turns Comical (But not in a good way)

We’ve all been there. The long-awaited moment when your code goes under the microscope, and you get gems like:

• “This is garbage.”
• “Sh*t code!”
• “Do you even know how to code?”
• “You must be joking with this pull request.”
• “This looks like spaghetti code thrown against a wall.”
• “You’ve just set the project back by weeks.”

Decoding “It’s Sh*t Code”

When faced with such cryptic feedback as “It’s Sh*t Code”, a developer might wonder:

• Lack of Guidance: This phrase doesn’t illuminate the problem, nor does it suggest ways to rectify it.
• Morale Impact: Sharp criticisms can sap motivation, leading to dwindling enthusiasm for the task at hand.
• Clarity Concerns: “Sh*t” refers to…? Without context, it’s hard to pinpoint what “sh*t” refers to. Is it about the structure, the logic, or something else?
• Professionalism: Using crude language is unprofessional and can degrade the team culture and trust.

The Gentle Art of “Not Making Your Colleague Cry”

Ideal feedback during a code review should be:

• Explicit: Less “What is this mess?” More “This section could use a comment for clarity.”
• Neutral-Toned: Keep the focus on the code, separating it from the coder.
• Solution-Oriented: Instead of just highlighting a problem, suggest a potential fix.

The Beauty of Constructive Zingers

Constructive feedback not only points out issues but also guides towards improvement:

• Instead of: “This code is messy.”
  Suggest: “Consider breaking this function into smaller ones to improve readability and maintainability.”
• Instead of: “This section seems off.”
  Suggest: “Maybe we can modularize this part for better clarity.”
• Instead of: “The chosen algorithm seems slow.”
  Suggest: “Given our requirements, perhaps [algorithm] might offer faster performance.”
• Instead of: “I can’t follow this logic.” or “This part is confusing.”
  Suggest: “Maybe we can modularize this part for better clarity.”

Embracing the Benefits of Thoughtful Feedback

• Elevated Code Standards: Better feedback, better code, better coffee breaks.
• Positive Team Environment: Less side-eye, more high-fives.
• Personal Growth: We’re all here to level up, right?

Share Your Hall of Fame… or Shame

What’s the most “creative” feedback you’ve received? The funnier, the better. Let’s laugh (or cry) together and create a more constructive code review culture.

To Infinity and Beyond

Code reviews: the final frontier in a developer’s journey. Let’s make it less about surviving and more about thriving, one constructive comment at a time.

The post The Art of Constructive Code Review: Why “It’s Sh*t Code” Doesn’t Cut It🎨💻🔍🚫 first appeared on forceUnwrap.

Sample Code Overview

First, let’s dissect the provided sample:

class Person {
    let name: String
    let surname: String
    let age: Int

    init(name: String, surname: String, age: Int) {
        self.name = name
        self.surname = surname
        self.age = age
    }
}

let person = Person(name: "John", surname: "Doe", age: 21)

Here, we have a simple Person class that stores an individual’s name, surname, and age. An instance of this class, person, is initialized with the values “John”, “Doe”, and 21, respectively.

The print Function

Let’s first discuss the print function:

print("--- Print ---")
print(person)

When you run this, you might see something like:

--- Print ---
Person

The print function displays the textual representation of the passed argument. For most Swift standard library types, this function will show a useful and clear representation. For example, if you pass a string or an array to print, it will pretty much show you the content as you’d expect.

However, when you pass a custom object, like our Person instance, you get a default representation (like Person) which isn’t particularly useful.

To make print more informative for custom types, you’d typically have to implement the CustomStringConvertible protocol and provide a description computed property:

extension Person: CustomStringConvertible {
    var description: String {
        return "\(name) \(surname), \(age) years old"
    }
}

With this in place, print(person) would output:

John Doe, 21 years old

The dump Function

Now, let’s see what happens when we use the dump function:

print("--- Dump ---")
dump(person)

You’ll probably get output like this:

--- Dump ---
▿ Person
  - name: John
  - surname: Doe
  - age: 21

The dump function provides a detailed breakdown of the passed argument. In this case, it shows the internal properties of the Person instance.

This function is especially useful for debugging purposes. You don’t need to implement any additional protocols or provide a custom description. It just inspects the object and presents you with a more in-depth view of its contents.

Performance of print vs dump

Another aspect worth examining between print and dump is their performance impact. While for most casual use cases you might not notice a significant difference, when dealing with large datasets or frequently called operations, understanding the relative costs can be beneficial.

print Performance

The print function, especially when you’re using the default or custom string representations, tends to be lighter on performance. It simply takes an object’s representation and writes it to the standard output. When dealing with simple and small data types, the overhead introduced by print is minimal.

However, when you implement the CustomStringConvertible protocol to give a custom representation, there’s potential overhead depending on the complexity of the description computed property. The more operations and concatenations you perform, the slower it can become, especially if called frequently.

dump Performance

The dump function, being more introspective, can be a bit heavier on performance. It delves deep into the object, revealing not just top-level properties but also nested structures. This deeper dive can introduce more computational overhead, especially when dealing with complex and large objects or hierarchies.

In practice, using dump repeatedly on large structures might slow down your debugging sessions or, if mistakenly used in production code, your application’s performance. It’s designed for detailed introspection, and this depth comes at a cost.

dump and String Interpolation

An interesting quirk about the dump function is its behavior with string interpolation. When you attempt to use dump on a string that contains nested objects via interpolation, such as dump("Test: \(person)"), it doesn’t dissect the object within the string as you might expect. Instead, it treats the whole content similarly to how print would, displaying the string as-is without deeper introspection of the nested object. This can be misleading if you’re expecting the detailed breakdown that dump typically offers. When using dump, it’s best to directly pass the object of interest rather than nesting it inside a string to ensure you get the detailed output you’re seeking.

Structs and Readability in Swift

In Swift, structs enjoy a level of readability that often surpasses that of classes, especially when it comes to debugging and logging. Due to the way Swift’s compiler auto-synthesizes certain functionalities for structs, when you print a struct instance (even when nested inside a string), you usually get a clear and readable output without needing the introspective depth of dump. For example, executing print("Test: \(person)") with a struct version of our Person would yield a detailed output, showcasing all its properties. This inherent readability of structs provides an advantage in clarity, often rendering the use of dump unnecessary.

Recommendations

For general logging and display purposes in production, stick to print. If you need detailed introspection for debugging, use dump but be wary of its performance impact on larger structures. Always test performance in scenarios that mirror real-world usage, especially if logging or data display operations are frequent.

In conclusion, while both print and dump have their unique strengths, it’s essential to be mindful of their performance implications in specific scenarios.

Conclusion

While both print and dump allow you to display information about objects and data in Swift, they serve slightly different purposes:

• print is for presenting a clean, human-readable representation, often requiring some customization for custom types.
• dump is more for debugging and introspection, offering a detailed view of the internals of an object or data structure without any additional work on your part.

By understanding and using these functions appropriately, you can make your Swift development and debugging processes much smoother.

The post Swift’s print vs dump: A Deep Dive first appeared on forceUnwrap.

Step 1: Safely Undo the Last Commit

First, make sure that you haven’t pushed your changes to a remote repository. If you have, it becomes a bit more complicated, especially if other people have pulled from that branch in the meantime.

If you haven’t pushed the commit, you can use the following command to revert it:

git reset --soft HEAD~1

Here’s what this command does:

• git reset: This is a command that allows you to reset your current HEAD to a specified state.
• --soft: This option ensures that the changes in the wrongfully committed files are retained in the index. In other words, they will be staged and ready to be committed again.
• HEAD~1: This refers to the commit before the latest one. By resetting to this commit, you’re effectively undoing the last commit.

Once executed, your commit will be undone, but the changes will still be there, staged and waiting for a new commit.

Step 2: Switch to the Correct Branch

Before you can commit your changes to the correct branch, you need to check out that branch. Use the following command, replacing correct-branch-name with the name of the branch where you intended to make your commit:

git checkout correct-branch-name

If you don’t already have this branch locally, you can create and switch to it using:

git checkout -b correct-branch-name

Step 3: Commit Your Changes

Now that you’re on the right branch, you can commit your changes. Since they are already staged (thanks to the --soft flag we used earlier), you can simply commit them:

git commit -m "Your commit message here"

Replace “Your commit message here” with an appropriate message for your commit.

Step 4: Verify Everything is Correct

Always double-check your work. Ensure you’re on the right branch and that your commit has been applied correctly:

git log --oneline

This command will display the commit history in a concise format. Your most recent commit should be at the top, and you should be on the correct branch.

Conclusion

Mistakes happen, and committing to the wrong Git branch is a common one. Thankfully, Git is a powerful tool that provides ways to fix such issues with ease. Always remember to double-check your branch before committing, and should you find yourself having committed to the wrong branch, simply follow the steps above to rectify the situation.

The post How to fix committing to the wrong Git branch? first appeared on forceUnwrap.

var firstArray = [1, 2, 3, 4, 5]    // [1, 2, 3, 4, 5]
var secondArray = firstArray        // [1, 2, 3, 4, 5]

print(firstArray == secondArray)    // true

secondArray.append(6)               // [1, 2, 3, 4, 5, 6]

print(firstArray.count)             // 5
print(secondArray.count)            // 6

print(firstArray == secondArray)    // false

In Swift, when an array is assigned to another variable, a copy of the array is not created immediately. Instead, the new variable refers to the same memory location as the original array. This means that any changes made to the new variable are reflected in the original array as well.

However, Swift also uses a technique called Copy-On-Write (COW) to optimize memory usage. When a mutable operation is performed on an array (e.g. adding or removing an element), Swift checks whether the array has more than one reference to its memory location. If it does, Swift creates a new copy of the array before performing the mutation, so that the original array remains unchanged.

In the code provided, firstArray is created with the values [1, 2, 3, 4, 5], and then secondArray is assigned to firstArray. Since secondArray is not mutated at this point, it still refers to the same memory location as firstArray.

The first print statement outputs true because firstArray and secondArray both contain the same values.

Next, the value 6 is appended to secondArray. Since secondArray now has more than one reference to its memory location, Swift creates a new copy of the array before appending the value. This means that firstArray remains unchanged, and the print statement that outputs 5 shows that firstArray still has 5 elements.

The post Copy on write iOS developer interview question explained first appeared on forceUnwrap.

git config --global mergetool.keepBackup false

Typically, when using git mergetool to resolve merge conflicts, the tool will save the conflicted version of the file with a .orig and .backup suffixes. However, if the mergetool.keepBackup configuration option is set to false, these .orig and .backup files will not be preserved. It’s worth noting that the default value for this option is true, meaning that backup files will be kept by default.

The post Avoid generating unwanted git .orig and .backup files first appeared on forceUnwrap.

import SwiftUI

struct CustomNavView<Content: View>: View {
    let content: Content
    let title: String
    
    init(title: String, @ViewBuilder content: () -> Content) {
        self.content = content()
        self.title = title
    }
    
    var body: some View {
        NavigationLink(destination: self.content) {
            Text(title)
        }
        .padding()
    }
}

Usage:

CustomNavView(title: "Picker sample in SwiftUI") {
    EmptyView()
}

Changelog:

// Good stuff. 🙇‍♂
git commit -m "Update to trailing closure as head_of_roses recommends" 

The post Pass some View as parameter to another View first appeared on forceUnwrap.

Pro tip:
I prefer to put in on a new line for better readability. In my experience I have noticed, that putting else on a new line, helps spoting start and end of guard without reading the context inside the guard.

// Don't
guard
		let clientID = Bundle.main.object(forInfoDictionaryKey: "ApiClientID") as? String,
		let serverClientID = Bundle.main.object(forInfoDictionaryKey: "ApiServerClientID") as? String
else {
		return
}

// Don't
guard let clientID = Bundle.main.object(forInfoDictionaryKey: "ApiClientID") as? String, let serverClientID = Bundle.main.object(forInfoDictionaryKey: "GoogleServerClientID") as? String else { return }

// Do
guard let clientId = Bundle.main.object(forInfoDictionaryKey: "ApiClientID") as? String,
			let serverClientId = Bundle.main.object(forInfoDictionaryKey: "ApiServerClientID") as? String
else {
		return
}

How do you line break guard with multiple statements? Share in the comments below.

The post Line breaks – multiple guard statements first appeared on forceUnwrap.

// Don't
for val in sequence {
		value.doSomething(
}

// Do
sequence.forEach {
		$0.doSomething()
}

// Do
sequence.forEach { value in
		value.doSomething()
}

Of course there are times when you need for in, but more about that later on.

The post Loops first appeared on forceUnwrap.

// Don't add final, unless you plan to extend the class
class AuthenticationService {
		// Implementation
}

// Do add final, if you are not extending
final class AuthenticationService {
		// Implementation
}

The post Class first appeared on forceUnwrap.

// Don't
let array = ["Tom", "John", "Joe", "Alan", "Alex", "Adam", "Tim", "Tom", "John", "Joe", "Alan", "Alex", "Adam", "Tim"]

// Do
let names = [
		"Tom",
		"John",
		"Joe",
		"Alan",
		"Alex",
		...
]

The post Array first appeared on forceUnwrap.