Xcode项目名称中的空格，最佳实践是什么？答案

【问题标题】：Spaces in Xcode project names, what's the best practice?Xcode项目名称中的空格，最佳实践是什么？
【发布时间】：2016-04-21 01:43:46
【问题描述】：

我正在创建一个新的 Xcode 项目，名称上会有一个空格，例如“Foo Bar”。我倾向于将其命名为“Foo Bar”，因为它是显示在顶部菜单、文件系统（“Foo Bar.app”）、命令选项卡等上的应用程序的实际名称。但是，我最终带有奇怪的文件夹和目标，例如“Foo BarTest”。

这里的最佳做法是什么？

【问题讨论】：

【解决方案1】：

我使用像“FooBar”这样的一个单词驼峰式名称来开发：文件名、路径等。对我来说，当偶尔需要编写 shell 脚本或其他东西时，让我的生活更轻松一点是有意义的，因为有无需担心内部空间。可以肯定的是，“make”实用程序在空格上会严重窒息……

但实际上，这是因为我没有看到缺点：我的 FooBar.app 的名称将被本地化无论如何，用英语以及任何其他语言，所以应用程序在Finder 看起来类似于“Foo Bar”，并且位于“关于”菜单等中。

因此，在我的所有编码中，它都是 FooBar，而对于用户来说，Foo Bar 无处不在。

如何本地化您的应用名称：

从一个名为“FooBar”的新创建的 Xcode Cocoa 应用程序开始。最初，到处都是“FooBar”：Xcode 变量 ${PRODUCT_NAME} 和 ${EXECUTABLE_NAME}，以及您在 Finder 中构建的应用程序的名称。

现在我们只想更改 Finder 中显示的名称。
正确地说，这不过是本地化。

在应用的 Info.plist 文件中，添加键“CFBundleDisplayName”，并使其值与现有键“CFBundleName”的值相同。

CFBundleName 的初始值是“${PRODUCT_NAME}”，一个 Xcode 变量，您可以复制并粘贴它。或者，您可以将这些键中的每一个“硬编码”为某个文字字符串，但如果这样做，您还必须更新应用程序“构建设置”窗格中的“产品名称”值。

然后，您需要进行实际的本地化。

如果它不存在（它可能存在），创建并添加到项目中的“InfoPlist.strings”本地化文件，id est（假设英语是“主要”语言）该文件驻留在其中并且是复制到应用程序的 Resources 文件夹中名为“en.lproj”的子文件夹中。

在此文件中，以这种格式添加出现在 Info.plist 文件中的相同两个键，为它们提供您希望应用在 Finder 中显示的值：

/* Localized versions of Info.plist keys */
CFBundleName        = "Foo & Bar";
CFBundleDisplayName = "Foo & Bar";

就是这样！就 UNIX 而言，该应用现在是“FooBar.app”，但在用户看来，它在 Finder 中显示为“Foo & Bar”。

【讨论】：

我可能在这里遗漏了一些东西，捆绑包如何可以称为 FooBar.app 并在 Finder 中显示为 Foo Bar？
只是为了确认，您的 CFBundleName 中不是“$(PRODUCT_NAME)”，而是“Foo Bar”？
另外，如果有人打开 /Applications，他们会看到 Foo Bar 还是 FooBar.app？
我将 Foo Bar 设置为 CFBundleName 和 CFBundleDisplayName 但文件显示为 FooBar.app，而不是 Foo Bar.app（是的，我知道 .app 取决于 Finder 首选项，我只是在使用它说清楚我在说什么）。我最终做的是将 PRODUCT_NAME 作为 Foo Bar 并将 PRODUCT_MODULE_NAME 作为 FooBar 并使捆绑包和其他标识符依赖于模块名称而不是产品名称。似乎比 Xcode 的默认设置更健康。
Pablo，我在回答您的后续问题时完全搞砸了。从那时起，我查看、测试、记忆和测试......我之前所说的部分内容与我应该说的内容完全相反。我将有保证、经过尝试和测试的方法作为我对上面第一个问题的回答的编辑。 HTH。

【解决方案2】：

我停止在 Xcode 项目名称中使用空格。

在某些情况下（*）你必须将你的模块导入到你的单元测试模块中，所以在 Swift 中你最终会编写

import Foo Bar

在你的 Foo BarTest 模块中，这是 Swift 编译器不喜欢的。

(*) 当您使用核心数据并且希望在单元测试中使用核心数据模型和类时，这至少是必要的。

【讨论】：

【解决方案3】：

命名项目的唯一“最佳做法”是使用常识。最好将项目名称与其将生成的应用名称相匹配，反之亦然。

我更喜欢一个词的名字——而且简短，特别是如果它是一个CLI 相关的项目。显然这里不是这种情况，所以命名它最适合你。

【讨论】：