scott-lydon

Coding Guidelines

Rules

1. Omit the return keyword in one-line functions that return a value.
2. Use trailing closure syntax.
3. Remove the Google indentation guide rule due to lack of specific guidelines in the Google Swift style guide and because SwiftLint handles indentation.
4. Reevaluate the rule regarding DispatchQueue from inaction on the main thread for feasibility in static analysis.
5. Use higher-order functions when multiple properties call the same function.
6. Require every method to have a comment.

scott-lydon

Coding Guidelines

Rules

1. Omit the return keyword in one-line functions that return a value.
2. Use trailing closure syntax.
3. Remove the Google indentation guide rule due to lack of specific guidelines in the Google Swift style guide and because SwiftLint handles indentation.
4. Reevaluate the rule regarding DispatchQueue from inaction on the main thread for feasibility in static analysis.
5. Use higher-order functions when multiple properties call the same function.
6. Require every method to have a comment.

scott-lydon

# Coding Guidelines

## Rules

1. **Omit the return keyword in one-line functions that return a value.**
2. **Use trailing closure syntax.**
3. **Remove the Google indentation guide rule due to lack of specific guidelines in the Google Swift style guide and because SwiftLint handles indentation.**
4. **Reevaluate the rule regarding DispatchQueue from inaction on the main thread for feasibility in static analysis.**
5. **Use higher-order functions when multiple properties call the same function.**
6. **Require every method to have a comment.**

scott-lydon

1. Omit the return keyword in one-line functions that return a value.

Non-triggering examples:

swift
Copy code
func blocks() -> [Block] {
    .all(with: .retained, times: 2)
}
swift

scott-lydon

// No Model in names
/*
 throw an error when a class or struct is added that doesn't
 use the word model in the name, and isn't a subclass of a
 UIViewController, nor UIView, nor view, uiviewRepresentable,
 codable or observer.
 */

import UIKit

scott-lydon

• Its better to use existing functions than to create your own
• Its better to add functionality to existing types than to create new types.
• Remove unused code.
• Give ui tests a timeout, longer for ci
• following conventions for teams.

scott-lydon

class QRCodeTarotUITests: XCTestCase {
    
    override func setUpWithError() throws {
        // Put setup code here. This method is called before the invocation of each test method in the class.
        
        // In UI tests it is usually best to stop immediately when a failure occurs.
        continueAfterFailure = false
        
        // In UI tests it’s important to set the initial state - such as interface orientation - required for your tests before they run. The setUp method is a good place to do this.
    }

scott-lydon

//
//  WeirdIssue.swift
//  QRCodeTarot
//
//  Created by Scott Lydon on 9/24/22.
//

import SwiftUI

struct WeirdIssue: View {

scott-lydon

struct TestText: View {
    var body: some View {
        HStack(alignment: .firstTextBaseline) {
            Text("Hello world")
            Spacer()
        }
    }
}

scott-lydon

struct TestText: View {
    var body: some View {
        VStack(alignment: .leading) {
            Text("Hello world")
        }
    }
}


struct TestText: View {