文件夹命名问题
我是管理仓库的。 我需要管理库存并在每次用户需要时显示库存。 我创建了一个名为：Stock 的文件夹 在 Stock 文件夹下我创建了一个名为 StockItem.cs 的文件 现在我需要添加一个名为 Stock 的文件来表示股票。 但文件夹名称是Stock！
我多次遇到这个问题，所以我决定问一下。 命名应用程序结构和文件的最佳方式是什么？
I am manage warehouse.
I need to manage the stock and show the stock in every time the user wants.
I created a folder named: Stock
under Stock folder I created a file named StockItem.cs
Now I need to add a file called Stock that represents the stock.
But the folder name is Stock!
I encounter this problem many times so I decided to ask.
What is the best way to name you application structure and files?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
为什么不直接将文件命名为
Stock.data或StockData或一百种其他可能性中的任何一个？或者将您的文件夹命名为其他名称。您不能拥有一个具有相同名称的文件夹和一个文件，就像您不能拥有两个具有相同名称的文件一样（当然，在不同的目录中，您可以，显然，但这里的情况似乎并非如此）。
Why don't you just call your file
Stock.dataorStockDataor any of a hundred other possibilities?Or call your folder something else. You can't have a folder and a file with the same name any more than you can have two files with the same name (well, in different directories you can, obviously, but that doesn't appear to be the case here).
那里有很多命名约定。如果您遇到名称冲突（听起来像这样），那么您可能应该重新考虑文件夹和文件的逻辑顺序。
您还必须注意，有时文件名可能会重叠。解决方案是确保您拥有绝对命名。因此，实现此目的的一种方法是使用 Java 中的命名约定 (packages< /a>）。
这两个文件都是item1，但是它们有不同的绝对名称，从逻辑上你可以弄清楚它们为什么放在那里（一个是新库存，另一个是旧库存）。
编辑：我看到这是在 .net 环境中，但我确信包命名约定仍然有效。
There are plenty of naming conventions out there. If you are running into names conflicting (which is what it sounds like) then you probably should re-think the logical ordering of your folders and files.
You also have to be aware that sometimes there might be some overlap in file names. The solution so this is to ensure you have absolute naming in place. So one way this is done is by using naming conventions found in Java (packages).
Both of the files are item1, but they have different absolute names, and logically you can figure out why they are placed there (one is new stock and the other is old stock).
EDIT: I see that this is in a .net environment, but I'm sure the package naming convention still holds.