Skip to content

Instantly share code, notes, and snippets.

Objective-C Coding Convention and Best Practices

Most of these guidelines are to match Apple's documentation and community-accepted best practices. Some are derived some personal preference. This document aims to set a standard way of doing things so everyone can do things the same way. If there is something you are not particularly fond of, it is encouraged to do it anyway to be consistent with everyone else.

This document is mainly targeted toward iOS development, but definitely applies to Mac as well.

Operators

NSString *foo = @"bar";
@jonsterling
jonsterling / gist:1541947
Created December 30, 2011 23:09
Configuring UITableViews with C99 array initialization!
// Define your table view's sections
typedef enum {
kTitleSection = 0,
kGoalSection,
kNumberOfSections
} NESTemplateEditTableSections;
// Make configuration arrays indexed against table sections.
// It's safe to reorder the original enum!
static NSString * const kCellIdentifiers[kNumberOfSections] = {
@Simbul
Simbul / pre-commit
Created February 9, 2012 18:06
Git hook to prevent commits on a staging/production branch
#!/usr/bin/env ruby
# This pre-commit hook will prevent any commit to forbidden branches
# (by default, "staging" and "production").
# Put this file in your local repo, in the .git/hooks folder
# and make sure it is executable.
# The name of the file *must* be "pre-commit" for Git to pick it up.
FORBIDDEN_BRANCHES = ["staging", "production"]
@mxswd
mxswd / TypeNats.swift
Last active December 12, 2016 19:24
Thanks @robrix and CodaFi_ for the discussion :D
// this is a playground
protocol Nat {
class func construct() -> Self
class func value() -> Int
}
struct Z : Nat {
static func construct() -> Z {
return Z()
}
@mbrandonw
mbrandonw / gist:ece3afb7597f2ceb544e
Created October 18, 2014 14:05
Proof of De Morgan's law in Swift
// ~(P ∨ Q) = ~P ∧ ~Q
enum Nothing {}
struct Not <A> {
let not: A -> Nothing
init (_ not: A -> Nothing) { self.not = not }
}
struct And <A, B> {
@JadenGeller
JadenGeller / Type-Level Assertions.swift
Last active March 9, 2018 03:06
Type-Level Assertions (or, almost-dependent types)
/*
* We've defined "traits" by which we can type an integer that are characteristic of its value.
* These traits can even be subtraits of other traits (like both positive and negative being nonzero).
*
* We can use these traits in the type signatures of functions to indicate what trait will be returned
* as a function of the passed-in traits.
*
* Even cooler, we can specify properties of the traits such that we can runtime-verify the correctness
* of these labels (in case a function was improperly annotated, for example).
*/
@cb372
cb372 / jargon.md
Last active May 14, 2024 03:45
Category theory jargon cheat sheet

Category theory jargon cheat sheet

A primer/refresher on the category theory concepts that most commonly crop up in conversations about Scala or FP. (Because it's embarassing when I forget this stuff!)

I'll be assuming Scalaz imports in code samples, and some of the code may be pseudo-Scala.

Functor

A functor is something that supports map.

@austinzheng
austinzheng / generics_manifesto.md
Last active October 23, 2023 20:38
Douglas Gregor's Swift Generics Manifesto, with added markdown formatting

(Source: https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160229/011666.html)

Introduction

The “Complete Generics” goal for Swift 3 has been fairly ill-defined thus fair, with just this short blurb in the list of goals:

Complete generics: Generics are used pervasively in a number of Swift libraries, especially the standard library. However, there are a number of generics features the standard library requires to fully realize its vision, including recursive protocol constraints, the ability to make a constrained extension conform to a new protocol (i.e., an array of Equatable elements is Equatable), and so on. Swift 3.0 should provide those generics features needed by the standard library, because they affect the standard library's ABI.

This message expands upon the notion of “completing generics”. It is not a plan for Swift 3, nor an official core team communication, but it collects the results of numerous discussions among the core team and Swift developers, both of the compiler an

@andymatuschak
andymatuschak / States-v3.md
Last active May 1, 2024 12:32
A composable pattern for pure state machines with effects (draft v3)

A composable pattern for pure state machines with effects

State machines are everywhere in interactive systems, but they're rarely defined clearly and explicitly. Given some big blob of code including implicit state machines, which transitions are possible and under what conditions? What effects take place on what transitions?

There are existing design patterns for state machines, but all the patterns I've seen complect side effects with the structure of the state machine itself. Instances of these patterns are difficult to test without mocking, and they end up with more dependencies. Worse, the classic patterns compose poorly: hierarchical state machines are typically not straightforward extensions. The functional programming world has solutions, but they don't transpose neatly enough to be broadly usable in mainstream languages.

Here I present a composable pattern for pure state machiness with effects,

// MARK: Equatable
func ==<T>(lhs: TerminatingNode<T>, rhs: TerminatingNode<T>) -> Bool {
return lhs.value == rhs.value
}
func ==<T, U>(lhs: ListNode<T, U>, rhs: ListNode<T, U>) -> Bool {
return lhs.value == rhs.value && lhs.next == rhs.next
}