使用SwiftLint统一编码规范：能否强制字符串仅存于Strings文件？

Absolutely! Let’s break this down into two clear parts to address both of your requirements:

1. Enforcing unified coding standards with SwiftLint #

SwiftLint is built exactly for this purpose—it comes packed with dozens of built-in rules covering everything from naming conventions and indentation to syntax best practices and anti-patterns. You can customize these rules to match your team’s preferred style using a .swiftlint.yml configuration file.

For example, here’s a snippet of a typical config that enforces common standards:

# Enable optional rules that fit your team's needs
opt_in_rules:
  - empty_count
  - explicit_init
  - prefer_nslocalized_string # We'll use this for string localization later

# Disable rules you don't want to enforce
disabled_rules:
  - trailing_whitespace

# Force explicit access control modifiers (e.g., public/private)
force_explicit_acl: true

# Enforce minimum length for identifiers (except common shorthands like "id" or "vc")
identifier_name:
  min_length: 2
  excluded:
    - id
    - vc

Once your config is set up, you can run SwiftLint locally during development, add it as a build phase in Xcode, or integrate it into your CI pipeline. It will flag any code that violates your rules with warnings or errors, making it impossible to merge non-compliant code if you enforce it strictly in CI.

2. Banning hardcoded strings (Swift files + storyboards/XIBs) #

This is a bit more nuanced, but totally achievable:

For Swift files #

SwiftLint has an opt-in rule called prefer_nslocalized_string that will flag any hardcoded string literals and require you to use NSLocalizedString (or similar localization APIs) to pull strings from your Localizable.strings file.

Add this to your .swiftlint.yml to enable it:

opt_in_rules:
  - prefer_nslocalized_string

# Optional: Exclude strings that don't need localization (e.g., log tags, constants)
prefer_nslocalized_string:
  allowed_strings:
    - "DEBUG"
    - "API_ENDPOINT"

This will catch any hardcoded strings in your Swift classes, extensions, etc., and force you to move them to the strings file.

For storyboards and XIBs #

SwiftLint doesn’t handle XML-based files like storyboards or XIBs out of the box, but you can complement it with a custom script to enforce this rule.

A simple approach is to write a shell script that:

• Iterates over all .storyboard and .xib files in your project
• Uses grep or xmllint to check for UI elements (like labels, buttons, or text fields) with hardcoded text attributes (instead of using a localization key)
• Throws an error if any hardcoded strings are found

You can add this script as a pre-build phase in Xcode or run it in your CI pipeline alongside SwiftLint. For example, a quick grep-based check might look like this:

#!/bin/bash

# Find all storyboard/XIB files with hardcoded text attributes
HARDCODED_STRINGS=$(grep -r 'text="[^"]*"' --include="*.storyboard" --include="*.xib" . | grep -v 'text="\$(')

if [ -n "$HARDCODED_STRINGS" ]; then
  echo "Error: Hardcoded strings found in storyboards/XIBs:"
  echo "$HARDCODED_STRINGS"
  exit 1
fi

Alternatively, you can use tools like SwiftGen to generate type-safe localization keys, which makes it easier to avoid hardcoded strings in interface files by binding keys directly in the storyboard/XIB inspector.

Final Verdict #

SwiftLint can fully handle enforcing your unified coding standards and banning hardcoded strings in Swift files. For storyboards and XIBs, pairing it with a custom script will close the loop and let you enforce this rule across your entire project.

内容的提问来源于stack exchange，提问作者Moses Liao GZ