Организация ресурса проекта XCode и структура
У меня часто есть несколько операторов в начале метода для возврата для "легких" ситуаций. Например, это:
public void DoStuff(Foo foo)
{
if (foo != null)
{
...
}
}
... может быть сделан более читаемым (по моему скромному мнению), как это:
public void DoStuff(Foo foo)
{
if (foo == null) return;
...
}
Так да, я думаю, что хорошо иметь несколько "точек выхода" от функции/метода.
3 ответа
Here's a little more explanation of Graham's suggestion:
- Create an images directory
- Create an images Group in Xcode
- Right-click the group and Get Info
- "Choose..." to set the group's directory to be your images directory
Now, anything you put in the images group will automatically go into the images directory. That's true if you drag/drop from within Xcode, from other other projects or from Finder, or if you Add New... by right-clicking on the images directory. (This assumes you leave the default setting of "relative to group" in the info pane.)
This will work for anything you put in that group (NIBs, etc).
For imageNamed:, you just give the base name.
My recommendation is to keep a small number of filesystem directories, and mostly organize with groups in Xcode. But I agree, a small number of filesystem directories are very helpful. I put all my source code in a Classes directory (just because Apple used that name; I would have picked "Sources" or something). I also have a Resources directory at the top level and generally create images and audio directories under that. But I don't generally create a lots of real directories beyond that. This keeps things a bit tidier, but makes it easier to grep and wildcard things with the shell.
Beyond shell tools, the big advantage of organizing by groups rather than directories is the impact on version control systems like subversion. When you suddenly realize that your "Views" group is way too big, you can reorganize it without taking the huge impact of moving files around.
На самом деле очень легко добраться от того места, где вы находитесь, туда, где вы хотите быть. Создайте папку images / и поместите в нее все изображения. Теперь в окне проекта в Xcode файлы изображений стали красными, потому что их больше нет на месте. Получите информацию о них и "Выберите ..." новое местоположение.
Обратите внимание, что после того, как вы переместили файл в исходную файловую систему (известную как $ SRCROOT ), изменений нет. способ использования файла в продукте. Если он был скопирован в Contents / Resources / до того, как вы переместили файл, то он будет скопирован туда впоследствии. В место назначения вложенные папки добавляться не будут.
Life is сложно для IDE. Они должны быть посредником между миром файловой системы , где находится компилятор с его исходными файлами, и миром пользовательского интерфейса , где работают программисты.
В старые времена, которые формировали Современная культура кодирования, все, компиляторы и люди, привыкли жить вместе в файловой системе. Итак, сегодня у нас все еще есть тенденция думать, что мы хотим контролировать расположение источников и ресурсов на диске. Это хорошо, потому что нам может понадобиться точно знать, что едят компиляторы.
В любом случае, если вы думаете, что ваша IDE - это просто интерфейс забавной системы баз данных с исходным кодом, и если вы действительно полностью уверены в ее возможностях и функциях (что бывает редко), вы можете прийти к выводу, что если вам просто наплевать на файловую систему, у вас может быть лучшая жизнь, как программист (и как человек).
Вы правы, задаваясь вопросом, потому что Xcode не очень хорош и не дружелюбен в отношении организации кода файловой системы и людей то есть (правильно) придирчивый к тому, что научится перемещать файлы в их правую папку на диске и в их правую группу Xcode. То есть, если вы используете «Создать ссылки на папки для любых добавленных папок», они будут иметь отношение 1: 1.
Но вы увидите много людей и множество примеров проектов от Apple itsef,