Quality Coding
Shares
Emoji: Speech Balloon

How to Improve Code Comments with Little Refactorings

Does your code have comments? Sometimes they’re helpful. But most of the time…

Disclosure: The book links below are affiliate links. If you buy anything, I earn a commission, at no extra cost to you.

As Jeff Atwood explains, code tells you how, comments tell you why. A well-placed code comment is a level above the code itself, explaining why something is written the way it is. But! We can express most comments as code, using well-named identifiers. The Refactoring book calls this Introduce Explaining Variable. Martin Fowler has since renamed that refactoring to Extract Variable to help folks find it in their IDEs.

Continue reading

Emoji: Nose

How Many Code Smells Can You See in This Short Method?

It’s time for a quick exercise in code smells!

How many code smells do you see below?

Continue reading

Don't Lose Your “Flow”… Quickly Generate Test Code!

Subscribe to Download these FREE Code Snippets
Languages: Swift and Objective-C
IDEs: Xcode and AppCode

You’ll get our newsletter on Clean Code techniques for iOS developers. And you’ll get instant access to these code snippets!
We take your privacy seriously. See our privacy policy here.

The 3 Laws of TDD: Focus on One Thing at a Time

Shares

When I was first learning TDD, I’d try to get to the First Step (a failing test) by writing a fully-formed test. But it often took a lot fiddling to get that test to run and fail. Sometimes this was because the production code took several steps to set up. Sometimes it was because the test code wasn’t right.

One of the tricky parts of TDD is that we’re creating two streams of code in parallel: the test code, and the production code. Two things changing at the same time… that’s a hard thing to keep in your head!

Continue reading

Emoji: Writing Hand

My Crazy Plans for the New Year (Book Teaser)

Shares

Happy new year! It seems like good time for a Quality Coding retrospective. I also want to share some goals for 2018.

…Did someone say, “Are you writing a book?”

Continue reading

Emoji: Bust in Silhouette

How to Mock Standalone Functions in Swift

Shares

We’ve looked at ways to mock methods in Swift. But what about standalone functions? Is there a way to mock them as well?

Yes! Not only can we mock Swift standalone functions, but we can do it without changing the call sites.

Continue reading

Emoji: Female Detective

How to Use SwiftLint for Clean, Idiomatic Swift

Shares

We get feedback from the compiler. We get feedback from Test-Driven Development. But what sources of feedback lie in between?

This is where linters come in. A linter goes beyond “Does the code compile?” A linter answers questions like, “Is the code idiomatic? Is it stylistically clean? Are there any red flags?”

Continue reading

Emoji: No Good Gesture

Incorrect TDD: What Can We Learn From It?

Shares

A paper published in 2013 about Test-Driven Development included the following diagram. Unfortunately, it gets some things wrong:

A tweet from Nat Pryce sparked discussion:

First, let me say I’m happy to see more studies on TDD. The thrust of this particular study is that TDD can be soft on negative tests. That is, maybe the code works for good data, but it’ll break on bad data.

TDD is a development discipline, so I’m all for learning more from traditional testing disciplines. I certainly don’t want to discourage folks from doing studies and writing papers.

But. Let’s first make sure we’re doing proper TDD, shall we? Otherwise any studies, especially studies about efficacy, may be flawed.

Continue reading

Emoji: Map Pin

Where Will Jon Be in Fall 2017?

Shares

Do you enjoy conferences and workshops? Here’s my conference schedule for this fall:

Continue reading

Emoji: Keycap Digit One

Does the Single Responsibility Principle Lead to Bad Architecture?

Shares

The “Single Responsibility Principle” (SRP) sounds so noble. But I’m afraid it’s misunderstood and misapplied. Ask your teammates: “What is the Single Responsibility Principle?” Go ahead, ask them. Then ask if the SRP is a good thing or a bad thing. I’d bet many of them will say something like this: “In principle, it’s a good idea. But in practice, it’s overkill.”

On Twitter, Chris Eidhof pointed to an example of taking the Single Responsibility Principle too far. Specifically, Chris was unhappy with the argument that Singletons violate the SRP because, besides their main responsibility, they also manage their own life cycle:

This led to a lively discussion. Many reacted against “over-architecture.” No doubt they experienced fragmented code that grew from over-zealous attempts at SRP.

I think that SRP isn’t just over-applied. It’s fundamentally misunderstood, even misquoted. The repeated misquotes perpetuate that misunderstanding.

Let’s see if we can clear things up, and point to a better way.

Continue reading

Emoji: Hatching Chick

Automatically Generate Swift tearDown with This AppCode Plugin

Shares

Those of you who are regular visitors to qualitycoding.org may have already read Jon’s article outlining the life cycle of XCTestCase objects during the execution of a test suite. If you haven’t, or you want to refresh your memory, take a moment to read the original article.

Jon discusses the importance of the setUp and tearDown methods. And, more specifically, why we should be deallocating our properties in the tearDown method.

Writing a tear down method is one of those repetitive tasks. It follows a specific pattern: all properties should be set to nil. It doesn’t really require any brain power. It’s just one of those annoying tasks that you have to remember to do when writing a test.

It’s tasks like this that should be automated. And now with the Swift tear down inspection AppCode plugin, we can.

Continue reading

>