目录标题的名称是“容器”还是“内容”？这个问题惹恼了我，因为如果目录的名称在语义上标题为“容器”，那么名称应该是单数。 （通过类比：当提到包含杂货的实际物品袋时 - 可能会将其称为'杂货袋'，而不是'杂货袋'。）相反，如果有人断言目录标题的名称目录的内容然后使用复数形式更有意义。
我理解这个问题存在常识甚至可用性问题;但是，虽然我想听听这两个选项的实际结果，但我更关注语义。
总结一下：目录的名称是否作为容器或内容的标题？
感谢。
答案 0 :(得分：1)
我的第一个冲动是说您根据通用容器的内容命名它。但是我只是为了好玩而深入研究。 （如果只需要汇总的结论，请滚动到最后。）
首先，我认为Tum的汽车和蛋糕示例对我们没有太大帮助。当然，它们是由更简单的组件制成的，但仅用于创建新的独立对象的目的。食品杂货袋是分子的集合-怎么办。要问的更有意义的事情是：对象的基本目的是持有其他对象吗？换句话说，它是否像文件系统中的文件夹一样是通用容器？您肯定会对蛋糕回答否。您可能会对汽车回答否（尽管确实可以容纳人）。您肯定会对购物袋回答是。
在您的购物袋示例中，您说过我们会将其称为杂货袋，而不是杂货袋。当然。以下句子在语法上都是正确且自然的发音：
只有当听众知道我们刚刚去购物并且可以在不通知我们的情况下推断出所述行李的内容时，第一句话才有意义。如果没有这些信息，就我们所知，这些袋子可能装有毒蛇。第二句话是最具描述性的，但包含多余的信息。任何熟悉食品杂货和购买过程的人都可以合理地推断它们将被装在袋子中。第三句话以最简洁的方式告诉我们所有我们需要知道的。
第四句话完全采用了不同的方法，标记了产生杂货的单数活动。但这并不能告诉我们我们购买了哪种产品，因此描述性不强。 （有时这种方法 是最佳选择，如其他示例所示）。
如果您在任何新的Windows PC或Mac上查看用户的主文件夹，您会发现该文件夹预装有文档，下载和图片之类的文件夹。标有“图片”的文件夹告诉我们所有我们需要知道的。您可以选择在所有目录名称后缀“ dir”，“ folder”或类似的后缀，但这并没有增加任何意义。 （我已经够大了，记得以前的Mac用户在文件夹名称的末尾添加了“ƒ”字符（通过按Option-F生成）。疯狂的时间。）
啊，但也有例外！在我的Mac上，Apple（当然，拥有无限的智慧）为三个子文件夹选择了单数名称：台式机，图书馆和公共。一个怀疑的理由是，没人知道台式机包含的内容，甚至连用户都没有！同样，公用文件夹可能包含任何内容。为了使所有学者见识，我们将其称为 heterogeneous 集合。就像您在圣诞节时取出的那大盒东西，其中包含诸如金属丝，小玩意，长筒袜，包装纸和假雪之类的东西–根据其目的和主题，可以轻松地将其标记为“圣诞节”。 / p>
Library文件夹是一个有趣的文件夹-并不是因为Apple并未根据其内容命名它，而是因为它为我们提供了一个有趣的真实示例。库的目的是保存其他对象，还是它本身就是一个功能对象？我会说它在中间的某个地方。假设我们决定根据内容标记现实世界的图书馆。我们可以称其为“书籍”。 （大多数图书馆包含的书籍多于书籍，但为简单起见，我们会想象我们的图书馆仅包含书籍。）图书馆可以在前面挂一个大标语，上面写着“书籍”，但是您可能会认为书籍是为了出售，而不是自由借钱。您可能会认为这是因为您生活在一个资本主义社会中，在这个社会中，大多数重大迹象都在试图兜售某些东西。因此语义问题也是 context 之一。
还有一个上下文问题，您没有在问题中提供。这些目录存储在哪里？它们在您的个人计算机上还是在Web服务器上？为什么这有关系？嗯，在您的PC上，您可能正在GUI中查看每个文件夹，其中标签被附加到单个图标上。但是，如果目录是网站结构的一部分，则用户更有可能只会将名称视为文件路径的一部分（如果他们完全注意到的话）。这里的问题是，您是否在乎？如果要，您是否希望文件路径像句子一样读取？最好用一个例子来说明：
http://acme.com/order/explosive/detonator/dx3000
虽然每个类别可以是复数形式，但路径使用单数目录名的读法更像是英文句子。尽管这似乎有些强制，但您确实在某些网站上看到了这种方法。
TL; DR：：当容器的功能或主题比其内容更具描述性时，单个标签（例如，图书馆，桌面，圣诞节）最有效。集合越异构，这种方法就越有可能适用。但是在大多数情况下，标记集合中的复数内容（例如文档，下载，图片）更容易且更具描述性。
答案 1 :(得分：0)
有趣的问题。
如果你看一个类作为标记名称的替代（使用<div>或<span>时你会做的，没有语义含义），你的类必须描述元素的内容。
但与此同时，它自己的元素是内容。如果你看一辆汽车就说“这是一辆汽车”，你就不要说'这些是汽车零件'。或者，如果你吃蛋糕，你称之为'蛋糕'，而不是'成分'。
所以我猜一个语义类名称将是单数而不是复数，因为它总是只有一个元素。这可能会导致在类名中使用大量的“包装器”，因为找到元素的拟合名称并不总是那么容易。
我希望这可以回答你的问题，如果不是，你可能想要阅读：http://css-tricks.com/semantic-class-names/
答案 2 :(得分：0)
目录本身不需要名称，因为没有任何内容的目录是没有用的。存在将一组文件组合在一起的目录。即使目录当前为空，它也代表这样的组，只是该组中目前没有文件，这就是为什么它为空。因此，目录名称应始终描述您在该目录中找到的内容。
假设您有一个带盒子的抽屉，并使用这些盒子将物理对象组合在一起。要知道每个盒子里面有什么，而不必先打开它并查看内部，可以给盒子贴上标签。您将如何标记这些盒子？
如果一个盒子中装有铅笔，您可以将其标记为铅笔，而不是铅笔，对吗？如果包装盒中包含回形针，则将其标记为回形针，而不是回形针，不是吗？这是因为在这种情况下，标签仅描述在框中可以找到的物品的类型。目录也是如此。包含图片的目录最有可能被命名为 Pictures 。
但是有时您将项目分组在一起，不是因为它们是同一种类，而是因为它们属于相同的“事物”。例如。如果您有一个装有所有圣诞节装饰品的大盒子，请给该盒子贴上圣诞节装饰品而不是“圣诞节装饰品”，对吗？如果您准备好朋友彼得的生日聚会，并在一个大盒子中收集一些东西，则需要在该盒子上贴上彼得的生日聚会而不是彼得的生日聚会物品。不同之处在于，这一次，项目本身没有共同点，也不属于同一种类，这一次，您只是将这些项目标记为属于同一事件或用于相同目的，因此您可以使用事件或用途名称作为标签。
包含彼得生日的图片的目录很可能会被命名为 Pictures / Peter生日。另一方面，如果您逐年保存彼得的每个生日的照片，则宁愿使用 Pictures / Peter的Birthdays / 2016 这样的结构。请注意，它突然变成了“生日 s ”，因为现在目录名再次描述了在内部找到的项目的类型，而不是单个事件/目的。
一般的经验法则：总是以这样一种方式命名目录，即使目录名的读者对他/他期望什么样的文件和其他目录有很好的了解。可以在该目录中查找，因此他/她只需阅读目录名称就可以决定“去那里”是否有趣。
如果您将目录命名为 Recipe ，那么读者希望在其中找到什么？我希望找到一个或多个文件，所有文件都属于一个配方，例如简短的成分表，更长的说明文字以及一些支持照片。相反，如果您将目录命名为 Recipes ，那么读者会有什么期望？我希望有几个配方，或者多个文件，每个文件包含一个配方，或者多个子目录，每个目录包含属于一个配方的文件。从这个简单的示例可以清楚地看到，是否选择复数会影响读者的期望。